Skip to main content

Organization Levels and Roles

Information on the different Levels and Roles that can be configured into your Organization in Contract Logix

Eric Reinert avatar
Written by Eric Reinert
Updated over 3 months ago

The out-of-the-box system comes with one organization level (Corporate) to which you may add your own sub-organization levels (see How to Set Up Your Organizational Hierarchy). For each organization within the hierarchy, you can then add one or more security roles which determine which features and record types users can access. The Roles Apply and Role Conflicts Settings on the Org Roles/Permission page of the Application Settings allow for level of access customization for users. The organizational level the role occupies also can determine which specific records they can access, based on the record’s Organizational Ownership field.

Organizations with a desire to limit or restrict access will benefit from an understanding of each configuration option:

Roles Apply/Scope

Global

Organizational

In this mode, permissions from all of a user's Roles apply to all records.

Permissions from each of a user's roles apply only to records within the organizational ownership area in which the role is located.

If a user has multiple Roles assigned, the permissions from each object type are combined from their roles according to the Role Conflicts setting (Role Conflicts explained in next section). NOTE: If the user is assigned only one Role then the Role Conflicts setting is disregarded.

However, a user in multiple roles may experience unique record access and record editing behavior based on the security permissions (i.e., Role Conflicts setting).

In this mode, creating well-separated roles will minimize the likelihood that role conflict resolution (i.e., Role Conflicts setting, explained in next section) will be needed. NOTE: This mode allows a user to have different permission levels to the same object type, depending on the organizational ownership of the record they are accessing.

The location of the role in the Organizational Hierarchy allows the user access to records with the corresponding organizational ownership.

When multiple roles apply, a user's effective permissions to a given object types are determined by considering two role priority levels.

  • Roles whose organizational ownership exactly matches any of the organizational ownership selections of the record, have the first priority.

  • Roles at higher organizational ownership levels have the second priority. These are considered only if there are no first priority roles.

Within their allowed organizational ownership area(s), the user will have the same level of access to all objects (Associations, Contacts, Contracts, Documents, and Organizations) of any given type.

Within each of the two priority levels, permission conflicts are resolved according to the selected Conflict Resolution mode (i.e., Role Conflicts setting).

In Summary


In the Global Roles Apply setting, users assigned multiple Roles (whether top level and sub-levels or just in sub-levels) may experience access overlap depending on the Role Conflicts setting.

In Summary

In the Organizational Roles Apply setting, users assigned multiple Roles (whether top level and sub-levels or just in sub-levels) experience unique areas of record access rather than access overlap (i.e., it is possible to grant users different levels of access to the same kind of object record depending on the organizational ownership of that record).

Role Conflicts

Most Privilege

Least Privilege

When more than one of a user's roles apply to a record they are accessing, the user's permission level for that record will be the highest level from among their roles. NOTE: A conflict between two roles may or may not exist for a given record, depending on the selected Roles Apply/Scope setting.

When more than one of a user's roles apply to a record they are accessing, the user's permission level utilized for that record will be the lowest level from among their roles. NOTE: A conflict between two roles may or may not exist for a given record, depending on the selected Roles Apply/Scope setting.

This mode is best suited for systems where the "shape" of access areas for a user is additive in nature.

This mode is best suited for systems that require exceptions which lower or deny a user's access within certain organizational areas.

It is recommended in the Organizational Hierarchy of your Org Roles/Permissions that the highest organizational level (Corporate) be reserved with Roles configured for users who need the highest level of record access, and then build distinct sub-organization levels in which access is more narrowly defined ad controlled through these settings.

For example, if you set up two sub-organizations under Corporate, (US-Canada and Latin America) then roles in the US-Canada sub-org can access records owned by US-Canada, and roles in Latin America sub-org can access records owned by Latin America. Roles in Corporate, sitting above these two sub-orgs in the hierarchy, can access both.

NOTE: When defining role permissions, there is also an option called Access All Org Ownership to ignore the Organizational Ownership field for a specified object type, thus allowing users in that role access to all records of that type regardless of which organization or sub-organization “owns” the record.

Types of Roles

  • Standard roles are added individually to a specific organization level and are configured independently. Use a Standard role when each role demands unique features and/or permissions.

  • With Parent roles you create a single role and then add it to one or more organization levels. The roles in each organization are linked back to the Parent so that modifications made to the Parent automatically update all linked roles. Parent roles eliminate the need to configure and maintain duplicate roles, saving time and effort when you have different users in different organizations that require the same feature access and permissions.

  • Relational roles are similar to a Parent role in that you create a single role and then add it to multiple organizations. However, Relational roles are used when you have the same users that require the same feature access and permissions across different organizations.

Did this answer your question?