Salesforce mit IMMOTRAY verbinden

So kommen deine Objekte und Teilobjekte aus Salesforce nach IMMOTRAY, und so meldet IMMOTRAY den Reservierungsstand zurück.

Die Bilder stammen aus einem echten Durchlauf am 09.09.2026 — Salesforce-Seite in einer Developer-Org, IMMOTRAY-Seite in der Verwaltung.

Die Arbeit ist geteilt. Teil A machst du selbst in Salesforce, dafür brauchst du dort Administratorrechte. Teil B macht zurzeit noch ein IMMOTRAY-Systemadministrator für dich — das Client Secret gilt für deine ganze Org, deshalb liegt die Einrichtung bei uns. Teil C ist optional und hat Zeit.

Für den Anfang reicht der Schnellstart am Beginn von Teil A: sechs Schritte, etwa 20 Minuten, danach laufen beide Richtungen.

---

Worum es geht

Wir fassen deine Felder nicht an. Nicht Status__c, nicht OeffentlicherStatus__c, nicht VKC_Phase__c, kein bestehendes Feld. Wir schreiben ausschließlich in die vier Felder aus Schritt A5, die es vor uns nicht gab. An deinem Appartment__c hängen Provisionsabrechnung, MaBV-Rechnungen und Mahnwesen — dort etwas zu setzen wäre unser Risiko und dein Schaden.

---

Teil A — In Salesforce

Schnellstart oder vollständig?

In deiner Org entstehen dabei nur die Anwendung aus A2, ein leerer Berechtigungssatz aus A4 und die vier neuen Felder aus A5. Kein neuer Benutzer, keine Änderung an einem bestehenden Feld. Rückgängig machen heißt: Anwendung löschen — die vier Felder können bleiben, sie stören nichts.

A1 — Integrationsbenutzer festlegen

Der Zugriff läuft unter einem Benutzer. Nimm einen eigenen (Lizenztyp „Salesforce Integration", falls vorhanden), keinen persönlichen Account.

Warum ein eigener: Wir blenden alle Änderungen aus, die dieser Benutzer selbst gemacht hat — sonst läse unser Abgleich unsere eigenen Schreibvorgänge als fremde Änderung zurück. Hängt an dem Benutzer noch anderes, verschwindet das aus unserer Sicht mit.

Im Schnellstart überspringst du diesen Schritt und trägst in A3 einen vorhandenen Administrator ein. Vor dem Produktivgang bitte auf einen eigenen Benutzer umstellen — danach in A3 den Ausführungsbenutzer ändern und in A4 den Berechtigungssatz neu zuweisen.

A2 — Externe Client-Anwendung anlegen

Setup → Anwendungen → Anwendungs-Manager

Oben rechts: Neue externe Client-Anwendung.

Nicht mehr „Connected App". Salesforce hat den Weg umgestellt; in aktuellen Orgs gibt es die Schaltfläche zum Anlegen einer Connected App gar nicht mehr. Bestehende Connected Apps laufen weiter — im Bild ist IMMOTRAY Sync genau so eine, Anwendungstyp „Connected". Neu angelegt wird heute die externe Client-Anwendung. Für uns ist beides gleichwertig: wir brauchen nur Verbraucherschlüssel und -geheimnis.

Ausfüllen:

Dann den Abschnitt API (OAuth-Einstellungen aktivieren) aufklappen und OAuth aktivieren ankreuzen:

Weiter unten, Abschnitt Flow-Aktivierung: Flow für Client-Anmeldeinformationen aktivieren ankreuzen. Salesforce fragt nach:

Die Warnung ist berechtigt und beschreibt genau, warum das Geheimnis so sorgfältig behandelt werden muss. Mit OK bestätigen, dann Erstellen.

A3 — Richtlinien: wer darf, und als wer

Auf der Detailseite der Anwendung: Reiter Richtlinien → Bearbeiten, Abschnitt OAuth-Richtlinien.

Zulässige Benutzer auf Vom Administrator genehmigte Benutzer sind vorab autorisiert umstellen. Auch hier fragt Salesforce nach — der Hinweis betrifft Benutzer, die die Anwendung schon verwenden; bei einer frisch angelegten ist das niemand:

Danach erscheint die Auswahl Berechtigungssätze auswählen. Den Berechtigungssatz aus Schritt A4 nach rechts schieben:

Im Abschnitt Erweiterungen an OAuth-Flows und an der externen Client-Anwendung steht jetzt Ausführen als (Benutzername). Dort die E-Mail-Adresse des Benutzers aus Schritt A1 eintragen.

Ausführen als ist der Kern des Ganzen: Der Client-Credentials-Flow kennt keinen anmeldenden Menschen. Alles läuft unter diesem Benutzer und mit genau seinen Rechten.

Speichern.

A4 — Berechtigungssatz mit Objekt- und Feldrechten

Setup → Benutzer → Berechtigungssätze → Neu — Name IMMOTRAY_Sync_Access.

Im Schnellstart bleibt er leer: anlegen, unter Zuweisungen verwalten deinem Administrator zuweisen, Objekt- und Feldeinstellungen weglassen. Er ist dann kein Rechtepaket, sondern nur der Haken, über den Salesforce die Anwendung für den Ausführungsbenutzer freischaltet — die Leserechte kommen aus dem Administratorprofil. Zwei Minuten. Den Rest dieses Abschnitts füllst du aus, sobald ein eigener Integrationsbenutzer den Zugriff übernimmt.

Unter Objekteinstellungen:

• Property__c — Lesen
• Appartment__c — Lesen und Bearbeiten
• Feldberechtigungen: Lesezugriff auf alle Felder, die wir abfragen; Schreibzugriff auf die vier Immotray_*-Felder aus Schritt A5

Dann Zuweisungen verwalten → den Benutzer aus Schritt A1 zuweisen.

Feldrechte sind die häufigste Fehlerquelle. Ein Feld, das im Berechtigungssatz fehlt, existiert für die API nicht — auch nicht für Administratoren. Salesforce antwortet dann mit INVALID_FIELD auf genau dieses eine Feld, und die ganze Abfrage scheitert, nicht nur dieses Feld. Unsere Schaltfläche Verbindung prüfen fragt deshalb mit der vollständigen Feldliste ab und nennt das fehlende Feld beim Namen.

A5 — Vier Felder für den Rückweg anlegen

Auch im Schnellstart nötig — fünf Minuten. Diese vier Felder sind der Rückweg. Fehlen sie, steht bei dir in Salesforce nicht, welche Einheit reserviert ist, und dein Vertrieb verkauft sie ein zweites Mal. Nachträglich anlegen geht jederzeit und ohne Neuaufbau der Verbindung.

Setup → Objekt-Manager → Appartment__c → Felder und Beziehungen → Neu

Immotray_Status__c trägt genau drei Werte: Frei, Reserviert, Verkauft. Text statt Auswahlliste, damit ein bei uns neu hinzukommender Wert nicht an einer Validierungsregel deiner Org scheitert.

Nicht vergessen: Schreibrechte für diese vier Felder im Berechtigungssatz aus A4.

A5b — Schreibrecht nur auf unsere Felder (empfohlen)

Wofür: Du willst IMMOTRAY den Reservierungsstand zurückmelden lassen, ohne dass die Anbindung irgendetwas anderes an deinen Teilobjekten ändern kann. Solange du diesen Schritt nicht machst, bleibt unser Integrationsbenutzer rein lesend — dann läuft nur die Richtung Salesforce → IMMOTRAY, und unter Anbieter → Bearbeiten → Salesforce bleibt der Schalter Rückmeldung aus.

Salesforce hat keinen Schalter „darf nur dieses eine Feld schreiben". Es ist die Kombination aus zwei Einstellungen im selben Berechtigungssatz:

1. Objektberechtigung Appartment__c: Lesen und Bearbeiten — nichts sonst.
2. Feldberechtigungen: Bearbeitungszugriff ausschließlich auf die Felder, die wir schreiben. Jedes andere Feld bleibt ohne Bearbeitungszugriff; ein Schreibversuch darauf scheitert in Salesforce mit INVALID_FIELD_FOR_INSERT_UPDATE.

Welche Felder das sind, hängt davon ab, wohin wir zurückmelden sollen — das stellen wir je Verbindung unter Anbieter → Bearbeiten → Salesforce ein (Auswahl neben Rückmeldung):

Variante 1 — euer Statusfeld Status__c („Verfügung") — Schreibrecht auf genau dieses eine Feld. Wir setzen dort ausschließlich:

Jeden anderen Status lassen wir unangetastet — steht eine Einheit bei euch auf Reserved, Sold oder in einer Notarphase, schreiben wir nichts. Hat jemand bei euch die Einheit nach uns bearbeitet, nehmen wir unsere Anfrage auch nicht mehr zurück; das entscheidet dann euer Vertrieb. Jeder Schreibvorgang ist bedingt: ändert sich die Einheit bei euch zwischen unserem Lesen und Schreiben, lehnt Salesforce ab und wir entscheiden im nächsten Lauf neu.

Variante 2 — eigene Felder aus A5. Dann schreiben wir bei jeder Rückmeldung genau zwei Felder, und zwar gemeinsam:

Beide brauchen Bearbeitungszugriff — fehlt einer, lehnt Salesforce die ganze Meldung ab. Die übrigen zwei Felder aus A5 (Immotray_Reserved_Until__c, Immotray_Contract_Id__c) füllen wir heute nicht; sie dürfen ohne Schreibrecht bleiben.

Schritt für Schritt (am Beispiel einer eigenen Berechtigung neben IMMOTRAY_Sync_Access):

Setup → Benutzer → Berechtigungssätze → Neu — Bezeichnung z. B. IMMOTRAY Reservierungsstatus, Lizenz „– Keine –", Speichern.

Objekteinstellungen → Teilobjekte (Appartment__c) → Bearbeiten. Unter Objektberechtigungen nur Lesen und Bearbeiten anhaken. Erstellen, Löschen, Alle Datensätze anzeigen und Alle Datensätze ändern bleiben aus.

Weiter unten unter Feldberechtigungen Bearbeitungszugriff anhaken — Variante 1: nur bei Status__c („Verfügung"); Variante 2: bei Immotray_Status__c und Immotray_Synced_At__c (Bild). Lesezugriff kommt automatisch mit. Bei allen anderen Feldern keinen Bearbeitungszugriff setzen. Speichern.

Dann Zuweisungen verwalten → den Integrationsbenutzer aus A1 zuweisen.

Vier Dinge, die du dabei wissen solltest:

• Rechte addieren sich. Salesforce nimmt immer die Summe aus Profil und allen Berechtigungssätzen. Hat der Integrationsbenutzer irgendwo sonst Schreibrechte — etwa über das Profil Systemadministrator oder einen anderen Berechtigungssatz —, ist diese Einschränkung wirkungslos. Sie greift nur mit einem eigenen Integrationsbenutzer mit minimalem Profil (z. B. Minimum Access – API Only Integrations, Lizenz Salesforce Integration), nicht im Schnellstart mit deinem Administrator.
• Name und Inhaber sind nicht abschaltbar. Sobald das Objekt Bearbeiten hat, zeigt Salesforce diese beiden Standardfelder ausgegraut als bearbeitbar an. Das lässt sich pro Feld nicht ändern. Wir schreiben sie nie: welche Felder unser Rückweg sendet, ist im Code fest vorgegeben (Status__c bzw. die Immotray_*-Felder).
• Datensatzzugriff. Bearbeiten wirkt nur auf Datensätze, die der Benutzer über eure Freigaben auch bearbeiten darf. Steht die organisationsweite Standardeinstellung für Teilobjekte auf Privat oder Schreibgeschützt, braucht der Integrationsbenutzer eine Freigaberegel mit Lese-/Schreibzugriff auf die Teilobjekte der veröffentlichten Immobilien. Alle Datensätze ändern ist dafür nicht der richtige Weg.
• Rechte greifen mit Verzögerung. Wir halten ein Salesforce-Zugangstoken bis zu 30 Minuten. Tauschst du den Benutzer unter Ausführen als oder änderst seine Rechte, kann unsere Seite bis dahin noch mit dem alten Stand arbeiten. Verbindung prüfen zeigt dir, als wer wir gerade angemeldet sind.
• In unserer Test-Org nachgewiesen (24.09.2026, Variante 1): ein Integrationsbenutzer mit genau diesen Rechten setzt Status__c auf Reservierung angefragt und zurück; Kaufpreis, eigene Felder, Objekt ändern, Einheit anlegen oder löschen lehnt Salesforce ab (INVALID_FIELD_FOR_INSERT_UPDATE bzw. keine Objektrechte).
• Eure Automatisierung läuft trotzdem. Auch wenn wir nur ein Feld schreiben, ist es ein Update auf eurem Appartment__c: Validierungsregeln, Flows und Trigger auf dem Objekt feuern. Lehnt eine Validierungsregel ab, sehen wir den Fehler; einen Flow mit Nebenwirkung sehen wir nicht. Prüft deshalb vorher, was bei euch an Änderungen dieses Objekts hängt — am besten in einer Sandbox.

A6 — My-Domain-URL heraussuchen

Setup → Meine Domäne → „Aktuelle URL Meiner Domäne".

Sie sieht so aus: https://kunde.my.salesforce.com

Nicht die Adresse aus der Adresszeile deines Browsers (…lightning.force.com, das ist die Oberfläche) und nicht login.salesforce.com. An beiden schlägt der Client-Credentials-Flow fehl — IMMOTRAY weist die Lightning-Adresse deshalb schon im Formular ab.

A7 — Zugangsdaten heraussuchen

Auf der Anwendung: Reiter Einstellungen → OAuth-Einstellungen → Verbraucherschlüssel und -geheimnis.

Salesforce schickt dir dafür einen Bestätigungscode per Mail. Drei Werte gehen an uns:

1. My-Domain-URL aus A6
2. Verbraucherschlüssel (Consumer Key / Client-Id)
3. Verbrauchergeheimnis (Consumer Secret)

Bitte über einen Kanal, der für Passwörter taugt — nicht per E-Mail im Klartext. Geht das Geheimnis später verloren, erzeugst du an derselben Stelle ein neues; bei uns ist das ein Formularfeld.

---

Teil B — In IMMOTRAY

Anbieter → Bearbeiten → Integration, Abschnitt Salesforce-Anbindung (unter „TeamProQ-Integration"). Der Abschnitt ist nur für Systemadministratoren sichtbar.

B1 — Verbindung anlegen

Verbindung hinzufügen öffnet das Formular:

Die Zugangsdaten werden gegen die Org geprüft, bevor etwas gespeichert wird. Eine Verbindung mit falschem Secret wäre schlimmer als keine: der Abgleich liefe alle zehn Minuten in denselben Fehler, und im Protokoll sähe das aus wie ein Ausfall auf Salesforce-Seite.

Zwei Fehlerbilder, die dabei zuverlässig auftreten. Die Lightning-Adresse statt der My-Domain-URL:

Und falsche Zugangsdaten — die Meldung von Salesforce steht wörtlich da:

In beiden Fällen wird nichts gespeichert.

B2 — Verbindung prüfen

Drei Dinge auf einmal, weil sie unterschiedlich scheitern und unterschiedliche Gegenmaßnahmen brauchen:

1. Anmeldung — Verbraucherschlüssel/-geheimnis oder die Einstellung der Anwendung.
2. Objektzugriff je Objekt — fehlt das Objektrecht, kommt INVALID_TYPE; fehlt ein einzelnes Feld, INVALID_FIELD. Beides zeigt auf den Berechtigungssatz aus A4.
3. Identität — der Run-As-Benutzer. Er wird nicht eingetippt, sondern gemessen und gespeichert: genau diese Id blendet der Abgleich später aus, damit er unsere eigenen Schreibvorgänge nicht als fremde Änderung zurückliest. Weicht der hinterlegte Wert ab, sagt die Prüfung das und korrigiert ihn.

B3 — Erstabgleich

Der erste Lauf ist ein bewusster Klick, kein Zufallstreffer eines Zeitplans: Automatischer Abgleich steht nach dem Anlegen absichtlich auf aus.

Erstabgleich (alles) liest jeden Datensatz neu ein. Er ist auch die Reparatur, wenn später eine Zuordnung korrigiert wurde — beim laufenden Abgleich kämen die betroffenen Datensätze nie wieder vorbei, weil ihr Änderungszeitstempel hinter dem Merkpunkt liegt.

B4 — Was übersprungen wurde

Trifft der Abgleich auf einen Statuswert, den er nicht kennt, überspringt er den Datensatz und sagt es — mit Feldname und Wert:

Das ist Absicht. Ein stiller Standardwert wäre die schlimmere Variante: bei 36 Einheiten, von denen 35 verkauft sind, stünden sie nach einem falsch geratenen „Frei" alle wieder im Verkauf, ohne dass es jemand merkt. Lieber ein Datensatz, der fehlt und sichtbar fehlt.

Die Korrektur ist bei uns eine Zeile pro Wert, danach denselben Erstabgleich noch einmal.

B5 — Automatischen Abgleich einschalten

Läuft der Erstabgleich sauber durch, den Schalter Automatischer Abgleich einschalten. Ab dann holt IMMOTRAY die Änderungen von selbst ab, spätestens alle zehn Minuten.

Der Abgleich merkt sich, wo er stehen geblieben ist. Eine Pause — nachts, bei einer Störung, nach einer abgeschalteten Verbindung — kostet deshalb keine Daten: der nächste Lauf holt alles seit dem letzten nach.

B6 — Rückweg und Protokoll

Status zurückschreiben meldet den Reservierungsstand aller Einheiten dieser Verbindung in die vier Immotray_*-Felder. Im Normalbetrieb passiert das von selbst, sobald sich bei uns etwas ändert.

Aufgeklappt zeigt die Karte den Merkpunkt je Objekt, den ausgeblendeten Integrationsbenutzer und die letzten Push-Zustellungen:

B7 — Verbindung löschen

Die eingelesenen Immobilien und Einheiten bleiben stehen, und ihre Salesforce-Id bleibt gespeichert. Eine neu angelegte Verbindung findet dieselben Datensätze deshalb wieder, statt Dubletten anzulegen.

---

Teil C — Sofortmeldung per Flow (empfohlen, aber nichts für den ersten Tag)

Aufwand: ein bis zwei Stunden für jemanden, der Flow Builder kennt. Fünf Schritte in Setup, und als einziger Teil dieser Anleitung nicht in der Oberfläche nachgeklickt (siehe Kasten unten). Lass ihn beim ersten Anschluss weg — der regelmäßige Abgleich trägt den Betrieb, Teil C macht ihn nur schneller.

Ohne diesen Teil holt IMMOTRAY Änderungen alle zehn Minuten ab. Mit ihm erfährt es sie in Sekunden. Das zählt vor allem, wenn mehrere Vermittler gleichzeitig dieselben Einheiten verkaufen: zehn Minuten sind genau die Spanne, in der eine längst verkaufte Einheit bei uns noch frei aussieht.

Der regelmäßige Abgleich läuft trotzdem weiter, und das ist kein Doppelt-gemoppelt: datensatzgesteuerte Flows feuern nicht, wenn eine Formel oder ein Rollup neu rechnet (SummeKaufpreise__c, Freie_Appartments__c, alle Anzahl*). Diese Änderungen kämen ohne den Abgleich nie bei uns an. Jede belastbare Salesforce-Anbindung fährt deshalb beides: den Anruf für die Geschwindigkeit, den Abgleich für die Vollständigkeit.

Der Ablauf: Dein Flow schickt uns nur die Datensatz-Id. Die Feldwerte holen wir uns anschließend selbst. So sehen Abgleich und Sofortmeldung exakt dieselben Daten, und in deinem Flow steht keine Feldliste, die bei jeder Änderung nachgezogen werden müsste.

Die drei Werte dafür stehen in IMMOTRAY auf der Verbindungskarte unter Push aus Salesforce einrichten: Callout-URL, connectionId und X-Immotray-Token.

Dieser Teil ist noch nicht Schritt für Schritt in der Oberfläche nachgestellt — anders als Teil A und B. Die Empfängerseite bei uns ist geprüft und läuft; die Schritte hier sind aus der Salesforce-Dokumentation und noch nicht bebildert.

1. Externe Anmeldeinformationen (Setup → Benannte Anmeldeinformationen → Externe Anmeldeinformationen → Neu): Authentifizierungsprotokoll Benutzerdefiniert. Darunter ein Prinzipal vom Typ „Benannter Prinzipal" mit dem Authentifizierungsparameter Token = dem X-Immotray-Token.
2. Benannte Anmeldeinformationen: URL https://app.immotray.de, die externen Anmeldeinformationen von oben, „Autorisierungsheader generieren" aus, „Formeln in HTTP-Header zulassen" an. Benutzerdefinierter Header X-Immotray-Token mit dem Wert {!$Credential.IMMOTRAY.Token}.
3. Zugriff freigeben: im Berechtigungssatz aus A4 unter „Zugriff auf externe Anmeldeinformationen (Prinzipal)" den Prinzipal hinzufügen. Ohne das scheitert der Aufruf mit UNAUTHORIZED_ENDPOINT.
4. HTTP-Callout im Flow Builder: POST auf /api/salesforce/inbound. Als Beispielrumpf genau das hier — die connectionId steht auf der Verbindungskarte:

{
  "connectionId": "00000000-0000-0000-0000-000000000000",
  "objectName": "Appartment__c",
  "ids": ["a01ak00003alxzjAAA"]
}

ids muss dabei als Textliste erkannt werden, deshalb im Beispiel eine echte Id in eckigen Klammern und nicht nur [].

1. Datensatzgesteuerter Flow auf Appartment__c, ausgelöst beim Anlegen und Ändern, optimiert für „Aktionen und zugehörige Datensätze". Der Callout muss in einen asynchronen Pfad — Salesforce erlaubt in einem After-Save-Flow keinen synchronen Callout, sonst lässt sich der Flow nicht aktivieren. Dort eine Textliste recordIds mit {!$Record.Id} füllen und den Callout mit objectName = Appartment__c aufrufen. Dasselbe noch einmal für Property__c.

Eintrittsbedingungen braucht es nicht. Unser Rückschreiben löst deinen Flow mit aus; wir erkennen und verwerfen diese Rückläufer selbst anhand des Integrationsbenutzers — im Protokoll steht dann „0 gelesen". Wer die überflüssigen Aufrufe sparen will, setzt als Bedingung LastModifiedById ungleich <Benutzer aus A1>. Unsere Prüfung bleibt trotzdem bestehen: eine Bedingung in einem fremden Werkzeug kann bei der nächsten Änderung dort unbemerkt entfallen.

---

Wenn etwas nicht geht

Kommt bei uns gar keine Zustellung an, liegt der Fehler in Salesforce (Flow feuert nicht oder der Callout scheitert dort). Kommt eine mit Fehlermeldung an, liegt er bei uns. Die Verbindungskarte zeigt beides — das sind zwei verschiedene Baustellen, und die Unterscheidung spart die meiste Zeit.

Was heute noch nicht mitkommt

Damit es keine Überraschung gibt:

• Bilder, Dokumente und Videos — weder die Dateien an deinen Datensätzen (Salesforce Files, Anhänge) noch Website_Header_Bild__c oder Objektvideo_Link__c
• Verknüpfungen auf Anbieter und Notar — die Immobilie landet beim Anbieter der Verbindung, deren Lookups werden nicht aufgelöst
• Förderung/KfW (Foerderung__c → kFW_id)
• Pflegeimmobilien-Felder: Betreiber, Zimmerart, Bettenanzahl, MaBV-Ratenplan, Erbbaurecht — dafür gibt es in unserem Datenmodell noch kein Zuhause
• Der Rückweg schreibt nur Immotray_*. Dein Status__c bleibt unberührt, deine Provisionsabrechnung sieht unsere Reservierungen also nicht automatisch.