Document Builder Salesforce Field Service : créer des documents de service PDF personnalisés et multilingues

Document Builder transforme l’expérience client post-intervention. Son adoption par une entreprise offre des avantages tangibles, notamment en modernisant l’interaction client après une intervention, tout comme l’implémentation d’une API Apex REST permet l’autonomie du client dans la réservation de créneaux.

• Marque et personnalisation : Document Builder est l’outil de FSL permettant de créer des documents de service plus personnalisés, dynamiques et mieux marqués que les Rapports de Service (Service Reports) standard.
• Expérience client améliorée : L’outil permet la visualisation des documents et la collecte des signatures directement via l’application mobile Field Service, offrant ainsi une expérience fluide et moderne.
• Accessibilité et efficacité : Les PDF peuvent être générés à la fois depuis le site de bureau et l’application mobile. Le document de service généré peut être traduit dans n’importe quelle langue prise en charge par la plateforme Salesforce, permettant d’adresser la langue préférée des clients individuels.
• Flexibilité du contenu : Le Template Builder facilite la construction des modèles de documents grâce au glisser-déposer de sept composants standards, dont Grille, Image, Galerie d’images, Numéros de page, Tableau des enregistrements associés, Texte riche et Signature.

Des profils techniques et opérationnels !

 

Cet outil s’adresse à une audience variée, allant des administrateurs configurant l’expérience aux travailleurs mobiles qui génèrent les documents finaux sur le terrain.

• Profils techniques (Administrateurs Salesforce) : Seuls les administrateurs Salesforce (avec accès à la configuration) peuvent accéder à l’expérience du builder et créer des modèles de documents de service. Ils gèrent les paramétrages, les licences, et l’intégration des logiques dynamiques (Flows, Apex).
• Développeurs et administrateurs avancés : L’outil permet de gérer la complexité et les cas d’usage spécifiques en permettant l’intégration de composants web Lightning (LWC) personnalisés dans les modèles. L’administrateur peut configurer la population dynamique du champ Service Document Template via un déclencheur Apex ou un Flow Builder, en fonction de la logique métier (par exemple, lors de l’insertion d’un Ordre de Travail avec un statut spécifique).
• Utilisateurs de terrain et dispatchers : Ces profils peuvent générer des documents de service PDF s’ils disposent des licences Field Service Dispatcher ou Field Service Mobile.

L’implémentation de Document Builder repose sur une configuration stricte et l’utilisation de composants spécifiques au sein de l’environnement Field Service.

 

1. Configuration et licences

Document Builder doit être activé dans les Paramètres Field Service. Une fois activé, il est important de noter qu’un utilisateur ne peut se voir attribuer l’accès qu’à Document Builder ou aux Rapports de Service standard, car l’octroi de l’autorisation Document Builder masque le bouton Create Service Report.

 

Chaque organisation bénéficie d’une allocation de 250 documents par utilisateur et par mois pour les licences Field Service Dispatcher, Field Service Dispatcher Plus Login-Based, Field Service Mobile et Field Service Mobile Login-Based.

 

 

2. Création et structure des modèles

Le Template Builder permet de concevoir le document en utilisant divers composants standards tel que des champs des champs.

 

 

3. Contraintes et limites techniques

Les documents générés via Document Builder sont soumis à plusieurs limites :

• Taille maximale d’un Service Document : 300 Mo.
• Taille maximale d’un PDF généré : 100 Mo.
• Nombre maximal de pages pour un PDF : 50 pages.
• Génération mobile : Sur iOS, les documents peuvent être créés à partir de Work Order, Work Order Line Item et Service Appointment. Sur Android, ils peuvent être créés à partir de Work Order et Service Appointment.
• Seul le noir apparaît sur les documents dans les champs de texte riche.
• Les champs de zone de texte long ne sont pas pris en charge pour les composants de liste associée dans Document Builder.

 

Document Builder excelle dans la localisation des documents de service, offrant la possibilité de traduire le document final en n’importe quelle langue prise en charge par la plateforme Salesforce. Cette capacité permet de s’assurer que la communication est faite dans la langue préférée du client individuel.

 

Mécanisme de traduction via :

1. Le processus de traduction s’appuie principalement sur le champ Service Report Language (Langue du Rapport de Service), qui est situé sur l’objet Ordre de Travail (Work Order).
2. Sélection de la langue : Lors de la génération du document de service, l’utilisateur sélectionne la langue souhaitée dans le champ Service Report Language.
3. Héritage linguistique : La langue est définie uniquement sur les ordres de travail ; tous les rendez-vous de service (Service Appointments) rattachés à cet ordre de travail sont traduits dans la même langue.
4. Langue par défaut : Si le champ Service Report Language sur l’Ordre de Travail est vide, le rapport est généré dans la langue par défaut de l’utilisateur qui crée le rapport.
5. Configuration préalable : Pour que les langues apparaissent comme des options dans le champ, elles doivent être configurées et activées via l’outil Translation Workbench de Salesforce.

 

Limitations de la fonctionnalité de traduction

 

Malgré son efficacité, la traduction dans Document Builder est soumise à des restrictions importantes :

• Langues RTL (Right-to-Left) : Les langues qui se lisent de droite à gauche (comme l’arabe ou l’hébreu) sont certes traduites, mais le formatage et la mise en page du document ne sont pas pris en charge.
• Contenu riche : Dans les champs de texte riche (Rich Text), seules les étiquettes personnalisées (custom labels) sont traduites. Cela signifie que le texte statique ou les valeurs de champs de texte long insérées directement ne bénéficient pas de la traduction automatique.
• Aperçus mobiles : Lors de l’utilisation de l’application mobile, seule la langue définie dans le champ Service Report Language est disponible pour l’utilisateur au moment du priming des données pour le mode hors ligne.

Le parcours de création et de signature d’un document de service avec Document Builder est largement numérisé, souvent initié via l’application mobile.

 

1. Préparation du modèle

L’administrateur crée et active le modèle (ex : Service Appointment Debrief). Le modèle par défaut est utilisé, sauf si un Service Document Template ID est spécifié sur l’enregistrement (Ordre de Travail, Ligne d’Ordre de Travail, Rendez-vous de Service) ou sur le type de travail (Work Type).

 

2. Génération du document (mobile ou desktop)

L’utilisateur accède à l’Ordre de Travail ou au Rendez-vous de Service et clique sur Create Service Document.

 

3. Signature et confirmation en temps réel

Sur l’application mobile Field Service, le travailleur est redirigé vers un aperçu où il peut collecter la signature numérique du client. Si la signature ne peut être collectée (ex: client absent), il peut enregistrer la raison.

Salesforce propose également la Signature sans Contact (Contactless Signature) via Appointment Assistant, qui permet au client de signer le rapport de service sur son propre appareil, éliminant l’usage de l’appareil du travailleur mobile.

 

4. Enregistrement final et archivage

Une fois généré, le PDF final est mis en file d’attente (en ligne ou hors ligne, puis synchronisé). Le document est enregistré dans la liste associée Rapports de Service (Service Reports) sur l’enregistrement parent. Si la langue du rapport de service est sélectionnée lors de la génération, le document est traduit dans la langue préférée.