Field Service App: offline, Formulare und Berichte

Die Field Service App muss dort funktionieren, wo das Netz endet. Die erste Entscheidung ist deshalb, welche Datensätze jede Technikergruppe offline hält. Data-Capture-Formulare aus dem Flow Builder ersetzen Papierprotokolle, Document Builder erzeugt den Servicebericht mit Unterschrift und Fotos. Prüfberichte mit Bedingungslogik brauchen meist ein zweites Werkzeug. Visual Remote Assistant spart Einsätze, wenn der Bediener eine Störung mit Anleitung selbst beheben kann. Die App hat eigene Versionen neben den Plattform-Releases, also braucht jede einen kurzen Test, bevor sie auf die Geräte kommt. Alles baut auf einem Datenmodell auf, das vor dem ersten Formular steht.

Was leistet die Field Service App?

Field Service, das Salesforce heute als Field Service and Operations (öffnet in einem neuen Tab) verkauft, bringt für Techniker eine eigene App mit. Kapitel 2 hat gezeigt, wie ein Einsatz eingeplant wird. Dieses Kapitel beginnt dort, wo der Techniker den Einsatz öffnet.

Die Field Service App ist eine eigene App im App Store und bei Google Play. Laut Trailhead (öffnet in einem neuen Tab) bekommen Techniker darin ihre Einsätze, Kundendaten, Änderungen am Arbeitsauftrag und die Unterschrift des Kunden, ohne im Büro anzurufen. Die Salesforce Mobile App ist die allgemeine App für Vertrieb und Innendienst. Für einen Hersteller zählt vor allem der Unterschied beim Offline-Betrieb: Laut Salesforce Developers (öffnet in einem neuen Tab) kann jede Field-Service-Org eigene Lightning Web Components in der Field Service App offline nutzen, die Salesforce Mobile App braucht dafür die Lizenz Mobile App Plus. Meine Regel: Techniker arbeiten in der Field Service App, Disposition und Innendienst bleiben im Browser.

Planen Sie deshalb Zeit ein, um Formulare und Abläufe mit den Technikern selbst zu testen, bevor die App ausgerollt wird.

Offline-Daten pro Technikergruppe mit Briefcase Builder

Eine Grundausstattung für offline bringt die App mit. Laut dem Trailhead-Modul zu Offline-Briefcases (öffnet in einem neuen Tab) legt Briefcase Builder fest, welche Datensätze jede Technikergruppe herunterlädt, und Performance Priming synchronisiert die wichtigsten Änderungen alle fünf Minuten, solange Verbindung besteht. Offline erfasste Änderungen speichert das Gerät und überträgt sie später.

Bei einem Maschinenbauer kommt aufs Gerät, was der Techniker braucht, um die Einsätze des Tages abzuschließen und zu dokumentieren, ohne im Büro anzurufen: Termine für heute und morgen, Arbeitsauftrag mit Positionen, das Asset mit seiner jüngsten Historie, das Fahrzeuglager und das Handbuch zu dieser Maschine. Vollständige Preislisten und alle Assets eines Gebiets bleiben online. Salesforce nennt keine feste Zahl an Datensätzen, die ein Gerät halten kann. Messen Sie deshalb die Synchronisation am Morgen mit Ihrer größten Region, statt mit einer Zahl zu planen.

Die Hinweise zu LWC Offline (öffnet in einem neuen Tab) nennen fünf bekannte Probleme. Drei davon bestimmen den Testplan:

Problem	Was passiert
Aufgaben werden nicht geladen	Ein Task-Objekt im Briefcase löst beim Priming einen Fehler aus.
Partner-Benutzer	Ein Benutzer mit Community-Lizenz kann beim Öffnen eines Service-Termins einen Fehler wegen eines fehlenden Datensatzes bekommen. Partnertechniker brauchen deshalb einen eigenen Briefcase und einen eigenen Test.
Kaltstart unter iOS	Geänderte Lightning Web Components lädt die App erst, wenn sie ganz beendet und neu gestartet wurde.

Den Briefcase pro Rolle, die vollständige Liste und einen Tag im Keller ohne Netz beschreibe ich in Field Service App offline: Welche Daten aufs Gerät?.

Aus Papierprotokollen werden Data-Capture-Formulare

Data Capture ist die Formularfunktion der Field Service App. Laut dem Trailhead-Überblick (öffnet in einem neuen Tab) baut sie direkt auf dem Flow Builder auf, und Formulare hängen an Service-Terminen, Arbeitsaufträgen und Auftragspositionen. Sie enthalten Unterschrift, Textfelder, Nachschlagefelder und Checkboxen, und Abschnitte können abhängig von früheren Antworten erscheinen. Formulare funktionieren offline, jede Eingabe wird automatisch gespeichert, und jede Übermittlung wird protokolliert. Nicht jede Flow-Funktion vom Desktop gibt es dort: Data Table und IN-Operator fehlen, siehe Field Service Mobile App: Flow-Grenzen.

Das Formular ist schnell gebaut. Länger dauert die Entscheidung davor: Welche Antworten werden Felder am Asset oder am Arbeitsauftrag, und welche bleiben Formularantworten? Betriebsstunden, Messwerte, die Sie über Besuche vergleichen, und das Gesamtergebnis gehören in Felder, denn Wartungspläne, Berichte und die ERP-Schnittstelle arbeiten mit Feldern. Bestanden oder nicht bestanden pro Prüfpunkt kann im Formular bleiben. Verbaute Teile werden als verbrauchte Produkte gebucht, nie als Freitext, sonst sehen Fahrzeuglager und ERP sie nicht. Die vollständige Zuordnungstabelle und wie Sie ein langes Protokoll nach Variante aufteilen, stehen in Field Service Data Capture: Prüfprotokolle ohne Papier.

Voice to Form und geführte Arbeit: Was ist verfügbar?

Der Stand ändert sich mit jeder App-Version, deshalb trenne ich ihn vom Formulardesign:

Funktion	Stand Oktober 2026	Quelle
Voice to Form	allgemein verfügbar seit App-Version 260.0 (Spring ’26)	Release-Beitrag in der Trailblazer Community (öffnet in einem neuen Tab)
Voice to Form auf Deutsch, Französisch, Italienisch, Spanisch, Japanisch	Winter ’27	Winter-’27-Highlights (öffnet in einem neuen Tab)
Nachschlagefeld offline, Vorschau mehrerer Bilder, Formulare an Assets und Zeitnachweisen	in 260.0 genannt, Stand in Ihrer Org prüfen	Release-Beitrag 260.0
Guided Experience, Formulare aus dem Foto eines Papierformulars	angekündigt am 20. Oktober 2026, ohne Termin	Salesforce-Blog (öffnet in einem neuen Tab)

Spracheingabe auf Deutsch macht die Funktion für Serviceteams in der DACH-Region interessant. Sie verarbeitet aber die Sprache von Beschäftigten, und damit sind Datenschutz und, wo vorhanden, der Betriebsrat gefragt. Diese Fragen und das Risiko, ein schlechtes Papierformular eins zu eins zu digitalisieren, beschreibe ich in Salesforce Field Service Mobile: Führung und Sprache. Meine Reihenfolge: erst Formular und Felder, dann Sprache als zweiter Schritt.

Wann reicht der Servicebericht aus dem Document Builder?

Document Builder erzeugt den Servicebericht als PDF aus einem Arbeitsauftrag, einer Auftragsposition oder einem Service-Termin. Laut den Field-Service-Limits (öffnet in einem neuen Tab) bringt jeder Nutzer mit einer Lizenz Field Service Dispatcher oder Field Service Mobile 250 Dokumente pro Monat mit, für Spitzenmonate gibt es einmalig 10.000 zusätzliche Dokumente. Ein Techniker mit fünf Einsätzen am Tag erstellt etwa 105 Berichte im Monat, deutlich unter der Grenze.

250

Dokumente pro Nutzer und Monat mit Lizenz Field Service Dispatcher oder Field Service Mobile

10.000

zusätzliche Dokumente einmalig pro Org für Spitzenmonate

50

Seiten und 100 MB höchstens pro Dokument

Für den klassischen Bericht an der Maschine, mit Arbeitszeit, Teilen, Fotos und Unterschrift des Kunden, offline erstellt, ist Document Builder die richtige Wahl. Die Grenzen auf derselben Seite sind für die Planung wichtig:

Grenze	Was sie bedeutet
Nur drei Objekte	Kein Dokument am Asset oder an einem eigenen Objekt.
Android hinkt hinterher	Unter iOS entstehen Dokumente aus Arbeitsauftrag und Service-Termin, unter Android nur aus dem Service-Termin.
Umfang	Höchstens 50 Seiten und 100 MB pro Dokument.

Fünf kleinere Lücken sollten Sie beim Standardbericht einplanen: Vorlagenwahl, Dateiname, E-Mail, Vorbelegung und Gestaltung. Flows und kleine Komponenten schließen sie ohne weitere Lizenz, wie ich in Document Builder: fünf Grenzen und Workarounds zeige.

Wann brauchen Sie ein zweites Werkzeug?

Prüfberichte mit bedingten Abschnitten, Maschinenakten am Asset, Zertifikate und Word-Ausgabe gehen über Document Builder hinaus. Dafür würde ich Salesforce Document Generation oder ein Werkzeug aus dem AppExchange für die Nutzer im Innendienst lizenzieren, die es brauchen, und den Servicebericht im Document Builder lassen. Den Vergleich finden Sie in Salesforce Service Documents: reicht der Document Builder?.

Angebote sind ein eigener Fall. Sieht der Techniker Zusatzarbeit oder ein verschlissenes Teil und will der Kunde vor Ort einen Preis, gehört das Angebot in den Vertriebsprozess mit seinen Freigaben. Wie Angebote, Verträge und Aufträge dort laufen, beschreibt das Kapitel Angebot, Vertrag, Auftrag der Masterclass Revenue Cloud.

Wann ersetzt ein Videoanruf den Einsatz?

Visual Remote Assistant ist ein Videowerkzeug für Service Cloud und Field Service. Laut Produktseite (öffnet in einem neuen Tab) tippt der Kunde auf einen Link per SMS oder E-Mail, und ein Video in beide Richtungen öffnet sich im mobilen Browser, ohne App, Login oder Passwort. Sitzungen lassen sich aufzeichnen. Das Add-on kostet laut Preisliste, Oktober 2026 (öffnet in einem neuen Tab) 50 US-Dollar pro Nutzer und Monat und ist in Agentforce 1 Field Service enthalten. Der Kunde braucht keine Lizenz.

Aus meiner Sicht ersetzt Video einen Einsatz, wenn der Bediener die Störung mit Anleitung selbst beheben kann: ein verstellter Parameter, ein Bedienfehler, ein Reset. Bei mechanischen Reparaturen spart es den zweiten Einsatz, weil der Techniker mit dem richtigen Teil anreist.

Wie Sie das Potenzial aus den Störungseinsätzen des letzten Jahres schätzen, steht in Visual Remote Assistant: Videohilfe statt Einsatz?.

Wie testen Sie jede App-Version?

Neben den drei Plattform-Releases im Jahr hat die App eigene Haupt- und Patch-Versionen. Laut dem Beta-Programm der Field Service App (öffnet in einem neuen Tab) gibt es Beta-Builds einen Monat vor Hauptversionen und eine Woche vor Patches, und mit Debug-Builds testen Entwickler ihre eigenen Komponenten im Emulator oder Simulator. Laut Release-Beitrag zu 260.0 verteilt Salesforce Versionen über mehrere Tage, manche Nutzer bekommen ein Update erst sieben Tage nach der allgemeinen Verfügbarkeit. Bis zu einer Woche laufen also verschiedene Versionen bei Ihren Technikern.

Meine Routine pro Version, auf iOS und Android, passt in einen halben Tag:

Nr.	Testfall
1	Anmeldung und Rückkehr nach einer Stunde im Hintergrund.
2	Priming mit einem echten Technikerprofil, dann ein vollständiger Einsatz im Flugmodus mit verbrauchten Teilen.
3	Ein echtes Data-Capture-Formular, zur Hälfte geschlossen und wieder aufgenommen.
4	Der Servicebericht mit Unterschrift, offline.
5	Eigene Komponenten nach einem Kaltstart.
6	Dasselbe mit einem Partner-Benutzer.
7	Nach der Synchronisation: Verbrauch und Bericht im Innendienst und im ERP.

Pilotgruppe, Kalender und wer für App-Versionen verantwortlich ist, beschreibe ich in Field Service App Updates: jede Version vorher testen. App-Versionen gehören in denselben Kalender wie die Plattform-Releases, beschrieben im Kapitel Release-Planung der DevOps-Masterclass. Wie solche Testskripte in Qualitätsprüfungen passen, steht im Kapitel Qualität, Tests und Reviews.

Rechenbeispiel: Das Inbetriebnahmeprotokoll verlässt das Papier

Ein Maschinenbauer mit 60 Technikern nimmt Verpackungsmaschinen in drei Varianten in Betrieb. Das Papierprotokoll hat 80 Prüfpunkte. Der Techniker füllt es von Hand aus und scannt es abends ein, der Innendienst tippt die Messwerte ins ERP. Alle Zahlen sind Annahmen, um die Reihenfolge der Entscheidungen zu zeigen.

1. 01

   Datenmodell

   Wochen 1 und 2 · Service, Innendienst, ERP-Team

   Jeden Prüfpunkt als Feld, Formularantwort, Folgeposition oder bereits bekannt markieren. Zwölf Fragen fallen weg, weil Seriennummer, Kunde und Maschinentyp schon am Asset stehen.

2. 02

   Briefcase

   Woche 3

   Ein Briefcase für eigene Techniker, einer für die zwei Partnerfirmen, beide gefiltert nach Gebiet und Datum.

3. 03

   Formulare

   Wochen 4 bis 7

   Allgemeine Prüfungen am Service-Termin, ein Variantenformular pro Maschinentyp an der Auftragsposition, Abnahme mit Unterschrift. Messwerte wie die Taktzahl landen in Feldern am Asset.

4. 04

   Bericht

   Woche 8

   Die Vorlage für den Servicebericht zeigt das Gesamtergebnis aus dem Feld am Arbeitsauftrag. Der ausführliche Prüfbericht mit Variantenlogik bleibt ein eigenes Dokument aus dem Innendienst.

5. 05

   Pilot

   Wochen 9 und 10 · acht Techniker

   Darunter einer von einem Partner. Sie fahren echte Inbetriebnahmen und die Testroutine auf beiden Plattformen.

Voice to Form wartet, bis Datenschutz und Betriebsrat zugestimmt haben. Nach dem Pilot stehen die Messwerte am Abend des Einsatzes am Asset, und niemand tippt sie noch einmal ab.

Zieldatenmodell für Servicedaten vor dem ersten Formular festlegen

Vier Entscheidungen brauchen einen Namen, bevor ein Partner Formulare baut:

Entscheidung	Was dazugehört
Zieldatenmodell für Servicedaten	Welche Werte werden Felder an Asset und Arbeitsauftrag, welche Auswahllisten werden geteilt, wie werden Mängel zu Folgearbeit?
Briefcase pro Rolle	Eigener Techniker, Partnertechniker, Teamleiter.
Aufteilung der Dokumente	Servicebericht im Document Builder, Dokumente mit Logik in einem zweiten Werkzeug, Angebote im Vertriebsprozess.
Verantwortung für App-Versionen	Meist der Release Manager, gemeinsam mit dem Gerätemanagement.

Das Datenmodell ist Arbeit an der Salesforce-Architektur und entscheidet, ob Formulare, Berichte und später KI-Agenten die Daten nutzen können. Kapitel 4 baut darauf auf, mit Assets, Wartungsplänen und Ersatzteilen, und die Übersicht zeigt alle Kapitel.