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
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
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
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
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:
If an account-level template is used, then the group is selectable (from the groups the user is a member of):
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
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
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).
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
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
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
- 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
- If the creator of a template leaves the group that the template is shared to:
- 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.
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.
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
The .csv report continues to have the same Sender Group column, properly tracking as one sender switches between groups:
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:
When UMG is enabled, you must first select the group and open the group settings to access the group specific menu items and settings:
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
What's different:
The group-level admin no longer has the option to force a view of the agreements for newly created users.
- Account-level admins still have this authority
What's different:
To add a user to your account, you must first select a group to gain access to the Users in Group menu option
When creating individual users, the group selected defines the primary group for the user.
Group-level admins do not have the authority to edit the primary group after the user is created.
The process to create one user is the same, minus the option to force a view share to the user's agreements (see above).
Things to consider:
Creating users individually does not allow the option to include the user in multiple groups as part of the creation process.
After the user is created, the group admin can edit the user profile to include the user in more groups and edit their sending authority.
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
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.
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
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.
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
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
Group-level admins that create webhooks can select any group they are an administrator of when setting the Group field value:
What's different:
The format for the uploaded .csv used to create/update multiple users has changed to accommodate users with multiple groups and group-specific authority. To this end three columns have been removed in the UMG experience:
- Group Name - Removed; Replaced with the Groups column
- Is Group Admin - Removed; Replaced with a status value in the Groups column
- Can Send - Removed; Replaced with a status value in the Groups column
One column has been added: Groups
Group-level admins do not have the authority to manipulate users with the Groups column.
- Only account-level admins have the authority to leverage cross-group properties/access via the Create/upload users in bulk feature.
When a group-level admin creates new users via bulk upload:
- Each user is created in the group from which the admin initiated the process
- The primary group for the user defaults to the group the user is created in
- Each user is permitted to sign, regardless as to the group-level settings fo the default value
The below content is provided for awareness, as the upload template includes the Groups column.
The Groups column contains one or more Group Definitions. Each Group Definition contains the name of one group, followed by one or more status values contained in square braces. eg: Group Name[Status]
- The Group Name is a literal match to an actual group name, including spaces. eg: Default Group
- Multiple status values can be included in one Group Definition eg: Group Name[Status1 Status2]
- Status values are enclosed in square brackets
- Group names may also contain square brackets. When this is the case, the status values must be contained in the last bracket string eg: Sales [East Coast][Status1 Status2]
- There is no space between the group name and the opening square bracket containing the status values
- Group names may also contain square brackets. When this is the case, the status values must be contained in the last bracket string eg: Sales [East Coast][Status1 Status2]
- Status values are delimited by a single space between the values
- Status values are enclosed in square brackets
- Multiple Group Definitions can be included, using a semicolon as the delimiter (no spaces)
- eg: Group Name[Status];Some Other Group[Status1 Status2 Status3];Last Group[StatusA StatusB]
- The available status values for a group definition are:
- Primary - Defines the group as the primary group for the user
- Send - Allows the user to send agreements from the group
- NoSend - Prevents the user from sending agreements from the group
- Admin - Defines the user as a group-level admin for the group
- Remove - Removes the user from the group
- If a user is removed from all groups, the user will reside in the Default group
In the above example:
- John@here.com is configured with two Group Definitions:
- The Default Group is his primary group, he is a group-level admin, and he is allowed to send agreements
- The Engineering group defines him as a group-level admin, and he can send agreements
- The Default Group is his primary group, he is a group-level admin, and he is allowed to send agreements
- Fred@here.com is also configured with two Group Definitions:
- The Procurement group defines him as a group-level admin but disables his ability to send agreements
- Fred is also being removed from the Sales group
What's different:
The action to deactivate a userID has been limited for group-level admins to ensure they do not disable users in groups where they have no authority.
Group admins may only deactivate a user that has membership only within the admin's groups, and/or the Default group.
- If the user has a membership outside of the authority of the group admin that is trying to deactivate them, the option to Deactivate User will not be available
Account-level Admin differences
Only account-level admins have access to the below:
What's different:
When creating an individual user, the User Group field has been renamed to Primary Group
What's different:
As was noted in the group-level admin section, the format for the uploaded .csv used to create/update multiple users has changed to accommodate users with multiple groups and group-specific authority. To this end three columns have been removed in the UMG experience:
- Group Name - Removed; Replaced with the Groups column
- Is Group Admin - Removed; Replaced with a status value in the Groups column
- Can Send - Removed; Replaced with a status value in the Groups column
One column has been added: Groups
The Groups column contains one or more Group Definitions. Each Group Definition contains the name of one group, followed by one or more status values contained in square braces. eg: Group Name[Status]
- The Group Name is a literal match to an actual group name, including spaces. eg: Default Group
- Multiple status values can be included in one Group Definition eg: Group Name[Status1 Status2]
- Status values are enclosed in square brackets
- There is no space between the group name and the opening square bracket
- Status values are delimited by a single space between the values
- Status values are enclosed in square brackets
- Multiple Group Definitions can be included, using a semicolon as the delimiter (no spaces)
- eg: Group Name[Status];Some Other Group[Status1 Status2 Status3];Last Group[StatusA StatusB]
- The available status values for a group definition are:
- Primary - Defines the group as the primary group for the user
- Send - Allows the user to send agreements from the group
- NoSend - Prevents the user from sending agreements from the group
- Admin - Defines the user as a group-level admin for the group
- Remove - Removes the user from the group
In the above example:
- John@here.com is configured with two Group Definitions:
- The Default Group is his primary group, he is a group-level admin, and he is allowed to send agreements
- The Engineering group defines him as a group-level admin, and he can send agreements
- The Default Group is his primary group, he is a group-level admin, and he is allowed to send agreements
- Fred@here.com is also configured with two Group Definitions:
- The Procurement group defines him as a group-level admin but disables his ability to send agreements
- Fred is also being removed from the Sales group
What's different:
The authority granted to group-level admins (by account-level admins) has added granularity under UMG.
The previous ability to "add new users to groups" has been split into two options:
- Group Administrators can add new users to the account and assign users to their groups - This option allows a group-level admin to create new usersIDs within the account (and assign them to groups)
- Group Administrators can assign existing users into their groups - This option only allows group admins to assign users within their groups. They do not have the authority to create/add new userID to the account
- This authority is a sub-set of the Group Admins can add new users setting above. As a result, this option is greyed out if you select the option to create users
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:
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
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.
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.
Using the Create/update users in bulk feature, account-level admins can quickly update all of the userIDs in their account.
Creating and editing users in bulk is an option available to group-level admins for functions like editing the name, company, title, and like information. Group membership is not a value that group-level admins can manipulate via the uploaded csv feature.
You can click the download sample CSV file link to download an example CSV with the various properties included.
The format for the uploaded .csv used to create/update multiple users has changed to accommodate users with multiple groups and group-specific authority. To this end three columns have been removed in the UMG experience:
- Group Name - Removed; Replaced with the Groups column
- Is Group Admin - Removed; Replaced with a status value in the Groups column
- Can Send - Removed; Replaced with a status value in the Groups column
The new Groups column
The Groups column contains one or more Group Definitions. Each Group Definition contains the name of one group, followed by one or more status values contained in square braces. eg: Group Name[Status]
- The Group Name is a literal match to an actual group name, including spaces. eg: Default Group
- Multiple status values can be included in one Group Definition eg: Group Name[Status1 Status2]
- Status values are enclosed in square brackets
- There is no space between the group name and the opening square bracket
- Status values are delimited by a single space between the values
- Status values are enclosed in square brackets
- Multiple Group Definitions can be included, using a semicolon as the delimiter (no spaces)
- eg: Group Name[Status];Some Other Group[Status1 Status2 Status3];Last Group[StatusA StatusB]
- The available status values for a group definition are:
- Primary - Defines the group as the primary group for the user
- Send - Allows the user to send agreements from the group
- NoSend - Prevents the user from sending agreements from the group
- Admin - Defines the user as a group-level admin for the group
- Remove - Removes the user from the group
In the above example:
- John@here.com is configured with two Group Definitions:
- The Default Group is his primary group, he is a group-level admin, and he is allowed to send agreements
- The Engineering group defines him as a group-level admin, and he can send agreements
- The Default Group is his primary group, he is a group-level admin, and he is allowed to send agreements
- Fred@here.com is also configured with two Group Definitions:
- The Procurement group defines him as a group-level admin but disables his ability to send agreements
- Fred is also being removed from the Sales group
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:
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
- UserB has access to all of the agreement/template content that UserA has created or is party to
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
- 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)
- 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.
Prijavite se v svoj račun