General - Frequenty Asked Questions
Q: How can I verify who the document was sent to?
- The Contact field links to the signer's profile.
Q: What is the "Token" and "Signature URL" used for?
- Token: A unique alphanumeric string used to secure the specific signing session.
- Signature URL: The direct link sent to the signer to access the document via the secure portal.
Q: How do I know if the document has been viewed?
- Acknowledged and Viewed?: Displays the total count of times the document was accessed.
- First/Last View Date and Time: Provides precise timestamps of the signer's first and most recent interaction with the document.
Q: What do the different checkboxes (Is Signed, Is Expired) indicate?
- Is Signed: When checked, this confirms the signature process is complete.
- Is Expired: Indicates if the document has passed its Expiration Date (e.g., 12/6/2025).
- Status: Reflects the overall stage of the request, such as Completed.
Q: Was the document protected by a PIN - e signature request?
- If the Require PIN checkbox is selected, the signer was required to enter a security code before accessing the document.
Q: How long did it take for the document to be signed in e signature request?
- You can compare Request Sent On (e.g., 11/6/2025, 8:01 PM) against Request Signed On (e.g., 11/7/2025, 1:13 PM) on e signature request record to determine the turnaround time.
Q: Where was the signature placed in e signature request?
- The Signature Placeholder (e.g., [Signature1]) indicates the specific tag in the document template where the signature will be captured.
Q: How does the system handle multiple signers on e signature request?
- Previous Signer Has Signed?: Indicates if the preceding person in the workflow has finished their task.
- Auto Send To Next Signer: If enabled, the system automatically routes the document to the next person in line once the current signer completes their part.
Q: Why is there a separate "FullName" field in the e signature log?
- This captures the exact name the user typed in the name signing on the document.
Q. What does the "DateTimeText" field represent in the log?
- It records the precise moment (in GMT) that the signature image holds (e.g., 2025-11-07 07:43 GMT). This provides a standardized time reference regardless of the signer's local time zone.
Q. What is the purpose of the "Token" in the log?
- The token links this specific acknowledgement log back to the original E Signature Request. It proves that the viewer of the document is the same person who received the secure link.
Q: What happens if "Do Not Share The Record" is checked?
- This is a privacy flag. If enabled, it restricts the visibility of this specific audit log to ensure sensitive viewer data isn't exposed to unauthorized internal users only according to the sharing settings YOU/Subscriber have defined in your org.
Q: How is the "Status" used in the e signature log?
- It tracks the state of the signature log record itself (e.g., New). If a signer were to decline the disclosure, this might reflect a different status ‘Rejected’ and capture a Rejection Reason.
Q: Where is the actual signature image data stored in the e signature log record?
- Field: Signature_Image_Text__c
- Answer: This field stores the encoded string of the signature. It is what allows the system to automatically capture and display the signature on the document without requiring a manual date input, as the timestamp is often baked into this data.
Q: How can we verify the location or device of the signer for legal purposes in e signature log?
- Field: SIgnerIPAddress__c
- Answer: This field automatically captures the IP Address of the device used at the moment of submission. This serves as a critical layer of the audit trail, proving where the signature originated.
Q: Is there a way to view the signed content directly within a record field?
- Field: Signed_Document__c
A: This Rich Text Area stores the final version of the document post-signature by that signer.
Q: How can we configure email notifications to alert us each time a signer opens the document?
A: Currently, DRTE does not trigger a standard email notification simply for "opening" a link. However, because a document is only loaded after a signer acknowledges the E-Signature Disclosure, a record is created for every unique session. To receive alerts, you can set up a workflow or trigger on the "E-Signature Disclosure" object to send an email notification whenever a new record is generated.
Q: Is it possible to track the total number of times the document has been accessed?
A: Yes. Since every visit to an unsigned document requires a new acknowledgement, you can track access by counting the number of E-Signature Disclosure records associated with that specific document link. Or using Acknowledged and Viewed? Field on e signature log record : Displays the total count of times the document was accessed.
Note: Access tracking is session-based. If a user acknowledges the disclosure, views the document, and then refreshes their browser, a new acknowledgement (and record) will be required.
Q: How do we set up an automatic email notification to be sent once the signer has successfully signed the document?
A: This functionality is not a default setting within the standard DRTE package. To enable "Signed" notifications, a customization must be implemented.
Recommended Approach:
- Create a custom trigger or flow that monitors the e signature request record is_signed checkbox status.
Q: How do we configure the document to automatically retrieve the "Date of Signed" rather than having the signer choose it manually?
A: No manual configuration or signer input is required for this. The DRTE system is designed to be "set it and forget it" regarding timelines. The Signature Image itself automatically captures and embeds the precise date of the signature onto the document the moment it is submitted.
Key Benefits of this Automation:
- Data Integrity: Prevents signers from back-dating or forward-dating documents.
- Efficiency: Reduces the number of fields a signer needs to interact with, leading to faster completion rates.
- Compliance: Provides a hard-coded audit trail directly on the document face.
Q: Can we manually edit a document just before starting the signature workflow?
- A: Yes. To enable this, you must modify the DRTE Editor properties on the record page by unchecking the Read Only property. This allows you to make manual adjustments "on the fly" before the signature request is officially generated.
Q: How can we edit the content of the email invitation for specific cases instead of using a static template?
- A: For the % of cases requiring custom messaging, use Salesforce’s native email capability.
- Enable email on e signature request object.
- Insert your standard template for sending signature request into the email composer and make your manual edits before hitting send.
- Crucial Step: After sending the email manually, you must manually update the Status of the E-Signature Request record to "Sent for Signature". This ensures the record sharing settings are correctly updated so the guest user can access the document.
Q: How does the signed document get saved into the Salesforce Files section?
- A: This is handled via an subscriber built automated Salesforce Flow triggered by the ESignature Log record.
- The Logic: The flow runs on a Scheduled Path after a new log is inserted, as the signed workflow is triggered by the Guest User. Guest user will have have elevated permissions, so you need to use Platform Event technique to generate document and save in files through the customisation.
- The Action: It uses a managed package action to generate the PDF.
- The Data Source: The flow pulls content from the pscdnyrichtext__Signed_Document__c field on the pscdnyrichtext__ESignature_Log__c object to create the final file.
Q: If a Salesforce field is blank, the PDF shows the placeholder text (e.g., {{Account__r.Phone}}). How do we make it appear as a blank space instead?
A: By default, DRTE treats all merge fields as essential data points. To hide placeholders when data is missing, you must use DRTE Dynamic Content logic to swap sections based on whether the field is populated.
Step-by-Step Configuration:
- Locate the Section: Go to the Document Template record, navigate to the Related Tab, and find the specific Section record containing the field that might be empty.
- Update the "Populated" Section: Modify the SOQL query for this section to include a WHERE condition specifying that the field is not null.
- Create the "Empty" Section: Clone the original section record.
- Edit the HTML: In the new cloned section, edit the HTML to remove the merge field placeholder entirely.
- Set the "Null" Condition: Update the SOQL query of this new section to include a condition that only runs when that specific field is null.
Result: DRTE will dynamically choose which section to render. If the field has data, it shows the version with the merge field; if it is empty, it shows the version with the blank space.