---
title: Access Rights
description: "> 📍 **Where to find this module?** > *Settings > User Management > Access Rights* --- ## Introduction Kafinea's **access rights** system allows you to precisely control what each user can see and do in the application. It is based…"
url: "https://www.kafinea.com/en/help/settings/access-rights/"
updated: "2023-11-28"
category: Settings
---

# Access Rights

> 📍 **Where to find this module?**
> *Settings > User Management > Access Rights*

---

## Introduction

Kafinea's **access rights** system allows you to precisely control what each user can see and do in the application. It is based on four complementary levels:

| Level | Role | Configuration Screen |
| --- | --- | --- |
| **Roles** | Define the organizational hierarchy | *Settings > User Management > Roles* |
| **Profiles** | Define permissions module by module | *Settings > User Management > Profiles* |
| **Sharing Rules** | Define data visibility between users | *Settings > User Management > Sharing Rules* |
| **Groups** | Group users for data sharing | *Settings > User Management > Groups* |

> **Good to know**: A **standard administrator** user has full access to all modules and all data, regardless of the configured roles, profiles, and sharing rules. There are two types of administrators in Kafinea:
>
>
>
> - **Standard administrator**: Full access to data and all system configuration.
> - **Limited administrator**: Data rights identical to a normal user (defined by their profile and role), but with access to system configuration—except for permission management (users, profiles, roles, groups, sharing rules).
>
>
>
> Access restrictions only apply to non-administrator users (and to limited administrators regarding data).

---

## 1. Administrators

By default, access restrictions do not apply to administrators. Kafinea offers two types of administrative accounts:

### Standard Administrator

The standard administrator has full authority over the entire application.

- **Data access**: can view, modify, and delete any record in any module, regardless of hierarchy or sharing rules.
- **Configuration**: full access to all settings screens (users, profiles, roles, module manager, system settings, etc.).
- **Security**: this is the only profile that can enable or disable other administrator accounts.

### Limited Administrator

The limited administrator is a hybrid profile designed to delegate settings management without risk of privilege escalation.

- **Data access**: identical to a normal user—their rights are defined by their profile and role. They only see what their profile authorizes.
- **Settings access**: can access most configuration screens (workflows, SMTP, features, logs, etc.).
- **Restrictions**: cannot access permission management—the **Users**, **Profiles**, **Roles**, **Groups**, and **Sharing Rules** screens are hidden from them. This prevents any privilege escalation (they cannot grant themselves additional rights).
- **Recommended use**: IT manager who manages workflows or SMTP, but should not access invoicing or accounting.

> **Concrete example**: an IT manager with the "Internal Support" profile (limited access to HR and accounting modules) can be a limited admin to manage workflows and SMTP, without ever being able to view payslips or modify other users' rights.

> **How to enable a limited administrator?**: In a user's record, check the **Limited Admin** box. This option is only available to standard administrators.

---

## 2. Roles

### Principle

A **role** defines a user's position in the organization's hierarchy. Roles are organized in a tree structure (organizational chart). This hierarchy determines **which data a user can see**:

- A **parent** role can see the data of its **child** roles (subordinates)
- A **child** role only sees its own data (unless sharing rules allow otherwise)

### Configuration

To manage roles: ***Settings > User Management > Roles***.

1. The screen displays the complete role tree
2. Click on a role to edit it, or use the **Add Role** button to create a new one
3. Each role must be attached to a parent role (except the root role)
4. Associate one or more **profiles** with the role—it is the profile that determines detailed permissions

> **Important**: Each user is associated with **a single role**. This role determines both their hierarchical position and their permissions (via the profiles associated with the role).

### Hierarchy in Practice

**Example**: a company with the following structure:

```
Directeur Général
├── Directeur Commercial
│   ├── Responsable Ventes France
│   │   └── Commercial France
│   └── Responsable Ventes Export
│       └── Commercial Export
└── Directeur Financier
    ├── Comptable
    └── Contrôleur de gestion
```

In this configuration:

- The **General Manager** sees data from all roles
- The **Sales Director** sees data from their subordinates (Managers and Sales Representatives) but not from the Finance Director
- A **France Sales Representative** only sees their own data

---

## 3. Profiles

### Principle

A **profile** defines **detailed permissions** module by module. It is the core of the access rights system. A profile determines:

1. **Module access**: is the module visible and accessible for this profile?
2. **Authorized actions**: create, view, modify, delete
3. **Field access**: for each module, which fields are visible and/or editable
4. **Global rights**: "View All" and "Edit All" (optional)
5. **Tool rights**: import, export, duplicate merging, etc.

### Configuration

To manage profiles: ***Settings > User Management > Profiles***.

1. Click on an existing profile to edit it, or click **Add Profile** to create a new one
2. In the editing screen, you see the list of all modules with their options

### Global Permissions

> **Note**: These options are generally not visible in Kafinea's default interface to avoid major configuration errors. They only appear if they are already active for an existing profile.

At the top of a profile's editing screen, two global options may be available:

| Global Permission | Effect |
| --- | --- |
| **View All** | The user can view **all records** in **all modules**, regardless of the owner. Sharing rules and role hierarchy no longer apply for viewing. |
| **Edit All** | The user can modify **all records** in **all modules**, regardless of the owner. |

> **Warning**: "View All" and "Edit All" are very powerful rights. They override sharing rules and role hierarchy. Reserve them for profiles that truly need them (e.g., management, administrative support).

### Permissions by Module

For each module, you can configure:

**Module access** (checkbox):

- **Checked**: the module is accessible for this profile
- **Unchecked**: the module is completely invisible and inaccessible

**Available actions** (when the module is accessible):

| Action | Description |
| --- | --- |
| **Create** | The user can create new records in this module |
| **View Detail** | The user can view detailed records |
| **Edit** | The user can modify existing records |
| **Delete** | The user can delete records |

> **Good to know**: If a module is unchecked (access removed), **all actions** are automatically blocked, even if they were individually checked previously. Rechecking the module restores action permissions as they were configured.

### Field-Level Permissions

For each accessible module, you can define the visibility of each field:

| Level | Description |
| --- | --- |
| **Visible and Editable** | The field is displayed and can be modified by the user |
| **Read-Only** | The field is displayed but cannot be modified |
| **Hidden** | The field is not displayed for this profile |

> **Good to know**: Some system fields (such as the record name) cannot be hidden.

### Utility Tool Rights

Each profile can also configure access to cross-functional tools:

| Tool | Description |
| --- | --- |
| **Import** | Import data from a CSV file |
| **Export** | Export data from a module |
| **Duplicate Merging** | Merge duplicate records |

### Combining Multiple Profiles

A role can be associated with **multiple profiles**. In this case, permissions **accumulate** according to the **most permissive** principle:

- If profile A allows creation in the Invoices module and profile B prohibits it, the user **can** create (the most permissive right prevails)
- If profile A grants access to the Contacts module and profile B grants access to the Invoices module, the user has access to **both** modules

> **Tip**: To simplify management, create thematic profiles (e.g., "Sales Access," "Accounting Access") that you combine according to each role's needs, rather than creating a monolithic profile per role.

---

## 4. Sharing Rules

### Principle

**Sharing rules** define the **default data visibility** between users. They complement the role hierarchy by specifying, module by module, whether users can see each other's data.

### Configuration

To manage sharing rules: ***Settings > User Management > Sharing Rules***.

### The Three Sharing Levels

| Rule | Description | Use Case |
| --- | --- | --- |
| **Private** | Each user only sees their own records and those of their subordinates (according to role hierarchy) | Sensitive data: HR, accounting, personal data |
| **Public: Read-Only** | All users can view records, but only the owner (and their superiors) can modify them | Data to view but not modify by all: product catalog, shared contacts |
| **Public: Read/Write** | All users can view and modify all records | Collaborative data: projects, shared tasks |

> **Important**: Sharing rules define the **default** behavior. **Exceptions** can be added to grant additional access to specific roles, groups, or users.

### Sharing Exceptions

When the default rule is "Private" or "Public: Read-Only," you can create exceptions to extend access:

1. In the sharing rules screen, click **Add Exception** for the desired module
2. Choose **who shares** (a role, a group, or a role and its subordinates)
3. Choose **with whom** (a role, a group, or a role and its subordinates)
4. Choose the **access level**: read-only or read/write

**Example**: The "Invoices" module is in "Private" mode. You want the collections team to be able to view invoices from the entire company. Create an exception that shares invoices from "All Roles and Subordinates" to the "Collections" group in "Read-Only."

### Recalculating Sharing Rules

After modifying sharing rules, click the **Recalculate** button for the changes to take effect.

> **Warning**: Recalculation may take a few seconds on instances with many users and data.

---

## 5. Groups

### Principle

A **group** is a set of users, roles, or other groups. Groups are primarily used to:

- **Assign records** to a team rather than a single user
- **Create sharing exceptions** to grant access to a cross-functional team

### Configuration

To manage groups: ***Settings > User Management > Groups***.

A group can contain:

- Individual **users**
- Entire **roles** (all users with that role)
- **Roles and subordinates** (the role and all its children in the hierarchy)
- Other **groups** (nesting)

**Example**: The "Executive Committee" group contains the "Sales Director," "Finance Director," and "General Manager" roles.

---

## 6. How Permissions Are Evaluated

When a user tries to access a record or perform an action, Kafinea checks permissions in the following order:

1. **Is the user a standard administrator?** → If yes, full data access, no further checks. For a **limited administrator**, the following checks apply normally.
2. **Is the module active?** → If the module is disabled, no one (except administrators) has access
3. **Does the profile allow module access?** → If none of the user's profiles authorize the module, access denied
4. **Is the action authorized by the profile?** → Check for the specific action (create, view, modify, delete)
5. **Do the sharing rules allow access to this record?** → Check owner, hierarchy, and exceptions

> **Good to know**: When a user has multiple profiles, Kafinea applies the **most permissive** principle: if at least one profile authorizes an action, it is authorized.

---

## 7. Common Configuration Scenarios

### Scenario 1: A Sales Representative Who Only Sees Their Clients

1. Create a **profile** "Sales Representative" with access to Contacts, Accounts, Quotes, Orders modules
2. In the **sharing rules**, set the Contacts and Accounts modules to "Private"
3. Create a **role** "Sales Representative" under the "Sales Manager" role
4. Associate the "Sales Representative" profile with the role

**Result**: the sales representative only sees their own clients and those of any subordinates. Their manager, however, sees data from all their sales representatives.

### Scenario 2: An Accountant with Read Access to Sales

1. Create a **profile** "Accounting" with full access to accounting modules (Invoices, Payments, etc.)
2. Create a second **profile** "Sales Read" with read-only access to sales modules (Quotes, Orders)—check "View Detail" but uncheck "Create," "Edit," and "Delete"
3. Associate **both profiles** with the "Accountant" role

**Result**: the accountant can manage accounting freely while viewing quotes and orders without being able to modify them.

### Scenario 3: A Cross-Functional Project Team

1. Create a **group** "Project Alpha Team" containing the relevant users
2. In the **sharing rules** for the Projects module (in "Private" mode), add an exception granting "Read/Write" access to the "Project Alpha Team" group

**Result**: team members can all collaborate on projects assigned to them, regardless of their hierarchical position.

### Scenario 4: Restricting Access to Leave Requests

1. In the **profile** for the relevant role, ensure the "Leave Requests" module is **checked** (accessible)
2. Verify that the "Create," "View Detail," and "Edit" actions are checked
3. If the user still cannot modify requests, check the module's **sharing rules**

> **Good to know**: If a module does not appear in the profile editing screen, this may mean the module is disabled. Contact your administrator to check the module's status in ***Settings > Module Manager***.

---

## 8. Troubleshooting

### A User Does Not See a Module in the Menu

**Possible causes**:

1. The module is **unchecked** in their profile → Edit the profile in *Settings > User Management > Profiles* and check the module
2. The module is **disabled** at the system level → Check in *Settings > Module Manager*
3. The module is not in the user's **menu** → Check the menu configuration

### A User Cannot Modify a Record

**Possible causes**:

1. The "**Edit**" action is unchecked in their profile → Edit the profile and check "Edit" for the relevant module
2. The record belongs to another user and the **sharing rules** do not allow modification → Check sharing rules or add an exception
3. The record is **locked** → Some modules allow records to be locked (e.g., validated invoices)

### A User Can Create but Not Modify

**Probable cause**: The profile allows "Create" but not "Edit." These two rights are independent.

**Solution**: Edit the profile in *Settings > User Management > Profiles*, check the "Edit" box for the relevant module, then save.

### Shared Lists Are Not Visible to a User

**Possible causes**:

1. The relevant module is **not accessible** in the user's profile → Lists for a module are only visible if the user has access to the module
2. The module is **disabled** → Check in *Settings > Module Manager*

### How to Check a User's Effective Rights

To diagnose a rights issue, check in order:

1. The user's **role**: *Settings > User Management > Users* → view the assigned role
2. The **profiles** associated with the role: *Settings > User Management > Roles* → view the role's profiles
3. The **profile permissions**: *Settings > User Management > Profiles* → edit the profile to see permissions module by module
4. The **sharing rules**: *Settings > User Management > Sharing Rules* → check the module's sharing mode

> **Tip**: If you are an administrator and use Kafinea's AI assistant, you can directly ask questions like "Why can't user john modify leave requests?" The assistant has a permission diagnostic tool that analyzes the configuration and tells you precisely the cause of the problem.

---

## 9. Best Practices

- **Define your hierarchy first**: create roles mirroring your organizational chart
- **Create reusable thematic profiles**: "Sales," "Accounting," "HR," rather than one profile per person
- **Apply the principle of least privilege**: only grant the rights strictly necessary for each function
- **Use groups** for cross-functional teams rather than modifying role hierarchy
- **Document your choices**: note why each profile was configured in a certain way, to facilitate maintenance
- **Test rights**: after a modification, log in with a test account having the modified profile to verify behavior

---

## 10. Frequently Asked Questions

**How Do I Grant Module Access to a Single User?**
 Create a specific profile with access to the desired module, then associate this profile with the user's role. If other users have the same role and should not have this access, create a dedicated role for this user.

**Are Rights Applied Immediately?**
 Yes, profile modifications are applied immediately. The affected user will see the changes upon their next page load. For sharing rules, remember to click the **Recalculate** button after your modifications.

**How Do I Allow Two Teams to Share Their Data?**
 Create a group containing members of both teams, then add an exception in the sharing rules to grant access to this group.

**How Do I Completely Remove Access to a Module?**
 Edit the user's profile and uncheck the module. The module will disappear from the menu and all actions will be blocked.

**What Happens When a User Has Multiple Profiles?**
 Permissions accumulate according to the most permissive principle. If one profile authorizes an action and another prohibits it, the action is authorized. This is useful for combining thematic profiles (e.g., "Sales Access" + "Accounting Access").

**A user says they don't see the "Edit" button on a record. What should I check?**
 Check in this order: 1) Is the "Edit" action checked in the profile? 2) Is the record locked? 3) Do the sharing rules allow this user to modify this record?

---

## Glossary

| Term | Definition |
| --- | --- |
| **Role** | Position in the organizational hierarchy, determines data visibility through subordination |
| **Profile** | Set of detailed permissions (access to modules, actions, fields) associated with one or more roles |
| **Sharing Rule** | Rule defining the default visibility of a module's data between users |
| **Group** | Set of users, roles, or other groups, used for record assignment and sharing exceptions |
| **Global Permission** | Cross-cutting right ("View All" or "Modify All") that overrides sharing rules and hierarchy |
| **Sharing Exception** | Additional rule that grants read or read/write access to a specific role or group |

---

## Related references 🔗

- [Users](https://www.kafinea.com/fr/documentation/parametrage/les-utilisateurs/)
- [The Layout Manager](https://www.kafinea.com/en/documentation/kafinea-interface/the-layout-manager/)