brainX

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:

globale_einstellungen_globale_rechtevergabe_monitor.pngGlobal Rights Assignment

2.1. Module Public/Not Public

The "public" toggle in the "Module" column determines whether a module is public/not public.

Note

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

globale_einstellungen_globale_rechtevergabe_spalte_berechtigungen.pngCompany-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.

globale_einstellungen_globale_rechtevergabe_button_aktionen.pngCompany-wide Access Rights - Actions Button - Flyout Menu

3. Custom Access Rules

Note

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.

globale_einstellungen_globale_rechtevergabe_benutzerdefinierte_zugangsregeln.pngGlobal Rights Assignment - Custom Access Rules

3.1. Creating a New Rule

After clicking the "New Rule" button, the "New Access Rule" popup opens.

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

globale_einstellungen_benutzer_und_rechte_popup_aenderungen_erkannt.pngNotice: Changes Detected

Example

Custom access rule for the Deals module:

globale_einstellungen_globale_rechtevergabe_popup_neue_zugangsregel_beislpiel.png

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:

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

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

globale_einstellungen_globale_rechtevergabe_benutzerdefinierte_zugangsregeln_einzeln_loeschen.pngEdit/Delete individual custom rule

After clicking the "Delete" action, a confirmation popup is displayed.

globale_einstellungen_globale_rechtevergabe_benutzerdefinierte_zugangsregeln_einzeln_loeschen_popup.pngPopup 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.

globale_einstellungen_globale_rechtevergabe_benutzerdefinierte_zugangsregeln_pro_modul_loeschen.pngDelete all custom rules

After clicking the "Delete" action, a confirmation popup is displayed.

globale_einstellungen_globale_rechtevergabe_benutzerdefinierte_zugangsregeln_pro_modul_loeschen_popup.pngPopup 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.