Skip to main content
Mitratech Success Center

Client Support Center

Need help? Click a product group below to select your application and get access to knowledge articles, webinars, training content, and release notes or to contact our support team.

Authorized users - log in to create a ticket, view tickets status and check your success plan details.

 

Permissions in EraCLM

Permissions in EraCLM are divided into two categories: user types and user roles. User types refer to how much access you have in EraCLM, whether you are a user that creates or negotiates agreements, or an administrator. User roles refer to the role that you play when negotiating an agreement. These two categories of permissions are configured in a different way.

User types

User permissions let you create or negotiate agreements in EraCLM and thus use the following sections in the platform: Agreements, Activity, Reports, Insights, and Queues.

Administrator permissions let you configure frameworks, groups, queues, and users, among performing other administrative tasks. There are different administrators for the platform, each one specializing on different aspects of EraCLM. For steps to configure user types, see Configure an EraCLM User. The following table describes the user types different functions.

User type Description Permissions
Active end-user Users that negotiate:
- controllers
- negotiators
- viewers
- approvers
- communication owners
- acceptors
- signers
Staff status Administrators Administrators at domain level. They have access to the Admin Panel.
They also can configure the following items:
- Queues
- Users
- Groups
Superuser status Administrators Administrator permissions reserved to EraCLM internal teams.
Framework specialist Framework administrators Administrator with permissions to create, edit, and archive frameworks. They have access to the Framework Builder. They also give framework access to users and groups.
Agreex specialist EraCLM Express end-user Users that negotiate in EraCLM Express:
- controllers
- negotiators
- viewers
- approvers
- communication owners
Agreex admin EraCLM Express Administrators EraCLM Express administrators. They have access to the Admin Panel.
They also can configure the following items:
- Queues
- Users
- Groups
Smart table specialist A user that can create smart tables and dictionaries by using the UI Administrators that can create smart tables and dictionaries by using the UI, instead of using the EraCLM API.

User Roles in an Agreement

Users negotiating an agreement must have a role assigned:

  • Controller
  • Negotiator
  • Viewer
  • Approver
  • Communication Owner
  • Acceptor
  • Signer

User roles have the following attributes:

  • Controllers are active users with permissions in at least one framework.

  • A controller creates an agreement, creates a team, and assigns permissions to users on that agreement.

  • Depending on their role, users can review or edit an agreement. They also can add comments, and accept or reject sections.

  • The controller assigns permissions to acceptors and signers in the team.

  • Framework rules can establish roles such as the approvers, communication owners, and signers.

For more information about user roles, see Rules, User Roles and Permissions.

Groups and User Permissions

All users that belong to a group have access to the same items, such as queues and frameworks. They also can share information about agreements created by members of the group, even if they don’t participate directly in the negotiation. For more information, see Configure an EraCLM Group.

Frameworks, User Roles, and User Permissions

Frameworks are created by Framework specialists, which is a special administrator permission. Frameworks can contain rules that assign user roles and that automate agreement sharing. The Framework specialist gives permissions to users or groups on the framework. These permissions let users create agreements from frameworks, so a user needs permission in at least one framework to assume the controller user role.

Agreements, User Roles, and User Permissions

When you create an agreement, you become the controller. The controller negotiates and assigns roles to users. User roles give different levels of access in the agreement. The actions performed depending on the level of access are as follows:

  • Negotiate or edit

  • View

  • Comment

  • Approve

  • Reject

The actions can be performed on different levels too:

  • On tags

  • On sections

  • On the whole agreement

EraCLM also lets controllers hide sections of the agreement to user roles, and framework rules can set certain sections as fixed and not let anyone change them.

Agreement Sharing Within Groups

By default, a user can see all agreements in which that user is the controller or has been assigned a negotiation role. These agreements appear in tab My Agreements, under the Agreements section.

When a user belongs to a group, and that group has permissions on an agreement, Agreements section shows two additional tabs: My Team agreements and Shared Archive. My team agreements show shared agreements in the negotiation phase and Shared Archive shows shared agreements that have been completed, either by signature, acceptance, or verification.

Note that although there can be a parent-child relationship between groups, agreement permissions can’t be shared to children agreements. Instead, you must select the groups that you want to have visibility in the agreement. See How to assign permissions to an agreement for more information.

For example, an admin creates a group named Company A. Company A, as the name implies, is the group that contains the entire company.

Then the admin creates group Legal as a child of Company A.

undefined

Company A contains the following users:

  • Diana A
  • Diana B
  • Diana C

Legal contains the following users:

  • Diana D
  • Diana E

Diana A creates an agreement named MSI Agreement, based on a framework that contains a rule to share agreements with group Company A.

Diana A adds Diana B as the negotiator. Users in Company A and Legal see MSI agreement according to the following table.

User My Agreements My Team agreements Shared Archive
Diana A
Diana B
MSI agreement MSI agreement when it’s being negotiated MSI agreement when it’s completed
Diana C No agreement MSI agreement when it’s being negotiated MSI agreement when it’s completed
Diana D
Diana E
No agreement No agreement No agreement

Diana D creates an agreement named Express Agreement, based on a framework that contains a rule to share agreements to Legal.

Diana D adds Diana A and Diana E as negotiators. Users in Company A and Legal see Express Agreement according to the following table.

User My Agreements My Team agreements Shared Archive
Diana A Express Agreement No agreement No agreement
diana B No agreement No agreement No agreement
diana C No agreement Express Agreement when it’s being negotiated Express Agreement when it’s completed
Diana D
Diana E
Express Agreement Express Agreement when it’s being negotiated Express Agreement when it’s completed

Queues, User Roles, and Permissions

A queue is a set of tasks assigned to several users so that each user can self-assign a task. Queues gather all tasks in one place. You can check the types of tasks, the status of the tasks, and which user is responsible for each task.

Queues are divided into the following categories:

Drafting queue: An agreement-related queue. This queue contains tasks that are related to creating drafts and editing agreements.

Approval queue: This queue contains tasks related to granting approval to any phase of the negotiation process, based on events that trigger an approval.

Administrators configure the queues so that users can distribute the workload. Depending on your framework configuration, EraCLM can send tasks to a predefined queue.

Queues contain user roles, each one fulfilling a task.

Queue Role Description
Dispatcher - Dispatcher is an admin role
- They assign tasks to queue members
Taker - A taker is an admin role
- They can assign themselves tasks
Viewers - Viewer is an admin role
- They can see all actions in the queue and status of all tasks
- They can’t participate in the queue
Queue member - Dispatchers can assign tasks to queue members
- Queue members can’t assign tasks to someone else
- They can’t assign themselves a task

Note that in this scenario, an admin role exists only within the queue, and it’s different from user type admin.

For more information about queues, see:

  • Was this article helpful?