Participant
Last updated on
Feb 19, 2024
Overview
The Limited Document Visibility (LDV) settings allow an agreement to contain multiple files that are selectively visible to the recipients depending on which settings are enabled and how the agreement is configured.
Example use cases include:
- Sales agreements that require internal oversight or approval before being sent to the customer.
- New hire documentation to be delivered after the offer letter is accepted.
- HR documents that require internal processing outside the initial signer's scope.
Here's a quick video that captures the high-level use:
Availability:
Limited document visibility is available for the enterprise license plan only.
Configuration scope:
LDV can be enabled at the account and group levels.
Limited Document Visibility involves several particular terms:
User vs. UserID
- User is a generic term for anyone who accesses Adobe Acrobat Sign by direct login, federated authentication, or integration. A user may have multiple email addresses they use to authenticate to Acrobat Sign (thus, a user may have numerous userIDs).
- UserID is a specific, authenticated object in Adobe Acrobat Sign. The actual ID is a system-assigned number that ensures the identification of a unique (user) object. UserIDs are often equated to the email address as both are unique values in the system, but a user can change their email address; they may not change the userID. All assets are logically related to their creating userID.
Internal vs. External parties
- Internal parties are userIDs that are part of the same Acrobat Sign account as the sending userID.
- It's worth noting that users in the same company may be in different Acrobat Sign accounts. Acrobat Sign does not make assumptions based on email domains or company names. The only relevant association is if the userIDs are related to the same accountID.
- External parties identify any userID that isn't a member of the sending userIDs account.
- If the participant's email isn't listed in the User list for the account, the participant is external by definition.
How document visibility works
LDV rules can be enabled at the account and group level.
LDV rules only expose the file content explicitly assigned to any given recipient.
File content is assigned to a recipient by adding at least one field assigned to that recipient.
- LDV is file-based, not page-based. If a file has 40 pages, and the recipient has one field assigned to them on one page, the recipient can see all 40 pages of the file.
- If the file contains no fields for the recipient, the entire file is excluded from that recipient's view.
- If there are four files, and the recipient needs to see all four, then at least one field must be applied to one of the pages of each file.
- If page-level control is required, the file must be divided into individual files, each containing one page.
In the example to the right, there are two signers and two documents in an agreement.
Signer 1 sees both documents, as there is a field assigned on both docs (Field 1 and Field 2)
Signer 2 will only see Doc 2 because they don't have an assigned field on Doc 1.
- Doc 2 is visible because Field 3 is assigned to Signer 2.
Note:
LDV rules expect two prerequisites:
- There must be more than one recipient
- Recipients include any user added to the signature/approval process
- CC'd parties are not recipients.
- There must be more than one file added to the agreement
- Files are any attachments used to build the agreement (.doc, .xls, .pdf, PNG, etc.)
If either of the above requirements isn't true, LDV rules are suspended for that agreement.
Signers will only see files containing signature, initials or data entry fields assigned to them is the root control that enables the LDV experience and the set of subordinate controls. If this control is disabled, LDV as a whole is disabled in the recipient experience.
All recipients and CC'd parties see all files all the time.
|
|
During the signing process |
When the agreement is completed |
|---|---|---|
|
Sender |
All documents |
All documents |
|
Internal Recipient |
All documents |
All documents |
|
External Recipient |
All documents |
All documents |
|
Internal CC |
All documents |
All documents |
|
External CC |
All documents |
All documents |
|
External Archive Recipient |
NA |
All documents |
After enabling the root LDV control, there are three additional configurations to control visibility depending on your preferred experience:
When only Signers will only see files containing signature, initials or data entry fields assigned to them is enabled:
- The Sender can see all file content all the time
- Recipients can only see the files they are explicitly included in during signing, and after the agreement is complete
- CC'd parties do not see any file content.
|
Participant |
During Signing |
Completed Agreement |
|---|---|---|
|
Sender |
All documents |
All documents |
|
Internal Recipient |
Assigned documents |
Assigned documents |
|
External Recipient |
Assigned documents |
Assigned documents |
|
Internal CC |
None |
None |
|
External CC |
None |
None |
|
External Archive Recipient |
NA |
All documents |
When Signers and CCs in my account will see all files is enabled:
- All internal userIDs (relative to the sending user) can see all file content.
- External recipients only see the files content assigned to them, during signing and after the agreement is complete.
- External CC'd parties see no file content.
|
Participant |
During Signing |
Completed Agreement |
|---|---|---|
|
Sender |
All documents |
All documents |
|
Internal Recipient |
All documents |
All documents |
|
External Recipient |
Assigned documents |
Assigned documents |
|
Internal CC |
All documents |
All documents |
|
External CC |
None |
None |
|
External Archive Recipient |
NA |
All documents |
When Signers and CCs will see all files when receiving the signed agreement is enabled:
- Recipients only see their assigned file content during the signature process
- CC'd parties do not see any file content during the signature process
Once the agreement is completed, all recipients and CC'd parties can see all file content.
|
Participant |
During Signing |
Completed Agreement |
|---|---|---|
|
Sender |
All documents |
All documents |
|
Internal Recipient |
Assigned documents |
All documents |
|
External Recipient |
Assigned documents |
All documents |
|
Internal CC |
None |
All documents |
|
External CC |
None |
All documents |
|
External Archive Recipient |
NA |
All documents |
This configuration enables LDV rules and allows all internal userIDs (relative to the sender) to view all file content during the signing cycle.
When the agreement is complete, all users can view all file content
|
Participant |
During Signing |
Completed Agreement |
|---|---|---|
|
Sender |
All documents |
All documents |
|
Internal Recipient |
All documents |
All documents |
|
External Recipient |
Assigned documents |
All documents |
|
Internal CC |
All documents |
All documents |
|
External CC |
None |
All documents |
|
External Archive Recipient |
NA |
All documents |
If you are planning on accepting written signatures, you should enable this option, but be aware that LDV rules do not apply when a written signature is involved.
In all cases, when a written signature is involved, LDV rules are suspended for that agreement.
|
Participant |
During Signing |
Completed Agreement |
|---|---|---|
|
Sender |
All documents |
All documents |
|
Internal Recipient |
All documents |
All documents |
|
External Recipient |
All documents |
All documents |
|
Internal CC |
All documents |
All documents |
|
External CC |
All documents |
All documents |
|
External Archive Recipient |
NA |
All documents |
Using LDV with the REST API v6
The sender can use the REST API v6 to explicitly grant visibility to documents.
REST API v6 calls ignore all document visibility settings in the UI, as the API call overrides account/group level settings.
The only carry-over behavior is that the sender must specify a document label if it specifies a form field for a particular recipient.
POST /agreements REST API v6 endpoint has three parameters that can be used to control document visibility behaviors.
AgreementInfo
|
Parameter Name |
Type |
Required |
Description |
|---|---|---|---|
|
documentVisibilityEnabled |
Boolean |
No |
Optional document visibility parameter for the agreement. This parameter must be specified and set to true to enable document visibility. |
ParticipantSetInfo
|
Parameter Name |
Type |
Required |
Description |
|---|---|---|---|
|
visiblePages |
String[] |
No |
A list of FileInfo.label that should be made visible for participants in this participant set. |
CcInfo
|
Parameter Name |
Type |
Required |
Description |
|---|---|---|---|
|
visiblePages |
String[] |
No |
A list of FileInfo.label that should be made visible for participants in this CC. |
HTTP Status Code
|
HTTP Status Code |
Reason |
Description |
|---|---|---|
|
400 |
INVALID_PARTICIPANT_SET_VISIBLE_PAGE_LABEL |
One or more visible page labels in the participant set is invalid. |
|
400 |
INVALID_CC_VISIBLE_PAGE_LABEL |
One or more visible page labels in CC is invalid. |
|
403 |
DOCUMENT_VISIBILITY_DISABLED |
Document visibility enabled is set to false and thus file info index cannot be specified for any participant set or CC. |
GET /agreements/{agreementId} REST API v6 endpoint can be used to retrieve relationship between participants and documents
AgreementInfo
|
Parameter Name |
Type |
Description |
|---|---|---|
|
documentVisibilityEnabled |
Boolean |
If true, document visibility was enabled for this agreement. |
ParticipantSetInfo
|
Parameter Name |
REST Object |
Description |
|---|---|---|
|
visiblePages |
String[] |
A list of FileInfo.label that should be made visible for participants in this participant set. |
CcInfo
|
Parameter Name |
REST Object |
Description |
|---|---|---|
|
visiblePages |
String[] |
A list of FileInfo.label that should be made visible for participants in this CC. |
If GET /agreements/{agreementId} is reporting CANCELLED status, it may be due to one or more invalid document visibility parameter values.
Use GET /agreements/{agreementId}/events to retrieve failure reason.
|
Error Message |
Condition |
|---|---|
|
fileInfoIndex <FileInfo index> is missing in one of the participantSets containing <participant email> |
<label> must be specified as visiblePages for participant <participant email> |
The above failure is logged with the Event.type value of AUTO_CANCELLED_CONVERSION_PROBLEM and Event.comment.
Limited document visibility and digital signature certificates are incompatible.
When LDV is enabled, the digital signature object is removed from the in-app authoring environment.
If an agreement with a digital signature field is sent with LDV rules enabled, an error will be triggered:
Digital signature field <field name> is unsupported due to limited document visibility.
If the userID can view the file that contains the attachment field, they also have the authority to view the attachment content.
Replacing a recipient works the same as normal with one exception:
- The Sender of the agreement may not replace themselves when they are a listed recipient with a non-signing role, and Signers and CCs in my account will see all files is disabled.
If Signers and CCs in my account will see all files is enabled:
- Internal recipients can only delegate to another internal user
- External recipients may not delegate to an internal user
- Attempting to do so throws the error: "Your account admin does not allow delegation to this individual."
The files and fields can be edited (using the Modify Agreement feature) as long as the agreement hasn't been viewed by a participant.
LDV is role agnostic.
If you have a non-signing recipient, then that recipient must have at least one field placed on every file that you intend for them to have access to.
If a recipient doesn't have any visible files (because no fields are placed), an error is triggered:
Participant <email> (<participant role>) does not have any visible document
Send in Bulk works the same as other agreements.
When an agreement is sent, there must be at least one required (not optional nor conditional) signature field for every recipient with a signing role.
If one or more signers don't have a required signature field, an additional page will be added to the end of the agreement and a signature block for every signer will be added (giving all signers a view of that last page).
Adobe MAX
The Creativity Conference
Oct 14–16 Miami Beach and online
Adobe MAX
The Creativity Conference
Oct 14–16 Miami Beach and online