Global Rights Assignment
Package: BASIC
1. General
The "Global Rights Assignment" area contains two very important functions of the brainX system for defining permissions:
The following permissions can be assigned per module:
- May view → Permission to view records of the module
- May edit → Permission to view and edit records of the module
- May edit and delete → Permission to view, edit and delete records of the module
2. Company-wide Access Rights
The company-wide access rights overview displays all modules of the system in a table-like structure.
The table has four columns:
- Module → module name and toggle for module public/not public
- Permissions → display and configuration of permissions for the module
- Custom Access Rules → display of the number of custom access rules for the module
- Actions → for each module, the action "Custom Access Rules" is available here
Global Rights Assignment
2.1. Module Public/Not Public
The "public" toggle in the "Module" column determines whether a module is public/not public.
Only with the setting "not public" (toggle "inactive") is the hierarchical rights system taken into account!
This means each user only sees the data they have access to based on their hierarchy level. Whether a user is then allowed to create, edit or delete records depends on the configuration of roles and profiles.
2.2. Permissions
If a module has been set to "public", further permissions can be assigned for the module:
- May view → records may be viewed but not edited or deleted
- May edit → records may be viewed and edited but not deleted
- May edit and delete → records may be viewed, edited and deleted
Company-wide Access Rights - Permissions
2.3. Actions Button
The "Actions" button is located at the top right in the "Company-wide Access Rights" block, which can be used to configure permissions for all modules.
After clicking the "Actions" button, a flyout menu opens with the following actions:
- "May view" for all modules → records may be viewed but not edited or deleted
- "May edit" for all modules → records may be viewed and edited but not deleted
- "May edit and delete" for all modules → records may be viewed, edited and deleted
- "Private" for all modules → Only with the setting "private" (= "not public") is the hierarchical rights system taken into account. This means each user only sees the data they have access to based on their hierarchy level. Whether a user is then allowed to create, edit or delete records depends on the configuration of roles and profiles.
Company-wide Access Rights - Actions Button - Flyout Menu
3. Custom Access Rules
Custom access rules only make sense if a module has the setting "May view" or "private" (= "not public")!
The "Custom Access Rules" block lists all existing custom access rules.
Custom access rules grant additional rights to the data of a module for specific users, groups, roles or roles and subordinates.
Data sharing is always created from top to bottom or at the same level in the hierarchical rights concept. Sharing from bottom to top is not necessary, as a superior role can see, edit and delete all data of its subordinate roles.
Global Rights Assignment - Custom Access Rules
3.1. Creating a New Rule
After clicking the "New Rule" button, the "New Access Rule" popup opens.
Popup New Access Rule
The popup is divided into the following areas:
- Module → selection of the module for which the access rule is to be created.
- Owner → selection of the owner of the records.
Roles, Roles and Subordinates and Groups are available for selection. - Access rights → selection of the permission to be granted.
"May only view" and "May view and edit" are available for selection. - Access rights to relative modules (only displayed once a module has been selected, since relative modules are always module-dependent) → selection of the permission to be granted for relative modules. The modules Emails, Tasks and Appointments are additionally inserted dynamically.
"May only view", "May view and edit" and "No access" are available for selection.
Once a new access rule has been created, the rights must be recalculated. A corresponding notice is displayed after saving:
Notice: Changes Detected
Custom access rule for the Deals module:

The Accounting Group may only view all records of the Sales Role. The access right to the relative module Orders is "May only view".
3.2. Editing a Rule
To edit a custom rule, click the actions icon "three dots" in the "Actions" column for the rule to be edited and select the "Edit" action in the flyout menu.
The "Edit Access Rule" popup opens:
Popup Edit Access Rule
All non-changeable settings are grayed out and cannot be edited.
Once an access rule has been changed, the rights must be recalculated to apply the changes. A corresponding notice is displayed after saving:
Notice: Changes Detected
After clicking the "Recalculate now" button in the notice, the rights in the system are recalculated. All changes are now valid.
3.3. Deleting a Rule
When deleting custom access rules, two options are available:
3.3.1. Delete Individual Rule
To delete a custom rule, click the actions icon "three dots" in the "Actions" column for the rule to be deleted and select the "Delete" action in the flyout menu.
Edit/Delete individual custom rule
After clicking the "Delete" action, a confirmation popup is displayed.
Popup Delete Access Rule
By clicking the "Confirm" button, the access rule is deleted.
3.3.2. Delete All Rules for a Module
To delete all custom access rules for a module, click the "Recycle Bin" actions icon in the block of the corresponding module.
Delete all custom rules
After clicking the "Delete" action, a confirmation popup is displayed.
Popup Delete Access Rules
By clicking the "Confirm" button, all access rules for the module are deleted.
4. Practical Examples
1 – Sales sees only their own leads, support sees all
The Leads module is set to not public. Each sales employee therefore only sees their own leads. To allow the support team to view all leads for qualification purposes, a custom access rule is created: Support Group may view records of the Sales Role. After recalculating, the support team has read access to all leads without any changes to the role hierarchy.
2 – Accounting may only read deals from the sales role
Accounting needs visibility into closed deals but should not be able to edit them. The Deals module remains set to not public. A custom access rule is created: Accounting Group, owner Sales Role, access right May only view. For the related module Orders, May only view is also selected. After recalculating, accounting can read deals and linked orders but cannot modify them.
5. Frequently Asked Questions
When should a module be set to "public" instead of "not public"?
Setting a module to public means all users can see all records in that module — regardless of their position in the role hierarchy. This makes sense for modules with purely internal reference data, such as product catalogs or price lists, where every user should have access. For operational data like leads, quotes, or invoices, not public is recommended so that the role hierarchy takes effect.
When does a custom access rule apply instead of the company-wide setting?
Custom access rules supplement the company-wide setting — they can extend permissions but not restrict them. If a module is set to not public, a user by default only sees their own records and those of their subordinate roles. A custom access rule grants additional access to records belonging to other roles, groups, or users beyond that default.
Must permissions be recalculated after creating a custom access rule?
Yes. As with all changes to the permission system, after saving a new or modified access rule, the Recalculate now button must be clicked for the rule to take effect.