Field Service Data Capture: Prüfprotokolle ohne Papier

Aus einem Prüf- oder Inbetriebnahmeprotokoll auf Papier wird ein Data-Capture-Formular im Flow Builder, das in der Field Service App läuft, auch offline, und am Arbeitsauftrag, am Service-Termin oder an einer Auftragsposition hängt. Das Formular ist schnell gebaut. Länger dauert die Entscheidung davor: Welche Antworten werden Felder am Asset oder Arbeitsauftrag, damit Wartungsplanung, Innendienst und ERP sie nutzen können, und welche bleiben Formularantworten für die Dokumentation? Teilen Sie lange Protokolle nach Maschinenvariante und Einsatzphase auf. Ein Formular mit 80 Prüfpunkten, von denen die meisten ausgeblendet sind, lässt sich schwer testen und schwer ändern.

Was ist Data Capture in Field Service?

Data Capture ist die Formularfunktion der Field Service App im Außendienst. Laut dem Trailhead-Modul Data Capture: Quick Look1 baut Data Capture direkt auf dem Flow Builder auf, also dem Werkzeug, das Admins schon für Automatisierung nutzen. Die Formulare laufen nativ in der App und lassen sich an Arbeitsaufträge, Service-Termine und Auftragspositionen hängen.

Was ein Formular enthalten kann:

• Felder und Eingaben: Text, Checkboxen, Lookups und Unterschrift.
• Bedingte Sichtbarkeit: Felder erscheinen oder verschwinden je nachdem, was der Techniker schon eingegeben hat.
• Medien: Fotos, Markierungen auf Fotos und Bildraster.

Für den Einsatz vor Ort zählen zwei Eigenschaften mehr als die Bausteine. Die Formulare funktionieren offline mit einer eigenen Offline-Engine, und die automatische Speicherung sichert jede Eingabe. Ein Techniker kann ein Formular an der Maschine schließen und später weitermachen. Jede Übermittlung wird protokolliert, online wie offline.

Voice to Form ist seit Spring ’26 allgemein verfügbar

Der Stand ändert sich mit jedem App-Release, deshalb lohnt der genaue Blick.

• App-Release 260.0 (Spring ’26). Der Release-Beitrag von Salesforce in der Trailblazer Community2 kennzeichnet Data Capture Voice to Form als GA. Techniker diktieren, die App schreibt mit und füllt die Formularfelder. Derselbe Beitrag nennt eine Lookup-Komponente, die auch offline funktioniert, eine Vorschau für mehrere Bilder und die Möglichkeit, Formulare von Assets, eigenen Objekten und mobilen Zeiterfassungen aus zu starten. Diese Punkte tragen im Beitrag kein GA-Kennzeichen. Prüfen Sie ihren Stand in Ihrer Org, bevor Sie damit planen.
• Winter ’27. Die Release-Highlights auf Trailhead3 ergänzen Voice to Form auf Spanisch, Japanisch, Italienisch, Französisch und Deutsch.

Spracheingabe auf Deutsch macht die Funktion für viele Serviceorganisationen im DACH-Raum interessant. Sie verarbeitet aber die Sprache von Beschäftigten, und damit kommen Datenschutz und, wo vorhanden, der Betriebsrat ins Spiel. Diese Fragen habe ich in Salesforce Field Service Mobile: Führung und Sprache beschrieben. Für das Formular heißt das: Legen Sie fest, welche Felder per Sprache gefüllt werden dürfen und welche Werte der Techniker von Hand bestätigt, etwa einen sicherheitsrelevanten Messwert.

Welche Antworten sollten Felder werden?

Diese Entscheidung würde ich vor dem ersten Formular treffen. Eine Formularantwort reicht, um festzuhalten, was geprüft wurde. Ein Wert, den später jemand auswertet, gehört in ein Feld am Asset oder am Arbeitsauftrag, denn Berichte, Wartungspläne und Schnittstellen arbeiten mit Feldern.

Antwort im Protokoll	Wohin sie gehört	Warum
Betriebsstunden oder Zählerstand	Feld am Asset	Wartung nach Nutzung liest es
Messwerte mit Verlauf (Druck, Temperatur)	Feld am Asset oder Arbeitsauftrag	Vergleich über mehrere Einsätze
In Ordnung oder nicht pro Prüfpunkt	Formularantwort	Nachweis der Prüfung
Gesamtergebnis der Prüfung	Feld am Arbeitsauftrag	Auswertung und Abrechnung
Gefundener Mangel	Neue Auftragsposition oder Folgeauftrag	Wird geplant und disponiert
Verbrauchte Teile	Products Consumed am Arbeitsauftrag	Fahrzeuglager und ERP
Unterschrift des Kunden	Formular und Servicebericht	Nachweis der Abnahme

Aus der Tabelle folgen zwei Regeln. Ein Formular fragt nichts ab, was schon am Asset oder Arbeitsauftrag steht, etwa Seriennummer, Kunde oder Maschinentyp. Und Verbrauch wird als Products Consumed gebucht, nie als Freitextfeld im Formular, sonst sehen Fahrzeuglager und ERP ihn nicht.

Messwerte am Asset verbinden das Formular mit der Wartungsplanung. Wie Wartungspläne und Entitlements zusammenspielen, steht in Field Service: Wie bildet man Wartungsverträge ab?. Das ist klassische Architekturarbeit und gehört der Serviceorganisation genauso wie der IT.

Wie hängt das Formular mit dem Servicebericht zusammen?

Data Capture sammelt die Daten. Das PDF, das der Kunde bekommt, entsteht im Document Builder. Der Document Builder arbeitet auf Arbeitsaufträgen, Auftragspositionen und Service-Terminen, wie in Salesforce Service Documents: reicht der Document Builder? beschrieben. Braucht der Kunde die Prüfergebnisse im Bericht, klären Sie im ersten Sprint, wie die Antworten in die Vorlage kommen. Werte, die als Feld am Arbeitsauftrag stehen, lassen sich direkt in die Vorlage setzen.

Prüfberichte mit viel bedingtem Inhalt können über den Document Builder hinauswachsen. Dann ist ein eigenes Prüfdokument aus Document Generation oder einem AppExchange-Tool die bessere Lösung, und das Formular liefert weiterhin die Daten.

Rechenbeispiel: 80 Prüfpunkte, drei Varianten

Alle Zahlen sind Annahmen. Ein Maschinenbauer nimmt Verpackungsmaschinen in drei Varianten in Betrieb. Das Papierprotokoll hat 80 Prüfpunkte auf zwölf Seiten, dazu eine Seite für die Abnahme durch den Kunden. Heute füllt der Techniker es von Hand aus, scannt es abends ein, und der Innendienst tippt die Messwerte ins ERP.

Als ein einziges Formular enthielte es jeden Prüfpunkt jeder Variante, und die bedingte Sichtbarkeit würde die meisten ausblenden. Jede Änderung an einer Variante würde das Formular für alle drei berühren. Ich würde es aufteilen:

• Formular 1, allgemeine Prüfungen (30 Punkte). Aufstellort, Stromversorgung, Schutzeinrichtungen, Not-Halt. Für jede Variante gleich, am Service-Termin.
• Formular 2, Variantenprüfung (35 Punkte). Ein Formular pro Variante, an der Auftragsposition für den Inbetriebnahmeschritt dieser Variante. Messwerte wie Taktzahl und Siegeltemperatur landen in Feldern am Asset.
• Formular 3, Abnahme (15 Punkte). Offene Punkte, Einweisung des Kunden, Unterschrift. Das Gesamtergebnis geht in ein Feld am Arbeitsauftrag.

Eine Maschine bekommt damit weiterhin 80 Prüfpunkte, aber jedes Formular ist kurz genug, um es zu testen. Mängel aus Formular 2 werden Auftragspositionen, und die Disposition sieht die Folgearbeit.

Den größten Gewinn hat in diesem Beispiel der Innendienst. Nach der Synchronisation stehen die Messwerte am Asset, niemand tippt sie mehr ab, und das Gesamtergebnis am Arbeitsauftrag zeigt, ab wann die Rechnung gestellt werden kann. Ändert sich bei einer Variante ein Grenzwert, passt der Admin nur das Formular dieser Variante an und testet nur dieses.

Ein Protokoll mit hohem Volumen auswählen

Formulare, Offline-Daten und Servicebericht bilden zusammen Kapitel 3 der Masterclass Field Service. Für das erste Formular würde ich so vorgehen:

1. 01

   Ein Protokoll auswählen

   Eines mit hohem Volumen, etwa die Jahreswartung Ihres häufigsten Maschinentyps.

2. 02

   Jede Frage markieren

   Als Feld, Formularantwort, Auftragsposition oder "schon bekannt". Die letzte Gruppe streichen.

3. 03

   Felder abstimmen

   Mit Innendienst und ERP-Team, bevor jemand den Flow Builder öffnet.

4. 04

   Offline bauen und testen

   Unter iOS und Android, mit einem internen und einem Partnertechniker.

5. 05

   Voice to Form ergänzen

   In einem eigenen Schritt, wenn Datenschutz und Betriebsrat zugestimmt haben.

Quellen3

1. 1Trailhead-Modul Data Capture: Quick Look (öffnet in einem neuen Tab)trailhead.salesforce.com
2. 2Release-Beitrag von Salesforce in der Trailblazer Community (öffnet in einem neuen Tab)trailhead.salesforce.com
3. 3Release-Highlights auf Trailhead (öffnet in einem neuen Tab)trailhead.salesforce.com