Eigene Objekte und Schema
Das Schema im CRM steuert, welche Objekte es gibt, welche Properties sie haben, wie Properties in Gruppen liegen und wie Datensätze verbunden sind. Als Admin legst du die Struktur fest. Als Member arbeitest du mit Datensätzen, Boards und Listen — ohne das Modell umzubauen.
Systemobjekte und eigene Objekte
Jeder Workspace mit CRM hat drei feste Systemobjekte: Contact, Company und Deal. Dazu kommen deine eigenen Objekte (Custom Objects).
Systemobjekt: Contact, Company, Deal — nicht umbenennbar, nicht archivierbar. Die Slugs contact, company und deal sind reserviert.
Eigenes Objekt: z. B. Ticket, Standort oder Asset — umbenennbar und archivierbar. Archivierte eigene Objekte erscheinen nicht in der Objektliste.
Wer Schema ändern darf
Schema: Objekt, Property und Gruppe anlegen oder ändern — Admin.
Datensätze anlegen, bearbeiten, archivieren, importieren — Member.
Boards und Listen anlegen und nutzen — Member.
Lesen (Objekte, Properties, Datensätze) — Viewer.
Members dürfen Datensätze aller Objekte pflegen — System und Custom. Das Datenmodell selbst bleibt Admin-Sache.
Objekt anlegen, umbenennen und archivieren
Öffne die CRM-Einstellungen für Objekte (Schema-Admin).
Lege ein neues Objekt an: Name und Slug. Beim Anlegen entsteht die Gruppe General.
Benenne das Objekt später um, wenn sich der Zweck ändert.
Archiviere ein eigenes Objekt, wenn du es nicht mehr brauchst.
Archivierte eigene Objekte verschwinden aus der Liste. Ein Wiederherstellen gibt es in der Produkt-UI und über die HTTP-API derzeit nicht. Systemobjekte kannst du weder umbenennen noch archivieren.
Identität, Anzeigename und zweites Anzeigefeld
Jedes Objekt hat bis zu drei besondere Property-Rollen:
Identität (Primary) — Upsert-Schlüssel / Matching. Einmal gesetzt: nicht tauschen, nicht löschen. Erzwingt Pflicht und Unique. Erlaubte Typen: Text, Email, Number, Select. Einmalig setzbar bei Custom Objects.
Anzeige (Display) — primärer Kurztitel in Listen und Verbindungen. Jederzeit änderbar.
Zweites Anzeigefeld (Secondary) — Ergänzung zum Titel; muss sich von Display unterscheiden. Jederzeit änderbar.
System-Defaults zum Einordnen: Contact → Email / Vorname / Nachname; Company → Domain / Name; Deal → Name / Name.
Die Identität steuert Matching und Import-Upsert. Display und Secondary steuern nur, wie der Datensatz heißt — nicht, ob er einzigartig ist.
Eigenschaften: Typen und Gruppen
Es gibt 12 Property-Typen: Text, LongText, Email, Number, Boolean, Date, DateTime, Select, MultiSelect, Template, File, Language.
Properties hängen in Gruppen. Systemobjekte haben Katalog-Gruppen; eigene Objekte starten mit General. Systemgruppen kannst du umbenennen, aber nicht löschen. Eine Gruppe löschst du nur, wenn keine aktiven Properties mehr dranhängen.
Workspace-eigene Properties darfst du auch an Systemobjekten anlegen — z. B. ein Extra-Feld am Contact.
Berechnete Felder und systemverwaltete Werte
Manche Felder setzt du nicht manuell am Datensatz:
Template — berechnet aus Platzhaltern (z. B. Vollname aus Vor- und Nachname). Read-only beim Record-Edit.
File — Typ existiert im Schema; Werte setzt du nicht über die normale Datensatz-Bearbeitung.
Systemverwaltete Contact-Felder — z. B. Original/Latest Source und Marketing-Bestätigungsstatus. Die Quelle schreibt das System; den Marketing-Status setzt ein Admin-Endpoint, nicht das normale Formular.
Was beim Anlegen und Importieren nicht gesetzt wird
Im Create-Formular und beim Import sind ausgeschlossen:
Template-Properties
File-Properties
systemverwaltete Properties
archivierte Properties
Pflichtfelder prüft das Formular in der UI. Plane Import und Formulare so, dass Identität und übrige Pflichtfelder sinnvoll befüllt sind.
Verbindungen zwischen Objekten
Zwischen Contact, Company und Deal gibt es feste System-Verbindungen (many-to-many). Den Typ wählst du in der UI nicht manuell — das System leitet ihn aus den Objekten ab.
Bei eigenen Objekten entsteht beim ersten Link der Default-Typ linked_to („Linked to“ / „Linked from“), ebenfalls many-to-many. Eine Admin-Oberfläche zum Konfigurieren von Verbindungstypen gibt es im Produkt derzeit nicht.
Self-Links sind nicht erlaubt. Der Anzeigename in der Verbindung kommt aus Display und Secondary.
Boards und Spalteneigenschaft
Ein Board braucht eine nicht archivierte Select-Property als Spaltenfeld. Spalten = Optionen dieser Property plus „Nicht zugeordnet“.
Beim Deal ist die typische Spalten-Property pipeline_stage. Das ist CRM — nicht die App Sales. Sales steuert Produkte, Angebote und Rechnungen; die Deal-Pipeline läuft über Boards im CRM.
Fehlt die Select-Property, legst du sie als Admin an (auch inline beim Board-Create möglich). Members bewegen Karten; Schema bleibt Admin.
Listen auf eigenen Objekten
Listen (statisch oder dynamisch) funktionieren auf System- und eigenen Objekten. Du speicherst Segmente — unabhängig von Board-Spalten. Eine dynamische Liste filtert nach Kriterien; das Board zeigt die Select-Property. Beides parallel nutzen ist üblich.
Mobil und Integrationen
Mobile: Objektliste → Recordliste → Detail; Datensätze anlegen und bearbeiten (Member+). Kein Schema-Admin, keine Boards, keine Listen-Verwaltung auf dem Handy.
Public API / MCP: Schema lesen (Objekte und Properties listen), Datensätze und Verbindungen schreiben. Schema-Mutationen (Objekte oder Properties anlegen) gehören nicht zur Public API / MCP.
Grenzen und häufige Verwechslungen
Sales-Pipeline = Deal-Board — nein. Pipeline = CRM-Board mit Select (oft pipeline_stage). Sales ist eine andere App.
Archiviertes Objekt wiederherstellen — in der UI/HTTP derzeit nicht.
File-Property als Upload-Feld — nicht über die normale Datensatz-Bearbeitung nutzen.
Verbindungstyp in der UI wählen — nein; System oder Default linked_to.
Jeder darf Schema bauen — nein. Schema = Admin+. Records, Boards und Listen = Member+.
MCP legt Objekte an — nein. MCP/Public API lesen Schema und schreiben Records.
Systemobjekt umbenennen oder Identität tauschen — nein.
Weiterlesen
Objekte und Datensätze — Systemobjekte, Archivieren, Alltag mit Records
Properties — Typen, Pflicht, Unique, Gruppen
Verbindungen — Contact, Company, Deal und eigene Objekte verknüpfen
Boards — Kanban, Spalten-Property, Kartenlayout
Deals im Alltag — Pipeline als Board, Abgrenzung zu Sales
Rechte im CRM — Admin, Member, Viewer