Field Service Mobile App: Flow-Grenzen in Winter '27

Die Salesforce Field Service Mobile App führt zwei Flow-Typen aus. Für neue Technikerformulare ist Data Capture meist die bessere Wahl: Es unterstützt bedingte Sichtbarkeit, Sections, Repeater und einen Lookup für mehrere Datensätze, und die Formulare lassen sich offline ausfüllen. Keiner der beiden Typen hat eine Data Table, um Datensätze aus einer Liste zu wählen, und keiner unterstützt den IN-Operator. Offline sammelt Data Capture die Antworten, legt Datensätze aber erst an oder ändert sie, wenn das Gerät wieder online ist. Dem klassischen Field Service Mobile Flow fehlt das meiste davon. Mit Winter ’27 laufen beide auf einer neuen nativen Laufzeit, jeder bestehende mobile Flow braucht also einen neuen Test am Gerät.

In der App laufen zwei Flow-Typen, und sie können nicht dasselbe

Wer “mobiler Flow” sagt, meint einen von zwei Prozesstypen im Flow Builder:

• Field Service Mobile Flow. Der ältere Typ. Die Flow-Hinweise für die Mobile App1 listen seine Einschränkungen.
• Data-Capture-Flow. Der Formulartyp für den Außendienst. Er braucht Lightning Data Service, das Salesforce bis Spring ’26 für alle Orgs verpflichtend gemacht hat (Lightning Data Service für Field Service Mobile2), und hat eine eigene Seite mit Einschränkungen3.

In den Release Notes zu Data Capture von Winter ’26 bis Summer ’26 habe ich in jedem Release eine neue Flow-Funktion gezählt. Für den klassischen Typ habe ich im selben Zeitraum keine gefunden (Stand November 2026). Der normale Prozesstyp Screen Flow wird in der App nicht unterstützt, nur diese beiden. Wie man Data-Capture-Formulare aufbaut, steht in Field Service Data Capture: Prüfprotokolle ohne Papier.

Was in welchem Flow-Typ geht (Hilfeseiten, Stand November 2026)

FunktionField Service Mobile FlowData-Capture-Flow

Data Tableneinnein

IN / NOT INneinnein, gilt für die ganze App

Transform-Elementnicht genanntnicht genannt

Bedingte Sichtbarkeitneinja, nicht mit Collection-Variablen

Section und Spaltenneinja, seit Summer '26

Lookup für mehrere Datensätzeneinja, seit Spring '26

Formelfunktionen25, ohne IF(), AND(), OR()50, mit IF(), CASE(), TEXT()

Globale Variablen311

“Läuft offline” hat drei Ebenen, die leicht durcheinandergeraten. Der Techniker kann ein Data-Capture-Formular ohne Verbindung öffnen und ausfüllen. Das Formular kann nur die Datensätze lesen, die im Briefcase des Technikers liegen. Und Anlegen, Ändern und Löschen müssen am Ende des Flows stehen und warten, bis das Gerät online ist, und das nur für Objekte, die die User Interface API unterstützt. Für einen Prozess, der vor Ort einen neuen Datensatz braucht, wiegt dieser letzte Punkt schwerer als eine fehlende Formelfunktion.

Warum gibt es keine Data Table in der Field Service Mobile App?

Die Komponente Data Table4 ist nicht mit mobilen Geräten kompatibel, das schreibt Salesforce in der eigenen Referenz. In der Liste der Data-Capture-Komponenten5 fehlt sie ebenfalls. Der klassische Typ erlaubt außer dem Datei-Upload gar keine Lightning-Komponenten auf Screens, und Data Capture unterstützt ebenfalls keine eigenen Lightning Web Components. Eine selbst gebaute Tabelle scheidet also in beiden Typen aus.

Einen gleichwertigen Ersatz gibt es nicht. Was Salesforce für Data Capture dokumentiert:

• Lookup-Komponente (Spring ’26). Der Techniker sucht einen oder mehrere Datensätze, etwa Assets, und wählt sie aus, auch offline. Das ist die einzige dokumentierte Mehrfachauswahl. Sie passt, wenn der Techniker weiß, wonach er sucht. Eine vorbereitete Liste zum Abhaken zeigt sie nicht.
• Repeater mit Datenquelle (Summer ’26). Eine Collection füllt die Zeilen vorab, der Techniker prüft oder ändert jede Zeile. Der Repeater ist dafür gedacht, Daten zu mehreren Positionen zu erfassen, nicht dafür, sie auszuwählen. Bei höchstens 30 Zeilen lässt sich eine Auswahl mit einer Checkbox pro Zeile nachbauen und nach dem Screen auswerten.

Rechenbeispiel: Bei der Jahreswartung einer Verpackungslinie muss der Techniker markieren, welche von acht Baugruppen er geprüft hat und welche einen Folgeauftrag brauchen. Am Desktop ist das eine Data Table mit acht Checkboxen. In Data Capture werden daraus entweder acht Lookup-Suchen oder ein Repeater mit acht vorbefüllten Zeilen und je einer Checkbox, dazu ein Loop nach dem Screen, der die angehakten Zeilen einsammelt.

Im klassischen Typ gibt es beides nicht. Collection Choice Sets werden dort nicht unterstützt, und ein Record Choice Set behält nicht einmal den gewählten Wert: Den speichert nur die Eingabekomponente.

IN, Transform und Formeln: die Logik muss neu gebaut werden

Die Flow-Hinweise für die Mobile App führen die Operatoren IN und NOT IN als nicht unterstützt in der Field Service Mobile App. Dieselbe Seite nennt Data Capture als Ausnahme bei der bedingten Sichtbarkeit, aber nicht bei IN, und die Data-Capture-Seite erwähnt IN gar nicht. Ich behandle es deshalb in beiden Typen als nicht unterstützt. Eine lange Werteliste in einer Decision ist ein Zeichen, dass die Logik ins Backend gehört oder in ein Feld, das vor dem Start des Flows gesetzt wird.

Transform taucht auf keiner Mobile-Seite auf, und die Referenz der Flow-Elemente6 nennt dafür nur Screen-, Autolaunched- und Record-Triggered-Flows. Ersatz ist ein Loop mit Assignments.

Formeln sorgen am häufigsten für Überraschungen. Der klassische Typ kennt 25 Funktionen. IF(), AND(), OR(), TEXT(), TODAY() und ISPICKVAL() gehören nicht dazu; logische Verknüpfungen gehen nur mit Operatoren. Data Capture listet 50 Funktionen, darunter IF(), CASE(), TEXT(), DATEVALUE() und REGEX(), aber INCLUDES(), HOUR() und MINUTE() fehlen auch dort.

Für Entwickler

Regeln für den klassischen Typ, die erst auf dem Handy auffallen

• Logische Operatoren müssen als &&, ||, == und != geschrieben werden; AND, OR, = und <> scheitern in der App.
• Eine Decision darf höchstens neun Bedingungen haben; Get Records akzeptiert weder OR noch eigene Logik.
• Zuweisungen an Collections sind auf Add, Equal und Equals Count beschränkt.
• Wer IN durch CONTAINS auf eine Werteliste ersetzt, setzt das Trennzeichen um die Liste und um den Suchwert, etwa ;A1;A10; und ;A1;, sonst trifft A1 auch A10.
• Debug und ein Lauf am Desktop verhalten sich wie ein normaler Screen Flow, eine Formel mit AND funktioniert dort also und scheitert erst in der App. Für Data Capture läuft der Debugger seit Winter '26 auf derselben Offline-Engine wie die App.

Bei Prüf- und Abnahmeprotokollen ist das die Grenze, die ich als erste mit der Serviceleitung besprechen würde, weil sie entscheidet, ob das Ausfüllen erzwungen oder nur auf dem Screen erbeten wird. Ob ein Formular als Nachweis gegenüber Kunde oder Behörde reicht, ist eine eigene Frage.

Datum und Uhrzeit verhalten sich offline anders

Die Eingabe von Datum und Uhrzeit ist nicht das Problem. Data Capture hat eine eigene Komponente Date & Time mit Minimum, Maximum und Standardwert. Die Schwierigkeiten liegen im weiteren Ablauf, und es hilft, vier Zeitpunkte zu trennen: wann die Arbeit stattfand, wann eine Formel ausgewertet wurde, wann der Datensatz synchronisiert wurde und welche Zeiten in den Audit-Feldern stehen.

• NOW() offline. Laut den Offline-Hinweisen7 liefert NOW() in einem Datum/Uhrzeit-Feld den Zeitpunkt, zu dem der Datensatz mit dem Server synchronisiert wurde, nicht die Uhrzeit auf dem Gerät.
• Audit-Felder. Erstell- und Änderungsdatum offline geänderter Datensätze stimmen nur mit der Einstellung “Accurate Record Dates for Offline”, die der Salesforce-Support aktiviert. Einen fachlichen Zeitstempel aus NOW() korrigiert sie nicht.
• Uhrzeit ohne Datum. Den Datentyp Time unterstützt die App überhaupt nicht (unterstützte Datentypen8). Geplanter Start und geplantes Ende sowie das Ankunftsfenster des Servicetermins sind als Datum/Uhrzeit-Felder ebenfalls ausgenommen.
• Fehler im Jahr 2026. Die mobilen Patch Notes9 führen Korrekturen auf: 12:00 AM wurde verworfen (Android 260.2), der Picker ignorierte das Zeitintervall (iOS 262.3), und Screen-Felder mit $Flow.CurrentDateTime luden nicht (Android 264.1).

Wenn der Zeitpunkt der Arbeit zählt, erfassen Sie ihn in einem eigenen Feld und legen Sie fest, ob der Techniker ihn eingeben darf, das Gerät ihn setzt oder der Server ihn vergibt. Diese Wahl testen Sie dann online und offline.

Was ändert sich mit nativen mobilen Flows in Winter ’27?

Seit Winter ’2710 laufen Flows in der App auf einer nativen Architektur: schnelleres Laden, bessere Offline-Fähigkeit, Screens im Design der normalen Datensatzformulare. Die Umstellung kommt schrittweise, je nach Instanz mit Patch 264, 264.1, 264.2 oder 264.3. Die Patch Notes von Juni bis September 2026 zeigen, wie viel sich darunter bewegt hat. Allein die Patches 262.2 und 262.3 haben auf iOS und Android mehrere Fehler bei der Übergabe leerer und Null-Werte behoben, von denen einige eine Decision auf den falschen Pfad schickten.

Bis dahin behandle ich jeden mobilen Flow nach der Umstellung als ungetestet. Wie man App-Versionen testet, bevor sie alle Techniker erreichen, steht in Field Service App-Updates testen.

Erster Schritt: mobile Flows nach Typ sortieren und die Lücken am Handy testen

Listen Sie jeden Flow auf, den Techniker in der App starten, und notieren Sie den Prozesstyp. Dann gehen Sie so vor:

1. 01

   Flows auflisten

   Flow-Name, Prozesstyp, aus welchem Objekt er startet und ob er offline laufen muss.

2. 02

   Mit der Tabelle abgleichen

   Jedes Element, jeden Operator und jede Formelfunktion markieren, die die Hilfeseiten ausschließen.

3. 03

   Formulare zu Data Capture

   Flows, die Daten erfassen und Sichtbarkeitsregeln, Sections oder einen Lookup für mehrere Datensätze brauchen.

4. 04

   Auf beiden Plattformen testen

   Auf iOS und Android, online und im Flugmodus, mit der Patch-Version Ihrer Nutzer.

Welche Datensätze ein Flow offline lesen kann, entscheidet der Briefcase, siehe Field Service offline: welche Daten aufs Gerät gehören. In Field-Service-Programmen entscheide ich mit dem Team, welcher mobile Prozess in Data Capture, in einen mobilen Flow, in eine normale Datensatzbearbeitung oder ins Backend gehört; das ist Teil meiner Arbeit an der Lösungsarchitektur.

Quellen10

1. 1Flow-Hinweise für die Mobile App (öffnet in einem neuen Tab)help.salesforce.com
2. 2Lightning Data Service für Field Service Mobile (öffnet in einem neuen Tab)help.salesforce.com
3. 3Seite mit Einschränkungen (öffnet in einem neuen Tab)help.salesforce.com
4. 4Komponente Data Table (öffnet in einem neuen Tab)help.salesforce.com
5. 5Liste der Data-Capture-Komponenten (öffnet in einem neuen Tab)help.salesforce.com
6. 6Referenz der Flow-Elemente (öffnet in einem neuen Tab)help.salesforce.com
7. 7Offline-Hinweisen (öffnet in einem neuen Tab)help.salesforce.com
8. 8unterstützte Datentypen (öffnet in einem neuen Tab)help.salesforce.com
9. 9mobilen Patch Notes (öffnet in einem neuen Tab)help.salesforce.com
10. 10Winter ’27 (öffnet in einem neuen Tab)help.salesforce.com