Documentation développeur
Automatiser TrueSign depuis un Flow, un déclencheur ou du code Apex, et interroger ses données.
Il n'y a pas d'API REST TrueSign : le package s'intègre par les mécanismes standard de la plateforme — actions invocables, objets SOQL, événements de plateforme. C'est délibéré : votre org reste le seul point d'entrée, et il n'y a rien de plus à authentifier.
Actions invocables
Utilisables depuis un Flow, Process Builder, une stratégie Einstein Next Best Action ou directement en Apex.
Envoyer pour signature
« TrueSign — Envoyer pour signature »
| Entrée | Type | Rôle |
|---|---|---|
recordId | Id — requis | L'enregistrement source (Opportunité, Compte, Contact, objet personnalisé…) |
templateId | Id | Le modèle d'envoi à utiliser |
emailSubjectOverride | String | Remplace l'objet de l'e-mail du modèle, pour cet envoi |
emailMessageOverride | String | Remplace le corps de l'e-mail du modèle |
| Sortie | Type |
|---|---|
signatureRequestId | Id de la demande créée |
success | Boolean |
errorMessage | String — renseigné en cas d'échec |
Cette action effectue un appel sortant. Dans un Flow déclenché par enregistrement, choisissez le chemin asynchrone — sinon la plateforme refuse l'appel (« uncommitted work pending »).
Générer un document
« TrueSign Gen — Générer document »
| Entrée | Type | Rôle |
|---|---|---|
recordId | Id — requis | L'enregistrement source |
genTemplateId | Id | Le modèle Gen |
| Sortie | Type |
|---|---|
contentVersionId | Id du document produit |
signatureSent | Boolean — vrai si l'envoi en signature a suivi |
success / errorMessage | — |
Si le modèle Gen porte l'option Envoi pour signature, la génération enchaîne automatiquement sur l'envoi.
Autres actions
| Action | Usage |
|---|---|
| Relancer une invitation | Renvoyer le lien à un destinataire encore en attente |
| Génération en masse | Générer pour un lot d'enregistrements |
| Reprise d'une génération en masse | Rejouer les seuls échecs d'un lot |
| Publication Chatter | Poster sur l'enregistrement au changement de statut |
Objets exposés
Interrogeables en SOQL, utilisables dans vos rapports, Flows et automatisations.
| Objet | Contenu |
|---|---|
TES_SignatureRequest__c | La demande : statut, document, expiration, historique d'actions, lien vers l'enregistrement source |
TES_SignatureRecipient__c | Chaque destinataire : rôle, statut individuel, date de signature, groupe |
TES_EnvelopeTemplate__c | Les modèles d'envoi — voir la référence des options |
TES_MergeFieldMapping__c | Les champs de fusion d'un modèle |
TES_ConnectMapping__c | Les mappings de writeback |
TES_GenTemplate__c / TES_GenObjectMapping__c | Modèles Gen et leurs listes liées |
TES_SigningGroup__c / TES_SigningGroupMember__c | Les groupes de signataires |
TES_BulkSend__c | Le suivi d'un lot d'envoi en masse |
TES_Job__c / TES_Log__c / TES_AuditLog__c | Jobs, journaux techniques, piste d'audit |
Statut, compteurs, document signé : seul le package les met à jour, après validation métier. Ne tentez pas de les forcer par DML ou Data Loader — vous obtiendriez une demande dont l'état ne correspond plus à la réalité chez le fournisseur. Voir Architecture de sécurité.
Permissions personnalisées
Vos automatisations peuvent tester les droits avec FeatureManagement.checkPermission :
| Permission | Autorise |
|---|---|
TES_Send_Access | Envoyer pour signature |
TES_BulkSend_Access | L'envoi en masse (en plus du droit d'envoi) |
TES_Gen_Access | La génération documentaire |
TES_Template_Access | L'édition des modèles |
TES_Approve_Any | Décider à la place d'un approbateur |
TES_Admin_Access | La configuration de l'org |
Elles sont portées par les permission sets décrits dans Gestion des utilisateurs. Les gardes sont appliquées côté serveur : une action invocable hérite des droits de l'utilisateur qui déclenche le Flow, et un utilisateur sans droit d'envoi ne crée aucune demande — y compris par l'envoi automatique qui suit une génération.
Événements de plateforme
| Événement | Usage |
|---|---|
TES_LogEvent__e | Publié à chaque changement de statut. C'est ce qui permet aux composants de se rafraîchir d'eux-mêmes — vous pouvez vous y abonner de la même façon |
TES_OtpEvent__e | Interne au parcours de signature weSign |
S'abonner à TES_LogEvent__e requiert le droit de lecture sur l'événement, porté par les permission sets utilisateur.
Déclencher depuis un enregistrement
Le schéma classique — un contrat passe à « Prêt à signer », la demande part :
Le Screen Flow fourni implémente déjà ce garde-fou anti-doublon : il ne propose pas l'envoi si une demande est déjà en cours sur l'enregistrement. Réutilisez-le plutôt que de le réécrire.
Bonnes pratiques
- Une transaction, un envoi. Chaque envoi effectue des appels sortants ; n'en enchaînez pas plusieurs dans la même transaction Apex.
- Testez les droits, pas les rôles.
FeatureManagement.checkPermission('TES_Send_Access')reste vrai quelle que soit la façon dont l'utilisateur l'obtient. - Lisez le statut, ne le calculez pas. Le statut de la demande est la seule source de vérité ; il est mis à jour par le fournisseur via le webhook.
- Consultez la piste d'audit plutôt que de reconstruire une chronologie : chaque action y est horodatée avec son auteur.