Developer documentation

Automating TrueSign from a Flow, a trigger or Apex code, and querying its data.

What TrueSign does not expose

There is no TrueSign REST API: the package integrates through the platform's standard mechanisms — invocable actions, SOQL objects, platform events. This is deliberate: your org remains the only entry point, and there is nothing extra to authenticate.

Invocable actions

Usable from a Flow, Process Builder, an Einstein Next Best Action strategy, or directly from Apex.

Send for signature

"TrueSign — Send for signature"

Input	Type	Role
recordId	Id — required	The source record (Opportunity, Account, Contact, custom object…)
templateId	Id	The sending template to use
emailSubjectOverride	String	Overrides the template's email subject, for this send
emailMessageOverride	String	Overrides the template's email body

Output	Type
signatureRequestId	Id of the created request
success	Boolean
errorMessage	String — populated on failure

The Flow must be asynchronous

This action makes an outbound call. In a record-triggered Flow, choose the asynchronous path — otherwise the platform refuses the call ("uncommitted work pending").

Generate a document

"TrueSign Gen — Generate document"

Input	Type	Role
recordId	Id — required	The source record
genTemplateId	Id	The Gen template

Output	Type
contentVersionId	Id of the produced document
signatureSent	Boolean — true if a signature send followed
success / errorMessage	—

If the Gen template carries the Send for signature option, generation automatically chains into the send.

Other actions

Action	Usage
Resend an invitation	Re-send the link to a recipient still pending
Bulk generation	Generate for a batch of records
Bulk generation retry	Replay only a batch's failures
Chatter post	Post on the record when the status changes

Exposed objects

Queryable in SOQL, usable in your reports, Flows and automations.

Object	Contents
TES_SignatureRequest__c	The request: status, document, expiry, action history, link to the source record
TES_SignatureRecipient__c	Each recipient: role, individual status, signing date, group
TES_EnvelopeTemplate__c	Sending templates — see the options reference
TES_MergeFieldMapping__c	A template's merge fields
TES_ConnectMapping__c	The writeback mappings
TES_GenTemplate__c / TES_GenObjectMapping__c	Gen templates and their related lists
TES_SigningGroup__c / TES_SigningGroupMember__c	The signing groups
TES_BulkSend__c	Tracking of a bulk send batch
TES_Job__c / TES_Log__c / TES_AuditLog__c	Jobs, technical logs, audit trail

State fields are read-only by design

Status, counters, signed document: only the package updates them, after business validation. Do not try to force them through DML or Data Loader — you would end up with a request whose state no longer matches reality at the provider. See Security architecture.

Custom permissions

Your automations can test rights with FeatureManagement.checkPermission:

Permission	Allows
TES_Send_Access	Sending for signature
TES_BulkSend_Access	Bulk sending (on top of the sending right)
TES_Gen_Access	Document generation
TES_Template_Access	Editing templates
TES_Approve_Any	Deciding on behalf of an approver
TES_Admin_Access	Configuring the org

They are carried by the permission sets described in User management. The guards are enforced server-side: an invocable action inherits the rights of the user triggering the Flow, and a user without sending rights creates no request — including through the auto-send that follows a generation.

Platform events

Event	Usage
TES_LogEvent__e	Published on every status change. This is what lets the components refresh themselves — you can subscribe the same way
TES_OtpEvent__e	Internal to the weSign signing journey

Subscribing to TES_LogEvent__e requires read access to the event, carried by the user permission sets.

Triggering from a record

The classic pattern — a contract moves to "Ready to sign", the request goes out:

The bundled Screen Flow already implements that duplicate guard: it does not offer the send if a request is already in progress on the record. Reuse it rather than rewriting it.

Good practice

• One transaction, one send. Each send makes outbound calls; do not chain several in the same Apex transaction.
• Test rights, not roles. FeatureManagement.checkPermission('TES_Send_Access') stays true regardless of how the user obtained it.
• Read the status, do not compute it. The request status is the single source of truth; it is updated by the provider through the webhook.
• Consult the audit trail rather than rebuilding a timeline: every action is timestamped there with its author.