Adobe Acrobat Sign Lexicon

Documents/Files/Attachments vs. Agreements vs. Transactions

Documents/files/attachments are all individual files that are uploaded to the Acrobat Sign system. The building materials for the Agreement.
Agreements are the customer-facing objects that Acrobat Sign creates from the uploaded files, and that recipients fill or sign. "Agreement" is the term used to define both the object during the process of obtaining signatures and the final PDF that is generated.
Transactions encompass the Agreement and all of the associated logging and documentation that is generated for/by the Agreement along the way. (eg: Audit reports, authentication results, field-level data .csv pages)

Feature prefixes

As features evolve, prefixes will be applied to indicate where the feature resides in the release/end of life cycle.

New – Something wholly new.
Modern – Something updated that may have an option to switch between the modern and classic experiences.
- Modern versions of things can have New features. E.g., the Modern version of the custom workflow designer has New features
Classic – The older version of something being updated, typically used when there is an option to switch between active versions.
Legacy – The older version of something when the option to switch is removed for newly created accounts.

Internal vs External

The term "Internal" describes the group of userIDs within a common accountID. These usersIDs are internal to the account, and settings that apply to internal users only apply to these userIDs.

All other email addresses are "External".

Note

Many companies have multiple accounts.

Users from the same company (sharing the same domain in their email address), but not within the same accountID are external to each other

Account-level admins can obtain a complete list of internal email addresses by navigating to Account > Users and clicking the Export user list icon.

A CSV file is downloaded to your local system. That CSV enumerates the users in the account, including their current status.

Objects and ObjectIDs

Objects

Within the scope of Adobe Acrobat Sign, an "object" is a discreetly understood group of attributes/properties.

Types of objects are:

The Account as a whole
Groups
Users
Agreements

Where all objects of the same type have the same list of properties, the values attributed to those properties will often be different, and in some cases, must be.

For example, all Users have an email address property, and every user's email value must be unique.

When "objects" are used in documentation, the understanding is that the whole type of object is being included. (e.g., Users can be created with a CSV file)

Object IDs

All objects have unique identification numbers to distinguish between objects of the same type. Every user has a unique userID. Every agreement has a unique agreementID.

Objects often use objectIDs as the key attribute to establish relationships with other objects. In this way, objects can maintain ongoing relationships even if other attributes change.

For example, a UserID can create multiple AgreementIDs, and that relationship persists even if the user changes other properties like the user's name and email address.

When used in documentation, an objectID identifies one unique instance from a type of objects. (e.g., Changing the email address of a userID does not change the ownership of the userIDs agreements.)

Parent - Child (Template) relationships

The idea of a parent-child relationship is best illustrated with a template that is used to generate multiple copies of itself without consuming the template. Because the parent is directly related to the child agreement it generates, the parent object can report on the relative status of all child agreements.

Adobe Acrobat Sign has three examples of this principle:

Library templates - When library templates are attached to an agreement, that agreement relationship is tracked as a child of the template document. (Note this is only true if only one template is attached to the agreement.) Library templates can report on the agreements that have used the template from the Manage page
Web Forms - Web Forms create a parent template that is copied when a user attempts to submit the form for signature. The Web form parent is tracked on the Manage page and can report on any agreements in progress or completed.
Send in Bulk - The Send in Bulk process allows the user to upload and configure one set of files and a CSV list of email addresses. This creates a parent template that copies itself and sends a discrete agreement to each email included in the CSV list. The parent object is tracked on the Manage page and can be used to report on the relative status of the spawned child agreements.

Property/Setting inheritance

Adobe Acrobat Sign is built on an object-oriented model that allows "child" objects to be created from "parent" objects. When a child object is created, it inherits all of the properties (attributes and settings) of the parent (template) object.

Persistent inheritance dictates that if the parent object changes a property value, that change flows down to all child objects, who inherit that change accordingly.

By breaking the inheritance link, a child object can be customized to facilitate a specific result.

A good example of this in Adobe Acrobat Sign is the Account:Group relationship. By default, all new groups inherit the setting values defined at the account level. However, groups have the ability to break the inheritance link from the account level and customize the group settings for a specific result (e.g., tighter signature requirements, specific agreement defaults).

In Adobe Acrobat Sign, inheritance flows from parent > child through the objects: Application > Tier of Service > Account > Group > User

The Application is the base object and contains all of the possible options for the service.
The Tier of Service is the level of service a customer purchases. At this level, the various features are enabled to differentiate an enterprise account from an individual account (for example).
The Account level inherits all settings from the Tier of Service and allows for the user administrators to customize the account for their specific use. This is the highest level of authority that customer admins can configure.
The Group level inherits all of the Account level settings and allows for further customization of the group. Changing setting values at the group level overrides the account-level settings, and propagates the group settings downstream to any child objects related to the group.
Both the User and Agreement objects inherit their properties from the Group they reside within. If a user changes the group they are related to, then the user will see only the values inherited from the new group, and any agreements created will only adopt the values available within that new group.

Because of property inheritance, it is generally recommended that admins configure their account level settings to be the most severe values that their work processes will tolerate, and then loosen restrictions as needed at the group level.

Signer (Roles) vs. Recipient vs. Participant

Signer (or Approver, Acceptor, etc.) - An explicitly defined role for a recipient

All recipients have a role.

Recipient - Any email used to include someone in the "signature cycle" of the agreement. Individuals that can interact with the agreement while it is in progress

Recipients are a sub-set of Participants.

Participant - Any email (individual) that is included in the transaction. This consists of the sender, all recipients, and all CC'd parties.

Single Use Pending Users

When an agreement is created in Acrobat Sign, the application attempts to identify if any of the recipients have an existing userID to which the agreement can be related.

If a userID exists, and that userID is in an account that is trusted by the sending account, then the agreementID is directly related to the userID, and the agreement is visible on the user's Manage page.

If the email does not exist in the system, or if the sending accountID is not trusted by the userID's account, then Acrobat Sign creates a unique single-use userID specifically to track the recipient's activities for that agreementID. Single use userIDs exist only for as long as the agreement is in progress. Once the agreement is completed, and all of the loggable events are captured, the single-use userID is no longer useful and deleted from the system.

Terminal Status

A terminal state is achieved when the agreement has no further actions that recipients can take to complete it. There are three terminal states:

Complete - Achieved when the agreement completes all processes with all recipients successfully.
Abandoned - An abandoned agreement has been stopped by explicit action. This action can come from one of several sources:
- Canceled by the sender
- Declined by the recipient
- Failed due to recipient authentication failure
- Failed due to system error
Expired - Agreements that reach their expiry date due to inaction within the defined time period.

Adobe Acrobat Sign Lexicon (Terminology, jargon, what have you...)