User Guide Cancel

Differences in UMG enabled accounts

Search
Adobe Sign

Adobe Sign

Open app
  1. Welcome to Adobe Acrobat Sign for Government
    1. First steps for new accounts
    2. Claiming an email domains
    3. Connecting Okta to a federated identity solution
    4. Manually create/edit users in Okta
      1. Creating individual users manually
      2. Creating multiple users via CSV import
      3. Add or Remove a group from a user profile
      4. Elevating a user to Account/Privacy administrator status
      5. Changing your Okta password
  2. Configure Acrobat Sign
    1. Configuration Overview
    2. System requirements
    3. Branding
      1. Company and Hostname
      2. Logos
      3. Email header/footer images
    4. User access to features
    5. User experience within the application
      1. Allowed Signature types
      2. Signature order options
      3. Self Signing workflows
    6. Recipient experience when interacting with agreements
    7. Transaction security
    8. Compliance information
      1. GDPR
      2. HIPAA
      3. eVaulting Chattle paper
      4. IVES
  3. Administrator processes
    1. Admin guide overview
    2. Users
      1. Manage users in the Gov CloudCreating users
      2. Add users to a group
      3. Remove a user from group membership
      4. Update users in bulk
      5. Users in Multiple Groups (UMG)
        1. Overview
        2. Differences in UMG enabled accounts
    3. Groups
      1. Create a group
      2. Delete a group
      3. Modify a group name
      4. Modify group-level settings
    4. Templates
      1. Edit shared templates
      2. Transfer template ownership
    5. Custom workflow designer
      1. Create a custom workflow
    6. GDPR deletion processes
      1. Delete a user
      2. Delete agreements
    7. Sandbox
  4. User environment and processes
    1. Support resources
    2. Transaction limits
    3. Page layouts
      1. Home page
      2. Send page
      3. Manage page
      4. Reports page
    4. Configure your profile
      1. "My Profile" overview
      2. Change your email address
      3. Define your signature
      4. Configure your event and alert notifications
      5. Define your language preferences
      6. Define your personal email footer
      7. Review account sharing
      8. Configure auto delegation
    5. Send agreements
      1. Compose an agreement to send for signature
      2. Recipient signing order
        1. Sequential or parallel signing
        2. Hybrid signing (Both sequential and parallel)
        3. Recipient groups
      3. Written signatures
      4. Send an agreement to yourself only
      5. Send in Bulk
      6. Sending from a template on the Manage page
      7. Sign agreements
      8. Fill and Sign a document
      9. Self Signing
      10. Signing a document from an email link
      11. Sign a document from the Manage page
    6. Custom workflow designer
      1. Overview
      2. Create a new sending workflow
      3. Edit a sending workflow
      4. Activate/Deactivate a workflow
      5. Send agreements using a workflow
    7. Manage agreements
      1. Search for agreements
      2. View Agreements
      3. Activity history and Audit Report
      4. Add a note to an agreement
      5. Set a reminder
      6. Cancel a reminder
      7. Add an expiration date
      8. Modify/Delete an expiration date
      9. Modify the files of a sent agreement
      10. Replace the current recipient
      11. Upload a signed agreement
      12. Share an individual agreement
      13. Download an agreement
      14. Download the individual files of an agreement
      15. Download the audit report
      16. Download the signer identity report
      17. Download the field data from an agreement
      18. Cancel an agreement
      19. Hide an agreement from view
    8. Reporting
      1. Create a report with classic reporting
      2. Report charts and data exports
        1. Overview
        2. User permissions for report charts and exports
      3. Data Exports
        1. Create a data export
        2. Open and edit a data export
        3. Refresh the data in an existing export
        4. Download the CSV from a data export
      4. Report Charts
        1. Create a report chart
        2. Open and edit a report chart
        3. Rename a data export/report chart
        4. Duplicate a data export/report chart
        5. Delete a data export/report chart
    9. API
      1. API Swagger documentation
      2. Webhooks

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.

Note:

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

  • 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
  • Review any Acrobat Sign supported integrations, custom API development, and/or 3rd party integrations in a developer account to ensure the 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

Objects and inheritance (Parent-Child objects)

"Object" is a term used to describe a collection of properties that represents one idea. Your Account is a type of object, as is your User.

Within an application like Acrobat Sign, objects can be used as templates to build other objects, and when one object is built from a "template" object, those two objects are said to have a Parent-Child relationship.

Because a child object is a direct copy of the parent, the settings are identical.  The child object inherits the property values of the parent. If a parent value changes, that change is also inherited by the child.

One object tree in Acrobat Sign is the Account > Group > User group of properties.

  • Every group naturally inherits the properties of the account they are in, as groups are child objects of the account
  • Every user inherits the properties of the group they are in, as they are considered the child objects of the group

Observing the Account > Group > User chain of objects, you can readily see how moving one user to a new group changes the "default" functionality of the user due to the new parameters inherited from the group.

Changing a property value of a child object is permitted, and this explicit change generally breaks the inheritance of that property value from the parent object. If the parent object changes the value for such a property, the child does not inherit the new value as the explicitly set value holds precedence.

This can best be seen when group-level admins over-ride the account-level settings for their group. And because the users in the group are child objects of the group they are in, the user experience is changed accordingly.

Users that have access to multiple groups change their inherited properties when they change the group from which they are acting. You will notice that when a user changes their group on the Send page, the page refreshes as the new group-level properties are loaded. This is most notable if you have unique logo branding per group.

 

Object IDs

Every object has a unique identifying number behind the scenes.  This unique ID is how the application differentiates objects of a like type and relates the objects to one another.

The implications of user and groupIDs become more apparent under UMG rules, particularly around reporting. When a user creates an asset in the system (agreement, template, web form), the userID of the creator, and the groupID that the asset was created in, are encoded into the asset.

When a user runs a report for their agreements, the application returns the data that is related to their userID. The groupID is not relevant to the search (unless a filter is applied).

But when a group admin runs a report for a group, the application returns the data that relates to the groupID (regardless as to which userID created it)

When users could only exist in one group, there was generally no difference to be observed. With users creating assets in multiple groups, it's possible that one user's content can span the groups of more than one group-level admin.

Group-level admins can only access the content generated within the groupIDs they have authority in (excepting the content they personally create). If a group admin reports on the content for one userID, the dataset returned only includes the content (created by the userID) within the group(s) where they are an admin.

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
Note:

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:

What's different:

The user's profile fully exposes all groups the user is included in and specifically flags the primary group.

With UMG enabled:

  • All groups that the user is a member of are listed
  • The first group listed is always the Primary Group

Set up your user profile

My Profile

What's different:

Because the user has access to multiple groups, the templates and workflows available to the user are grouped by the Group the template/workflow is related to.

  • Templates and workflows can only be related to one group, or the account as a whole
  • Account level templates/workflows are also displayed in their own section, at the bottom of the list of groups
  • When a template/workflow is launched from this menu, the Send (compose) page loads with the associated Group value automatically applied
    • The Send from selector is locked to the value of the group the template/workflow is associated with
Starting a template or wirkflow form the Home page

If a group-level template is used, then the group is inserted on the Send page, and the option to edit the group is suppressed:

Group-level template

 

If an account-level template is used, then the group is selectable (from the groups the user is a member of):

Account level template

What's different:

The Send page introduces a drop-down selector at the top of the page: Send from
This selector allows the sender to select the group (and all related group-level properties) that governs the properties and options for the transaction. 

  • In the Send from drop-down field, the user only has access to select the groups for which they have been explicitly added to and granted send permissions
  • The primary group is always the default (loaded) value for the group when the user comes to the Send page

 

Things to consider:

Set the Send from selector first.

  • Changing the selector imposes group-level settings including:
    • Branding
    • Permitted authentication types
    • Signature restrictions
    • Shared library template and workflow options
    • Message templates
  • Because changing the Send from selector forces the webpage to reload with the new group settings, any field-level content that has been added is lost with the refresh
  • Once an agreement is sent, the group it was sent from may not be altered
Send from group

What's different:

Much like the Send page, the Self Sign page introduces a drop-down selector at the top of the page: Select Group

This selector allows the sender to select the group (and all related group-level properties) that governs the properties and options for the transaction. 

  • The user only has access to the groups they are explicitly added to
  • The primary group is always the default (loaded) value for the group when the user comes to the Send page

 

Things to consider:

Set the Send using selector first.

  • Changing the selector imposes group-level settings including:
    • Branding
    • Permitted authentication types
    • Signature restrictions
    • Shared library template and workflow options
  • Because changing the Send using selector forces the webpage to reload with the new group settings, any field-level content that has been added is lost with the refresh
Self Sign

What's different:

An identifying label has been added to the agreement context menu to indicate which group an agreement was sent from.

 

Things to consider:

Some functions are strongly tied to the group, (eg: reporting parameters and retention rules).

Sent From value for an agreement

What's different:

A column has been added to the table of agreements that is produced on the Manage page.

  • The Group header in the table is not clickable. To sort the dataset, use a filter

 

Group affiliation on the Manage page

What's different:

A new filter is available to filter the Manage page dataset by Group

  • Only one Group filter can be in effect at a time
    • Like other filters, a small tag is populated to the left of the Filters button when the Group filter is in effect
    • The Group filter includes templates that have been shared to the group
    • Explicit Group filters do include account-level shared templates
  • Users can only employ the filters for groups they are currently members of
    • The All Groups option is the only "filter" that includes agreements created in groups the user is not currently a member of
Filter contgent on the Manage page by group

What's different:

When creating a library template, the creator has the option to set the template access properties and share the agreement with any group they are a member of.

  • Templates may only be shared to one group
  • When a template is shared to a group in this manner, a strong relationship is established between the template and group. Meaning:
    • Admins with access to the group can edit the template via the shared libraries tab
    • If the user is removed from the group, the template will remain as an asset of the group (unless explicitly re-linked to a new group)
    • Templates shared to a group can only be used by members of the group (and the creator of the template)
      • If the creator of a template leaves the group that the template is shared to:
        • The creator of the template continues to have access to send the agreement (as the owner of the template) despite no longer being affiliated with the group
          • The creator of the template retains authority/access to edit the properties of the agreement on the Manage page
        • The group continues to have access to the template
    • If the creating user is deleted from the application (via GDPR delete), the agreements can be retained as an asset of the group

 

Things to consider:

One user with access to all groups can be used as a central document admin.

Template properties -- Select the group

A user with the authority to create web forms can associate their form to any group they are a member of.

  • A web form can only be related to one group
    • The related group can not be changed after the web form is created
  • Web forms do not surface in the Shared Libraries tab
  • If the creator loses membership to the group, the web form retains its group relationship.
Create a Web form

What's different:

A filter has been added to the Reports page to allow the report to be confined to agreements related to one or more Groups.

  • The user must have access to the Group to apply the filter
Reports filter for Groups

 

The .csv report continues to have the same Sender Group column, properly tracking as one sender switches between groups:

Report column for Senders group

Note:

If a user is removed from a group they have previously sent agreements from, they will not be able to report on those transactions. 


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.

What's different:

If the user is an administrator of more than one group, then Workflows and Shared Libraries have been moved from the top level of the group admin's menu options to be sub-menus for each individual group:

Group-level admin menu

 

When UMG is enabled, you must first select the group and open the group settings to access the group specific menu items and settings:

Group settings under UMG

What's different:

When a group admin has administrative authority over more than one group, the admin first needs to select which group they want to configure:

  • Select Groups from the left-rail menu list
  • Single-click the group you want to edit (to expose the Group Settings link)
  • Click the Group Settings link
Group menu

What's different:

The authority to determine if a userID can sign agreements, and the ability to install an auto delegation rule for a userID, have been removed from the group-level admin interface.

  • This authority exists only with account-level admins under UMG rules
Elements removed from Edit User Profile

Group-level admins have the authority to allow or disallow a user's membership to each group they administer via the user's profile.

  • The user must be exposed to the group admin (through creation or admin entitlement) for the user to be visible in the list of users

To add group membership:

  • Navigate to [Group] > Users in Group page
  • Double-click the user to open the user profile
  • Click the plus icon to the right of the Group Membership header
    • The Add Group Membership dialogue box opens        
  • Select the group you want to add the user to
    • Only the groups the admin is an administrator of are selectable
  • Click Add
  • Repeat the process for all groups to be added
  • Click Save when done.
Add group membership

Users newly placed into a group will adopt two authority values:

  • Group Admin - Does the userID have group-level administrative authority?
    • False by default
  • Can Send - Does the userID have the authority to access templates/workflows and send agreements under the group's property profile.
    • True by default

Check or uncheck the values per group as necessary

  • Click Save when done
Note:

Group-level admins do not have the authority to edit the primary group for a userID unless they have administrative authority in both the original primary group and the new group.

Edited user membership

How to delete a group membership

To remove a user from group membership:

  • Navigate to [Group] > Users in Group page
  • Double-click the user to open the user profile
  • Single-click the group you want to remove to expose the Delete Group Membership action
  • Click the Remove link
  • Repeat for any additional memberships to be removed
  • Click Save
Note:

If a user has their group membership revoked for all groups:

  • The userID is deposited in the Default group
  • The primary group for the user is set to the Default group
Delete a group membership

Group-level admins that create webhooks can select any group they are an administrator of when setting the Group field value:

Create Webhook


Account-level Admin differences

Only account-level admins have access to the below:

What's different:

The authority granted to group-level admins (by account-level admins) to remove users from the default group becomes editable (vs. always enabled) under UMG.

  • Group admins can remove users from the account's default group - This option allows a group-level admin to remove users from the default group when enabled.
Group admin related settings


Privacy-level Admin differences

Privacy-level admin tools are not currently changed by the UMG settings.

API differences

Note:

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 by editing the individual user profile:

Editing an individual user - This is done through:

  • The Users menu - account-level admins only
  • The Users in Group menu - account or group-level admins
Edit the User

Single click the user to expose the Edit User option; Click Edit User

The overlay for group management is opened, and the admin can freely add the user to any group(s) where they have administrator authority by clickiung the plus icon.

Add group membership

Once the group membership is added to the user, the admin can enable/disable the user's authority within the group by checking/unchecking the boxes under the Group Admin and Can Send column headers.

Edit the membership authority


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.

Note:

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.

Start agreement from tempalte or workflow

 

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.

Starting an agreement from Send


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:
Note:

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.

Create a library tempalte


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:

Edit a template properties

Note:

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
Web Form creation

Caution:

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:

 

User to User sharing is not changed under UMG rules:

  • If UserA shares their account to UserB:
    • UserB has access to all of the agreement/template content that UserA has created or is party to
      • All templates owned by UserA (assigned to self/group/account) are visible
    • Having membership to multiple groups, or shifting the UserA to another primary group does not impact the relationship

When a UserA is shared to GroupX:

  • All members of GroupX can view all of the agreement/template content that UserA has created or is party to
    • All templates owned by UserA (assigned to self/group/account) are visible
  • Having membership to multiple groups, or shifting UserA to another primary group does not impact the relationship
  • Users added to GroupX will gain access to the agreement/template content of UserA
  • Users removed from GroupX lose access to the agreement/template content shared by UserA

When GroupA is shared to UserX:

  • UserX gains access to all agreements created/sent from GroupA
    • The sending userID does not need to be a current member of GroupA. That the agreement was created through GroupA defines the relationship
  • UserX gains access to all agreements/templates for all userIDs that have GroupA defined as their primary group
    • e.g.: Changing UserM's primary group from GroupA to GroupB will remove UserX's view to UserM's content (excepting agreements sent from GroupA per the above rule)

When GroupA is sharing to GroupB

  • All members of GroupB can access all agreements sent through GroupA
    • The sending userID does not need to be a current member of GroupA. That the agreement was created through GroupA defines the relationship
  • All members of GroupB can access all agreement/template content for users that have GroupA defined as their primary group
  • Adding a new userID to GroupB will grant that userID access to the GroupA content
    • Removing a userID from GroupB will remove access to GroupA content
  • Creating/updating a userID to have GroupA as the primary group exposes all user agreement/template content to GroupB
    • Removing a userID from GroupA removes access to the user's content for GroupB (excepting agreements created through GroupA)


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.

The current Acrobat Sign integration packages do not account for UMG in any way.  As a result, all users sending agreements through an integration 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.

 Adobe

Get help faster and easier

New user?

Quick links

View all your plans Manage your plans
View quick links
Hide quick links

Legal Notices    |    Online Privacy Policy