What's New
Get Started
Administer
- Admin Console Overview
-
User Management
- Adding users
- Create function-focused users
- Check for users with provisioning errors
- Change Name/Email Address
- Edit a user's group membership
- Promote a user to an admin role
- User Identity Types and SSO
- Switch User Identity
- Authenticate Users with MS Azure
- Authenticate Users with Google Federation
- Product Profiles
- Login Experience
-
Guidance for regulatory requirements
- Accessibility
- HIPAA
- GDPR
- 21 CFR part 11 and EudraLex Annex 11
- Healthcare customers
- IVES support
- "Vaulting" agreements
- EU/UK considerations
- Claim your domain
- Report Abuse links
Send, Sign, and Manage Agreements
-
Recipient Options
- Cancel an email reminder
-
Options on the e-signing page
- Overview of the e-sign page
- Open to read the agreement without fields
- Decline to sign an agreement
- Delegate signing authority
- Download a PDF of the agreement
- View the agreement history
- View the agreement messages
- Convert from an electronic to a written signature
- Convert from a written to an electronic signature
- Navigate the form fields
- Clear the data from the form fields
- E-sign page magnification and navigation
- Change the language used in the agreement tools and information
- Review the Legal Notices
- Adjust Acrobat Sign Cookie Preferences
- Send Agreements
-
Authoring fields into documents
- In-app authoring environment
- Create forms with text tags
- Create forms using Acrobat (AcroForms)
- Fields
- Authoring FAQ
- Sign Agreements
-
Manage Agreements
- Manage page overview
- Delegate agreements
- Replace Recipients
- Limit Document Visibility
- Cancel an Agreement
- Create new reminders
- Review reminders
- Cancel a reminder
- Access Power Automate flows
-
More Actions...
- How search works
- View an agreement
- Create a template from an agreement
- Hide/Unhide agreements from view
- Upload a signed agreement
- Modify a sent agreement's files and fields
- Edit a recipient's authentication method
- Add or modify an expiration date
- Add a Note to the agreement
- Share an individual agreement
- Unshare an agreement
- Download an individual agreement
- Download the individual files of an agreement
- Download the Audit Report of an agreement
- Download the field content of an agreement
- Audit Report
- Reporting and Data exports
Advanced Agreement Capabilities and Workflows
- Webforms
- Reusable Templates
- Transfer ownership of web forms and library templates
-
Power Automate Workflows
- Overview of the Power Automate integration and included entitlements
- Enable the Power Automate integration
- In-Context Actions on the Manage page
- Track Power Automate usage
- Create a new flow (Examples)
- Triggers used for flows
- Importing flows from outside Acrobat Sign
- Manage flows
- Edit flows
- Share flows
- Disable or Enable flows
- Delete flows
-
Useful Templates
- Administrator only
- Agreement archival
- Webform agreement archival
- Agreement data extraction
- Agreement notifications
- Agreement generation
- Custom Send workflows
- Share users and agreements
Integrate with other products
- Acrobat Sign for Salesforce
- Acrobat Sign for Microsoft
- Other Integrations
- Partner managed integrations
- How to obtain an integration key
Acrobat Sign Developer
- REST APIs
- Webhooks
Support and Troubleshooting
Allowing users to send agreements from more than one group, admins can strongly tie library templates, recipient authentication, and signature requirements to one group, letting the workflow define the nature of the group instead of the users in it.
Overview
When an agreement is created, it's the group-level settings that largely dictate the available assets (templates/workflows) and system-inflicted properties of the agreement (branding, recipient roles, authentication methods, PDF security/retention, etc.).
Being locked into one group means that any individual userID is locked into one set of defaults, one array of templates and workflows, and one concept of signature compliance.
Allowing users to access multiple groups opens the door for administrators to think about groups as more than a collection of users. Groups can be viewed as an environment for specific document signing requirements that you grant users access to.
For example, one group can be designed around a set of very strict compliance-related signature and distribution rules, and another can be configured for internal, low-authentication workflows and templates. A user assigned to both groups can access all the resources for each group.
Group-level administrators also have the ability to manage more than one group, which improves the practical usability of the group-level administrator role.
This document is designed to highlight the changes UMG brings to the interface/functionality for users, and identify the considerations that migrating to UMG sparks for administrators.
Prerequisites
- Only enterprise and business-level accounts are eligible to enable users in multiple groups
- Ensure that your network security explicitly permits access to allow the Acrobat Sign endpoints
- The most current version of the Custom Workflows, Home, and Manage interface must be enabled for the account
- Switching the account to allow users in multiple groups automatically enables the new page versions (if they aren't already), and disables the options to revert back to the legacy interface. This includes the "Switch" links
- Legacy Workflow/Home/Manage pages are incompatible with users in multiple groups
- Backing out of UMG does not reset your Home/Manage
- Switching the account to allow users in multiple groups automatically enables the new page versions (if they aren't already), and disables the options to revert back to the legacy interface. This includes the "Switch" links
- Review any Acrobat Sign supported integrations, custom API development, and/or 3rd party integrations in a developer account to ensure functionality
The Primary Group
All users under UMG rules are assigned a "primary group". The primary group is:
- The default group that the user loads when they enter the Send page
- The group that defines the userIDs signature authority/parameters if an agreement is sent to their email address
- The group that is referenced if a group-level setting is needed and the requesting source is unaware of UMG
- EG: Acrobat Sign integrations can span multiple versions. Older versions that are not UMG aware need a default to refer to, and that would be the primary group
- EG: Acrobat Sign integrations can span multiple versions. Older versions that are not UMG aware need a default to refer to, and that would be the primary group
Group affiliation of assets
Agreements, Web Forms, and Send in Bulk events created before enabling UMG are only related to creating userID.
Agreements, Web Forms, and Send in Bulk events created after UMG is enabled are related to the groupID they were created in addition to the userID that created them.
In practice, this means that the assets created before enabling UMG will move with the user if you change the user's primary group. Users viewing the group (through account sharing) will lose visibility of these assets when the user is moved out of the shared group.
Assets created after UMG is enabled will remain related to the group. Users viewing the group will continue to see the assets created in the group after the creating user is moved to a new primary group.
How to enable the option to have users in multiple groups
Enabling or disabling UMG can only be done via an account-level administrator. Please refer to this article for instructions to upgrade your account.
Reverting back from UMG is possible with the below notable effects:
- All Group level admin flags are cleared
- Account-level admin flags are not impacted
- Group-level admins can be re-entitled to their dedicated groups
- All users exist solely within their primary group
A user can have a membership to a maximum of 100 groups.
User-level differences
User-level changes are ubiquitous. All users that can log in to Acrobat Sign will observe the below changes:
Group-level Admin differences
These interface changes are only observable by the admins of the account (as permitted by the account-level admin controls):
The role of the group-level admin is significantly improved, as one user can be the admin for multiple groups, and is not required to be the admin of all groups they are a member of.
Group-level admins in multiple groups can better manage documents and workflows for broader teams, and report on the content of multiple groups, without being given access to the full dataset for the account.
Account-level Admin differences
Only account-level admins have access to the below:
Privacy-level Admin differences
Privacy-level admin tools are not currently changed by the UMG settings.
API differences
Only v6 of the REST API will be updated to accommodate UMG.
The legacy SOAP API will not be updated to accommodate UMG.
Use of SOAP APIs or v5 REST (and older) will function without UMG awareness, and the User's primary group will be in effect.
v6 REST API endpoints that are executed in the context of a specific group have been expanded to include an optional groupId identifier that can be passed into a request as a query parameter, header, or as part of the request body.
This parameter is optional, and if omitted the code defaults to the user's primary group.
Group-specific actions are in two categories:
- User management
- CRUD operations on resources
Change in user management is contained in the ability to manage multiple group memberships in one API call and the expansion of the security model which affects group admin's abilities, i.e. makes sure the group admin does not cause a change in a group outside of their reach.
Change in resource operations is the additional group id parameter to request/response models, providing a group context to agreements, web forms, and Send in Bulk events.
The group Id parameter is only added in the v6 REST API. Versions below v6 REST use the primary group for backwards compatibility.
INVALID_GROUP_ID
A common error response code "INVALID_GROUP_ID" is triggered when:
- The identified group not found
- The identified user is not a member of the identified group.
- The feature is disabled and group id does not match the primary group of the user
If UMG is not enabled, all existing endpoints behave as before. The primary group of the user is used as the only valid group membership and if another group id is passed to an endpoint, the INVALID_GROUP_ID is returned.
Add users to multiple groups
Adding a user to multiple groups is done in one of two ways:
Creating Agreements
UMG rules are observable at the very beginning of the process to create a new agreement.
If a user is starting the process by selecting a template or workflow from the Home page > Start from library, the user must expand the group from which they are sending first, and then select the template/worklflow from the options available within the group.
Selecting the template/workflow and clicking Start opens the Send page, ready for the user to complete the configuration.
By starting the agreement from a group-level template or workflow, the group value is inserted into the Send page, and the option to edit the group is suppressed.
If an account-level workflow/template is selected, the sender has the option to select the group value.
If the user starts the process from the Send page, the Send from drop-down field defines the group the agreement is associated with.
By selecting the group, the agreement is constrained to the library templates available to the chosen group.
Changing the group changes the properties applied to the agreement. This forces the page to refresh, and any field level content that was entered is lost.
Custom workflow designer
Creating and managing custom workflows is not impacted by UMG rules thus far:
- Workflows that are assigned to a group may only be edited by an admin (group or account level) that has their primary group set as the same group the workflow is dedicated to
- Workflows that are assigned to the account level can only be edited by an account-level admin (irrespective of primary group)
In future updates, administrators will be given the interface options to associate the workflows they create with individual groups they have admin authority in, regardless of their Primary Group.
Library template creation and management
Creating a reusable library template under UMG rules has one additional step when granting group level permission to access the template:
Define the group that the library template is associated with.
- This is done in a sub menu when you select the Who can use this template permission:
The original userID that creats a template is understood as the "owner" of that template.
The template owner always has access to the template to Send or Edit. It does not matter what authority level the owning userID has, or if the owner is associated with the group the template is exposed to.
Managing existing library templates
Existing library templates can have their properties edited through the Manage page.
Open the template for editing, and if the template is being shared to Any user in my group, the editor can change the group association:
Changing the group association does not impact the group affiliation for agreements already created.
Web form creation and management
Creating a web form under UMG rules has one additional step:
Define the group that the web form is associated with. This is done at the very top of the page.
- Set the group value first, as changing the group resets the page and clears any field level content
The associated group may not be edited after the web form is created.
Managing existing web forms
UMG rules do not impact how existing web forms are managed (as the associated group may not be edited).
Reporting against the web form requires either the creator to run the report, or an admin with authority to the report data in the group.
Sharing content
Sharing an individual agreement or template is not impacted by UMG rules.
Accounts using standard account sharing (only User to User sharing) are not impacted by UMG rules.
Advanced Account Sharing permits sharing between Users, between Groups, and between Users and Groups:
Document retention/GDPR
Are there no changes expected to the GDPR tool set with respect to the UMG changes.
Integrations
All enterprise-level accounts can enable UMG, even when one (or more) integrations are configured.
Currently, the following integrations support UMG parameters:
- Salesforce
- Power Automate
- Microsoft 365 (Teams, Outlook, Word/PowerPoint)
Users sending agreements through an integration that are not UMG aware are perceived to be in their primary group only, and sending parameters will align with the primary group settings accordingly.
API - REST v6
Many of the REST v6 API endpoints have had an optional parameter for the groupID added to the method.
The current expectation is that any existing REST v6 API call will continue to work, regardless as to if UMG is enabled or not.
Previous API versions (both SOAP and REST) will continue to work as expected, understanding the user only as a member of their primary group.