User Guide Cancel

Assign users to multiple groups

 

Adobe Acrobat Sign Guide

What's New

  1. Pre-Release Notes
  2. Release Notes
  3. Important Notifications

Get Started

  1. Quick start guide for administrators
  2. Quick start guide for users
  3. For Developers
  4. Video tutorial library
  5. FAQ

Administer

  1. Admin Console Overview
  2. User Management
    1. Adding users
      1. Add a User
      2. Add Users in Bulk
      3. Add Users from your Directory
      4. Add Users from MS Azure Active Directory
    2. Create function-focused users
      1. Technical accounts - API driven
      2. Service accounts - Manually driven
    3. Check for users with provisioning errors
    4. Change Name/Email Address
    5. Edit a user's group membership
    6. Edit a user's group membership through the group interface
    7. Promote a user to an admin role
    8. User Identity Types and SSO
    9. Switch User Identity
    10. Authenticate Users with MS Azure
    11. Authenticate Users with Google Federation
    12. Product Profiles
    13. Login Experience 
  3. Account/Group Settings
    1. Settings Overview
    2. Global Settings
      1. Account tier and ID
      2. New Recipient Experience
      3. Self Signing Workflows
      4. Send in Bulk
      5. Web Forms
      6. Custom Send Workflows
      7. Power Automate Workflows
      8. Library Documents
      9. Collect form data with agreements
      10. Limited Document Visibility
      11. Attach a PDF copy of the signed agreement 
      12. Include a link in the email
      13. Include an image in the email
      14. Files attached to email will be named as
      15. Attach audit reports to documents
      16. Merge multiple documents into one
      17. Download individual documents
      18. Upload a signed document
      19. Delegation for users in my account
      20. Allow external recipients to delegate
      21. Authority to sign
      22. Authority to send
      23. Power to add Electronic Seals
      24. Set a default time zone
      25. Set a default date format
      26. Users in Multiple Groups (UMG)
        1. Upgrade to use UMG
      27. Group Administrator Permissions
      28. Replace recipient
      29. Audit Report
        1. Overview
        2. Allow unauthenticated access on the transaction verification page
        3. Include reminders
        4. Include view events
        5. Include agreement page/attachment count
      30. Transaction Footer
      31. In Product Messaging and Guidance
      32. Accessible PDFs
      33. New authoring experience
      34. Healthcare customer
    3. Account Setup
      1. Add logo
      2. Customize company Hostname/URL    
      3. Add company name
      4. Post agreement URL redirect
    4. Signature Preferences
      1. Well formatted signatures
      2. Allow recipients to sign by
      3. Signers can change their name
      4. Allow recipients to use their saved signature
      5. Custom Terms of Use and Consumer Disclosure
      6. Navigate recipients through form fields
      7. Restart agreement workflow
      8. Decline to sign
      9. Allow Stamps workflows
      10. Require signers to provide their Title or Company
      11. Allow signers to print and place a written signature
      12. Show messages when e-signing
      13. Require signers to use a mobile device to create their signature
      14. Request IP address from signers
      15. Exclude company name and title from participation stamps
    5. Digital Signatures
      1. Overview
      2. Download and sign with Acrobat
      3. Sign with Cloud Signatures
      4. Include metadata for Identity Providers
      5. Restricted Cloud Signatures Providers
    6. Electronic Seals
    7. Digital Identity
      1. Digital Identity Gateway
      2. Identity Check policy
    8. Report Settings
      1. New report experience
      2. Classic report settings
    9. Security Settings
      1. Single Sign-on settings
      2. Remember-me settings
      3. Login password policy
      4. Login password strength
      5. Web session duration
      6. PDF encryption type
      7. API
      8. User and group info access
      9. Allowed IP Ranges
      10. Account Sharing
      11. Account sharing permissions
      12. Agreement sharing controls
      13. Signer identity verification
      14. Agreement signing password
      15. Document password strength
      16. Block signers by Geolocation
      17. Phone Authentication
      18. Knowledge-Based Authentication (KBA)
      19. Allow page extraction
      20. Document link expiration
      21. Upload a client certificate for webhooks/callbacks
      22. Timestamp
    10. Send settings
      1. Show Send page after login
      2. Require recipient name when sending
      3. Lock name values for known users
      4. Allowed recipient roles
      5. Allow e-Witnesses
      6. Recipient groups
      7. CCs
      8. Recipient Agreement Access
      9. Required fields
      10. Attaching documents
      11. Field flattening
      12. Modify Agreements
      13. Agreement name
      14. Languages
      15. Private messages
      16. Allowed signature types
      17. Reminders
      18. Signed document password protection
      19. Send Agreement Notification through
      20. Signer identification options
        1. Overview
        2. Signing password
        3. One-Time Password via Email
        4. Acrobat Sign authentication
        5. Phone authentication
        6. Cloud-based digital signature
        7. Knowledge-based authentication
        8. Government ID
        9. Signer Identity reports
      21. Content Protection
      22. Enable Notarize transactions
      23. Document Expiration
      24. Preview, position signatures, and add fields
      25. Signing order
      26. Liquid mode
      27. Custom workflow controls
      28. Upload options for the e-sign page
      29. Post-sign confirmation URL redirect
    11. Message Templates
    12. Bio-Pharma Settings
      1. Overview
      2. Enforce identity authentication
      3. Signing reasons
    13. Workflow Integration
    14. Notarization Settings
    15. Payments Integration
    16. Signer Messaging
    17. SAML Settings
      1. SAML Configuration
      2. Install Microsoft Active Directory Federation Service
      3. Install Okta
      4. Install OneLogin
      5. Install Oracle Identity Federation
    18. Data Governance
    19. Time Stamp Settings
    20. External Archive
    21. Account Languages
    22. Email Settings
      1. Email header/footer images
      2. Permit individual user email footers
      3. Customize the Signature Requested email
      4. Customize the To and CC fields
      5. Enable Linkless Notifications
      6. Customize email templates
    23. Migrating from echosign.com to adobesign.com
    24. Configure Options for Recipients
  4. Guidance for regulatory requirements
    1. Accessibility
      1. Accessibility Compliance
      2. Create accessible forms with Acrobat desktop
      3. Create accessible AcroForms
    2. HIPAA
    3. GDPR
      1. GDPR Overview
      2. Redact a user
      3. Redact a user's agreements    
    4. 21 CFR part 11 and EudraLex Annex 11
      1. 21 CRF part 11 validation pack
      2. 21 CFR and EudraLex Annex 11 handbook
      3. Analysis of shared responsibilities
    5. Healthcare customers
    6. IVES support
    7. "Vaulting" agreements
    8. EU/UK considerations
      1. EU/UK Cross-border transactions and eIDAS
      2. HMLR requirements for deeds signed electronically
      3. The impact of Brexit on e-signature laws in the UK
  5. Download Agreements in Bulk
  6. Claim your domain 
  7. Report Abuse links

Send, Sign, and Manage Agreements

  1. Recipient Options
    1. Cancel an email reminder
    2. Options on the e-signing page
      1. Overview of the e-sign page
      2. Open to read the agreement without fields
      3. Decline to sign an agreement
      4. Delegate signing authority
      5. Restart the agreement
      6. Download a PDF of the agreement
      7. View the agreement history
      8. View the agreement messages
      9. Convert from an electronic to a written signature
      10. Convert from a written to an electronic signature 
      11. Navigate the form fields
      12. Clear the data from the form fields
      13. E-sign page magnification and navigation
      14. Change the language used in the agreement tools and information
      15. Review the Legal Notices
      16. Adjust Acrobat Sign Cookie Preferences
  2. Send Agreements  
    1. Send page overview
    2. Send an agreement only to yourself
    3. Send an agreement to others
    4. Written Signatures
    5. Recipient signing order
    6. Send in Bulk
      1. Overview of the Send in Bulk feature
      2. Send in Bulk - Configure a parent template
      3. Send in Bulk - Configure the CSV file
      4. Cancel a Send in Bulk transaction
      5. Add reminders to Send in Bulk
      6. Reporting for Send in Bulk
  3. Authoring fields into documents
    1. In-app authoring environment
      1. Automatic field detection
      2. Drag and drop fields using the authoring environment
      3. Assign form fields to recipients
      4. The Prefill role
      5. Apply fields with a reusable field template
      6. Transfer fields to a new library template
      7. Updated authoring environment when sending agreements
    2. Create forms with text tags
    3. Create forms using Acrobat (AcroForms)
      1. AcroForm creation
      2. Creating accessible PDFs
    4. Fields
      1. Field types
        1. Common field types
        2. In-line Images
        3. Stamp Images
      2. Field content appearance
      3. Field validations
      4. Masked fields values
      5. Setting show/hide conditions
      6. Calculated fields 
    5. Authoring FAQ
  4. Sign Agreements
    1. Sign agreements sent to you
    2. Fill & Sign
    3. Self-signing
  5. Manage Agreements
    1. Manage page overview
    2. Delegate agreements
    3. Replace Recipients
    4. Limit Document Visibility 
    5. Cancel an Agreement 
    6. Create new reminders
    7. Review reminders
    8. Cancel a reminder
    9. Access Power Automate flows
    10. More Actions...
      1. How search works
      2. View an agreement
      3. Create a template from an agreement
      4. Hide/Unhide agreements from view
      5. Upload a signed agreement
      6. Modify a sent agreement's files and fields
      7. Edit a recipient's authentication method
      8. Add or modify an expiration date
      9. Add a Note to the agreement
      10. Share an individual agreement
      11. Unshare an agreement
      12. Download an individual agreement
      13. Download the individual files of an agreement
      14. Download the Audit Report of an agreement
      15. Download the field content of an agreement
  6. Audit Report
  7. Reporting and Data exports
    1. Overview
    2. Grant users access to reporting
    3. Report charts
      1. Create a new report
      2. Agreement Reports
      3. Transaction Reports
      4. Settings Activity Report
      5. Edit a report
    4. Data Exports 
      1. Create a new data export
      2. Web form data export
      3. Edit a data export
      4. Refresh the data export content
      5. Download the data export
    5. Rename a report/export
    6. Duplicate a report/export
    7. Schedule a report/export
    8. Delete a report/export
    9. Check Transaction Usage

Advanced Agreement Capabilities and Workflows

  1. Webforms 
    1. Create a web form
    2. Edit a web form
    3. Disable/Enable a web form
    4. Hide/Unhide a web form
    5. Find the URL or script code 
    6. Prefill web form fields with URL parameters
    7. Save a web form to complete later
    8. Resize a web form
  2. Reusable Templates (Library templates) 
    1. US Government forms in the Acrobat Sign library
    2. Create a library template
    3. Change a library template's name
    4. Change a library template's type
    5. Change a library template's permission level
    6. Copy, edit, and save a shared template
    7. Download the aggregate field data for a library template
  3. Transfer ownership of web forms and library templates
  4. Power Automate Workflows 
    1. Overview of the Power Automate integration and included entitlements
    2. Enable the Power Automate integration
    3. In-Context Actions on the Manage page
    4. Track Power Automate usage
    5. Create a new flow (Examples)
    6. Triggers used for flows
    7. Importing flows from outside Acrobat Sign
    8. Manage flows
    9. Edit flows
    10. Share flows
    11. Disable or Enable flows
    12. Delete flows
    13. Useful Templates
      1. Administrator only
        1. Save all completed documents to SharePoint
        2. Save all completed documents to OneDrive for Business
        3. Save all completed documents to Google Drive
        4. Save all completed documents to DropBox
        5. Save all completed documents to Box
      2. Agreement archival
        1. Save your completed documents to SharePoint
        2. Save your completed documents to One Drive for Business
        3. Save your completed documents to Google Drive
        4. Save your completed documents to DropBox
        5. Save your completed documents to Box
      3. Webform agreement archival
        1. Save completed web form documents to SharePoint Library
        2. Save completed web form documents to OneDrive for Business
        3. Save completed   documents to Google Drive
        4. Save completed web form documents to Box
      4. Agreement data extraction
        1. Extract form field data from your signed document and update Excel sheet
      5. Agreement notifications
        1. Send custom email notifications with your agreement contents and signed agreement
        2. Get your Adobe Acrobat Sign notifications in a Teams Channel
        3. Get your Adobe Acrobat Sign notifications in Slack
        4. Get your Adobe Acrobat Sign notifications in Webex
      6. Agreement generation
        1. Generate document from Power App form and Word template, send for signature
        2. Generate agreement from Word template in OneDrive, and get signature
        3. Generate agreement for selected Excel row, send for review and signature
  5. Custom Send workflows
    1. Custom Send Workflow Overview
    2. Creating a new Send Workflow
    3. Edit a Send Workflow
    4. Activate or Deactivate a Send Workflow
    5. Send an agreement with a Send Workflow
  6. Share users and agreements
    1. Share a user
    2. Share agreements

Integrate with other products

  1.  Acrobat Sign integrations overview 
  2. Acrobat Sign for Salesforce
  3. Acrobat Sign for Microsoft
    1. Acrobat Sign for Microsoft 365
    2. Acrobat Sign for Outlook
    3. Acrobat Sign for Word/PowerPoint
    4. Acrobat Sign for Teams
    5. Acrobat Sign for Microsoft PowerApps and Power Automate
    6. Acrobat Sign Connector for Microsoft Search
    7. Acrobat Sign for Microsoft Dynamics 
    8. Acrobat Sign for Microsoft SharePoint 
  4. Other Integrations
    1. Acrobat Sign for ServiceNow
    2. Acrobat Sign for HR ServiceNow
    3. Acrobat Sign for SAP SuccessFactors
    4. Acrobat Sign for Workday
    5. Acrobat Sign for NetSuite
    6. Acrobat Sign for VeevaVault
    7. Acrobat Sign for Coupa BSM Suite
  5. Partner managed integrations
  6. How to obtain an integration key

Acrobat Sign Developer

  1. REST APIs 
    1. Methods documentation
    2. SDK/Developer Guide
    3. API FAQ    
  2. Webhooks 
    1. Webhook overview
    2. Configure a new webhook
    3. View or edit a webhook
    4. Deactivate or reactivate a webhook
    5. Delete a webhook
    6. Two-way SSL certificates
    7. Webhooks in the API

Support and Troubleshooting

  1. Customer Support Resources 
  2. Enterprise Customer Success Resources 

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

  • 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
  • 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

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 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
View their agrewements option

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

Note:

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.

Access users through groups

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

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
Classic template for uploading users vis csv

One column has been added: Groups

Caution:

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
    • Status values are delimited by a single space between the values
  • 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
New bulk upload csv format

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
  • 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
Removed element - Deactivate user

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

Create User - Primary gorup

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
Classic template for uploading users vis csv

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
  • 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
New bulk upload csv format

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

Two settings are available under UMG rules to allow users to be removed from the Default group when added to another group:

  •  Group assignment removes a user from the default group if it is their primary - When enabled, a user that has their primary group set to the Default group will be removed from the Default group if added to any other group using the Assign Users to this Group administrative pages. The new group becomes the user's primary group automatically.
    • This setting is not applied when adding the user to a group through the user's profile
    • This setting is not applied when using the CSV import or API methods to add/modify users.
  • Group admins can remove users from the account's default group - This setting enables the option for a group-level administrator to remove a user from the Default group via the user's profile.
Group admin settings for removing users form the default group.

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

Using the Create/update users in bulk feature, account-level admins can quickly update all of the userIDs in their account.

Note:

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.

Navigate to the create user interface

Note:

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
Removed columns

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
  • 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
CSV example

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
  • 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.

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.

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.

Get help faster and easier

New user?