Introduction

Access to information in ACRM is determined by a user's assigned Rights. Rights in Aurea CRM are a highly configurable feature that supports many customization options. In this article, we will provide a quick overview of how Rights work on a basic level, as well as some of the most important points that should be taken into account when addressing related issues.

Rights Formats

At the most basic level, Rights are applied as sets of Rights Formats that restrict the ways in which records for each info area can be accessed. These can then be assigned to a user or group, or to a whole Station. Operations can be restricted completely or conditionally, including the usual view, create, update, and delete. Note that it is also possible to limit the type of access to specific fields within an Info Area. 

Hierarchy

At any given time, it is possible for a user to be restricted by up to four Rights Formats (see Checking active Rights below):

• Station access rights apply to all users who log on to the Station the access rights are assigned to.
• Group access rights apply to all members of the Group the access rights are assigned to.
• Rep access rights apply to individual Reps.
• Role access rights are also assigned if a rep logs on using one or more Login Roles.

The Rights Hierarchy is the most common source of confusion regarding Rights, especially when troubleshooting related issues. Understanding how Inheriting Access Rights works is key when troubleshooting related issues.

In a similar vein, please be aware that rights are also subjected to an Implicit Hierarchy unless disabled, limiting access to a record if the parent records are also restricted for the user.

Note: The option to Merge Access Rights is also supported.

Assigning Rights

For the rights to apply to a given Rep, Role, or Station, they need to be assigned. The process to Assign Rights changes depending on the level at which they need to be enabled. Note that the relevant checkboxes need to be enabled at the Rep Level in the Rights module for the rights to apply:

Checking active Rights

In CRM.web, you can see the complete set of rights being applied in the System Information page:

In CRM.win, they can be checked under Help > About:

The Super User

Finally, it is important to be aware that, by default, when logged in as the SU (Super User), limitations imposed by rights will be ignored, which may help test whether a certain behavior is related to the Rights settings.

Related features

Aside from limiting access to Info Areas, the Rights Format also determines how certain features are applied to each user, if so configured. The most prominent of these are the following:

• Triggers: Triggers modify data in ACRM when a certain condition is met. They can be highly customizable, and can be used alongside the more complex Workflows. Please refer to Generating logs for Trigger events in CRM.web for the steps required to generate logs for Triggers.
• Mark as Deleted: This feature allows for soft-deleting records. While records deleted in this manner cannot be undeleted manually, all historical information is kept for auditing purposes.
• History: This feature produces history records under the configured conditions, detailing all changes made to a record.

Defining Conditions

As explained before, one of the supported features of the Rights Formats is the ability to define conditions for the different restrictions and triggers that can be set up:

These conditions can be made to compare the value of a field with a variety of preset values and variables, including Rep-Based Access Rights that reference the current user's information and hierarchy. This will allow you, for example, to restrict the visibility of a record to users within the creator's group.

Please refer to Defining Conditional Access Rights for more information on setting up this type of restriction. Be aware that it is possible to set conditions for Info Areas, as well as for specific fields.

More information

As always, the number of ways in which it is possible to configure the Rights that can be applied to a user is too large to cover in this article. For a complete list of the existing features and how to enable them, please refer to the existing documentation on the Rights Module.