Salesforce Document Builder: fünf Grenzen und Workarounds

Der Salesforce Document Builder erstellt den Servicebericht im Field Service mit Unterschrift, Fotos und Offline-Unterstützung. In der Praxis hat er aber fünf Grenzen: Die Vorlagenwahl ist umständlich, der Dateiname steht fest, es gibt keinen E-Mail-Versand, nichts belegt Sprache und Vorlage vor, und das Styling ist einfach. Keine davon ist ein Grund, ein weiteres Tool zu kaufen. Jede lässt sich mit einem Flow oder einer kleinen Lightning Web Component schließen. Hier zeige ich, wie ich sie in meinen Projekten löse.

Warum sind die Grenzen des Document Builder wichtig?

In meinem ersten Artikel zu Service Documents habe ich beschrieben, was der Document Builder ist, was er kostet und wann Sie stattdessen ein Tool zur Dokumentenerstellung brauchen. Kurz gesagt: Für den Servicebericht vor Ort ist er die richtige Wahl, weil er in der Field-Service-Lizenz steckt und offline funktioniert.

Die offizielle Liste der Limits nennt technische Grenzen wie 50 Seiten pro Dokument oder drei unterstützte Objekte. Was sie nicht nennt, sind die Lücken, die erst im ersten Test mit Technikern und Serviceinnendienst auffallen. Sie sind klein, entscheiden aber darüber, ob die Nutzer den Bericht annehmen. Ein Techniker, der nach jedem Einsatz die richtige Vorlage suchen muss, oder ein Innendienst, der jedes PDF von Hand umbenennt, fragt bald nach dem alten Papierformular.

Die gute Nachricht: Der Document Builder steht auf derselben Plattform wie alles andere in Salesforce. Flows und Lightning Web Components (LWC, der Standardweg für eigene Oberflächenkomponenten) schließen alle fünf Lücken ohne zusätzliche Lizenz.

Grenze 1: Welche Vorlage soll der Techniker wählen?

Die Vorlage auf Arbeitsauftrag und Servicetermin ist nur ein Textfeld. Es verweist auf die Lightning-Seite (FlexiPage), die das Layout der Vorlage enthält. Für einen Techniker ist das ein technischer Wert ohne Bedeutung. Gibt es mehrere Vorlagen, etwa pro Auftragsart oder pro Land, wählen Nutzer die falsche oder gar keine.

Workaround: Legen Sie die Auswahl hinter einen Screen Flow oder eine Quick Action. Der Flow zeigt eine kurze Liste mit lesbaren Namen wie “Jahreswartung” oder “Reparatur mit Ersatzteilen” und schreibt den richtigen Wert in das Feld. Noch besser: Filtern Sie die Liste nach dem Einsatz, damit der Techniker nur Vorlagen sieht, die zur Auftragsart passen.

Grenze 2: Warum kann ich den Dateinamen nicht festlegen?

Der Document Builder benennt die erzeugte Datei selbst. Ein Muster wie Auftragsnummer, Kunde und Datum lässt sich nicht hinterlegen. Für den Innendienst ist das lästig, denn das PDF landet im Postfach des Kunden, im ERP oder in einem Dokumentenarchiv, und niemand erkennt am Dateinamen, zu welchem Einsatz es gehört.

Workaround: Ein datensatzgesteuerter Flow mit asynchronem Pfad. Er startet, wenn das Dokument erstellt wurde, und benennt die Datei kurz danach um. Er muss asynchron laufen, also kurz nach der Erstellung, damit die Datei schon existiert, wenn der Flow sie umbenennt. Die Namensregel liegt dann an einer Stelle, und ein Admin kann sie ohne Code ändern.

Grenze 3: Wie verschicke ich den Servicebericht per E-Mail?

Im Standard verschickt der Document Builder das Dokument nicht. Der Techniker erstellt das PDF, der Kunde unterschreibt, und dann liegt der Bericht am Arbeitsauftrag. In den meisten Serviceorganisationen erwartet der Kunde den Bericht noch am selben Tag per E-Mail, oft als Grundlage für die Rechnungsfreigabe.

Workaround: Ein Flow, der startet, wenn das Dokument fertig ist, und es als Anhang verschickt. Im Flow legen Sie fest, wer es bekommt, zum Beispiel den Kontakt am Arbeitsauftrag oder eine zentrale Serviceadresse des Kunden, welche E-Mail-Vorlage genutzt wird und in welcher Sprache. Zusammen mit Grenze 2 kommt die E-Mail mit einem Dateinamen an, den der Kunde ablegen kann.

Grenze 4: Lassen sich Sprache und Vorlage vorbelegen?

Ja, per Flow. Im Standard wählt der Techniker Vorlage und Sprache, wenn er das Dokument erstellt. Das ist ein weiterer Schritt vor Ort und eine weitere Fehlerquelle, etwa ein deutscher Bericht für einen Kunden in Frankreich.

Workaround: Setzen Sie beide Felder per Flow auf Servicetermin und Arbeitsauftrag. Die Sprache kann vom Account oder vom Servicegebiet kommen, die Vorlage von der Auftragsart oder vom Asset. Der Techniker prüft dann nur noch die Vorschau und holt die Unterschrift ein.

Grenze 5: Wie weit kommt man beim Styling?

Die Standardkomponenten decken Felder, Tabellen, Bilder und Unterschriften ab. Alles andere, etwa eine horizontale Linie zwischen Abschnitten oder eine andere verknüpfte Liste, fehlt. Und einige Grenzen aus der offiziellen Liste treffen den Bericht direkt: Lange Textfelder lassen sich in verknüpften Listen nicht anzeigen, und die Feldbezeichnungen sind die aus dem Datenmodell.

Workaround: Die Vorlage ist eine Lightning-Seite und damit aus Komponenten wie aus Bausteinen aufgebaut. Eigene LWCs lassen sich per Plug and Play neben die Standardkomponenten setzen. Zwei Beispiele aus meinen Projekten:

• Grafische Elemente. Eine horizontale Trennlinie oder ähnliche Zwischenelemente zwischen Abschnitten. Klein, aber der Bericht wirkt wie ein gestaltetes Dokument statt wie ein Datenexport.
• Eigene verknüpfte Liste. Eine Komponente, die auch Felder mit mehr als 255 Zeichen anzeigt, etwa die Arbeitsbeschreibung des Technikers, und Feldbezeichnungen nur für den Bericht überschreibt. Das Standardfeld “Erstellt von” erscheint im Dokument dann als “Techniker”, ohne dass sich die Bezeichnung in der ganzen Org ändert.

Salesforce weist darauf hin, dass LWCs für Service Documents ein eigenes Druck-Styling brauchen, beschrieben im Entwicklerleitfaden für eigene Komponenten in Service Documents (öffnet in einem neuen Tab). Komponenten aus der mobilen App lassen sich nicht einfach wiederverwenden. Planen Sie sie als eigene kleine Bibliothek.

Funktionieren die Workarounds offline?

Das Hauptargument für den Document Builder ist die Offline-Erstellung an der Maschine des Kunden, also dürfen die Workarounds das nicht kaputt machen. In der Praxis tun sie das nicht. Eigene Komponenten lesen ihre Daten über GraphQL (die Abfrageschnittstelle, die die Field Service App für Offline-Daten nutzt), deshalb liegen die Daten ohne Verbindung auf dem Gerät. Die Vorschau in der mobilen App zeigt die Informationen korrekt an, einschließlich der eigenen verknüpften Liste und der überschriebenen Bezeichnungen.

Die Flows aus Grenze 2 und 3 laufen nach der nächsten Synchronisierung auf dem Server. Dort gehören sie hin: Der Techniker wartet vor Ort nicht auf die E-Mail, und die umbenannte Datei und die E-Mail folgen, sobald das Gerät wieder online ist. Die Flows für Grenze 4 können laufen, wenn die Disposition den Einsatz plant. Dann liegen die Werte auf dem Gerät, bevor der Techniker losfährt.

Was ich für den Rollout empfehle

• Planen Sie die fünf Themen in den ersten Sprint ein. Sie sind klein, gehören aber zur Definition of Done des Serviceberichts und nicht in eine spätere Phase.
• Halten Sie die Flows an einer Stelle. Ein Flow für die Vorbelegung, einer für Umbenennung und E-Mail. Dann findet ein Admin die Regeln und kann sie ändern.
• Bauen Sie die LWCs als kleine Bibliothek. Trennlinie, verknüpfte Liste, eventuell ein Kopf mit Logo. Wiederverwendbar in jeder Vorlage.
• Testen Sie offline mit echten Geräten. Einschließlich der Vorschau, auf iOS und Android, bevor der erste Techniker live geht.

Wenn Sie einen Field-Service-Rollout planen und den Servicebericht von Anfang an richtig aufsetzen wollen, sehen Sie sich meine Leistungen an oder schreiben Sie mir.