„Ein Deal-Feld aktualisieren" klingt nach einer Einzeiler-Aufgabe — bis das Feld sich stumm weigert: Die Anfrage meldet Erfolg, die Karte zeigt den alten Wert. Die Ursache ist fast immer eine von dreien — die falsche Methodengeneration, das falsche Feldnamen-Format oder die falsche Wertform. So funktioniert das Aktualisieren von Deal-Feldern in Bitrix24 (Alaio) wirklich: vom rohen REST-Aufruf bis zur No-Code-Automatisierungsregel.

Welche Methode aktualisiert ein Deal-Feld?

Die aktuelle Antwort ist die universelle Methode crm.item.update: Übergeben Sie entityTypeId 2 (Deal), die Deal-ID und ein fields-Objekt, das nur die zu ändernden Felder enthält — alles Weggelassene bleibt unberührt.

{"entityTypeId": 2, "id": 351, "fields": {"stageId": "C1:WON", "opportunity": 50000}}

Die ältere Einzelmethode crm.deal.update funktioniert weiterhin und steht in den meisten Tutorials, gehört aber zur Legacy-Generation: gleiche Felder, andere Benennung. Neue Integrationen sollten standardmäßig crm.item.update nutzen — sie deckt Deals, Leads, Kontakte, Unternehmen und Smart-Prozesse mit einem Vertrag ab.

Warum wird das Feld nicht aktualisiert?

Der erste Verdächtige ist die Groß-/Kleinschreibung. Die Legacy-API und der Workflow-Designer schreiben Feldcodes in Großbuchstaben: TITLE, OPPORTUNITY, UF_CRM_1721244707107. Die universelle API schreibt dieselben Felder in camelCase: title, opportunity, ufCrm_1721244707107. Senden Sie TITLE an crm.item.update, wird es als unbekannter Schlüssel ignoriert — mit Erfolgsmeldung. Soll die universelle Methode die originalen UF_CRM_*-Namen akzeptieren, übergeben Sie useOriginalUfNames mit Y. Der zweite Verdächtige ist die Wertform: Ein Listenfeld erwartet die Element-ID statt der Beschriftung, ein Datumsfeld ein korrektes Datumsformat, und ein ungültiger Wert liefert CRM_FIELD_ERROR_VALUE_NOT_VALID mit dem Feldnamen zurück. Wo die Feldcodes nachzuschlagen sind, zeigt der Beitrag zu Feld-IDs in Bitrix24.

Wie aktualisiere ich Telefon, E-Mail und andere Multifelder?

Telefonnummern und E-Mails leben im Multifeld-Array fm, und dessen Update-Semantik stolpert jeder mindestens einmal: Bestehende Zeilen werden über ihre id angesprochen — eine Zeile mit id ändert den Eintrag an Ort und Stelle —, Zeilen ohne bekannte id werden als neue Einträge hinzugefügt. Ein „frischer" Wertesatz ohne ids ersetzt die alten nicht, er hängt an — und der Kontakt des Deals sammelt still doppelte Telefonnummern. Erst die aktuellen fm-Zeilen lesen, dann per id aktualisieren.

Wie aktualisiere ich ein Feld per Webhook?

Für eine Ein-Portal-Integration braucht es keine OAuth-Anwendung: Ein eingehender Webhook liefert eine URL, die die Autorisierung in sich trägt. Erstellen Sie ihn mit dem Scope crm — und denken Sie daran, dass der Webhook mit den Rechten des Mitarbeiters agiert, der ihn angelegt hat: Sieht diese Person die Pipeline nicht, scheitert der Aufruf mit einem Zugriffsfehler, obwohl das Token gültig ist. Methode, id und fields gehen in die Anfrage genau wie oben. Die Einrichtung Schritt für Schritt steht im Webhook-Guide; kommt statt eines Ergebnisses ein Fehlercode zurück, benennt er direkt das Feld oder das Rechteproblem — protokollieren Sie den Code, nicht nur die Beschreibung.

Wie aktualisiere ich Deal-Felder ohne Code?

Innerhalb des Portals brauchen die meisten Feld-Updates gar kein REST — eine Automatisierungsregel auf der Phase erledigt das. Die Standardregel „Element bearbeiten" deckt ein Feld mit statischem Wert ab. Ändern sich mehrere Felder auf einmal oder kommen Werte aus vorherigen Schritten, nimmt die Regel Deal per ID aktualisieren aus dem Roboteka-Katalog ein JSON-Objekt im selben camelCase-Format wie crm.item.update und schreibt alles in einer Aktion. Das Leeren eines Feldes ist ein Fall für sich — ein leerer String löscht keine Listen, Daten oder Multifelder, dafür gibt es die Regel Feld leeren, die jeden Typ korrekt nullt. Um einen Wert über Entitätsgrenzen zu bewegen — etwa die Stadt aus dem Kontakt in den Deal zu kopieren — dient Feld der verknüpften Entität setzen, und gegen leere Pflichtfelder vor einem Phasenwechsel liefert Feld auf Inhalt prüfen ein Y/N für die Verzweigung. Eine Aktion im Workflow ist zugleich die günstige Antwort auf „brauche ich dafür ein externes Szenario": keine Tokens zu erneuern, keine Request-Limits zu budgetieren — das Update läuft dort, wo der Deal lebt.

Wie geht es weiter

Starten Sie beim tatsächlichen Fehlerbild: falsche Schreibweise — auf camelCase wechseln oder useOriginalUfNames setzen; doppelte Telefonnummern — fm-Zeilen per id aktualisieren; Zugriffsfehler — die Rechte des Webhook-Erstellers prüfen. Alles, was auf Deal-Ereignisse statt auf externe Aufrufe reagieren soll, bauen Sie als Automatisierungsregeln in Bitrix24 — die Update-Regeln oben sind dort gewöhnliche Bausteine. Und fehlt der Baustein, den Sie brauchen: Beschreiben Sie die Aufgabe — Roboteka baut fehlende Automatisierungsregeln kostenlos und stellt sie in die gemeinsame Bibliothek.