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