Access and roles
Access defines who sees and can do what in the portal. For an owner and administrator it is not a set of checkboxes but a model of responsibility: an employee works with their own tasks and clients, a head sees their department, and other people's data stays closed unless access is granted deliberately.
This page explains the access model. Configuration lives in the portal administration section — see Portal administration.
Roles
Access is built on three roles:
- Administrator — configures the portal, rights, and policies; sees and manages a broad perimeter.
- Head — is responsible for their department or line of work; sees their team's work.
- Employee — works with their own tasks, clients, and materials.
A role sets the base level of access, while precise rights are refined by policies for scopes and modules.
Access scopes
Access is granted not "to everything at once" but by scope. A scope is the boundary within which a right applies: the whole company, a department, a sales pipeline, a stage, a project, or a specific user.
This way the same employee can have broad access in their own project and none in someone else's. It lets you open up exactly what is needed for the work without revealing anything extra.
Rights: read, edit, manage
Within each scope a right is made up of levels:
- Read — see objects and their contents;
- Create — start new objects;
- Edit — change existing ones;
- Manage — configure access and rules in this scope.
Separate the levels deliberately: the right to see does not mean the right to change, and the right to work does not mean the right to hand out access to others.
Default access mode
Each module has a default access mode — what happens when there is no explicit rule:
- Strict — access is closed by default; only what a policy explicitly allows is opened. Suited to sensitive data and large companies.
- Open — read and work access is open by default, while policies restrict individual scopes. Suited to a small team with high trust.
It is safer to start with strict mode in modules that hold client and financial data and to open access as the need arises.
Change history and reason
Changing access is a management decision, not an invisible edit. That is why, when a policy changes, the system asks you to state a reason for the change, and the edit history is preserved: you can see who changed access, when, and why.
This matters for control and incident review: if someone saw too much or, conversely, lost access, the history makes it clear which change led to it.
Good practices
- Grant access by scope and role, not "just in case" across the whole company.
- Separate the right to see from the right to change; give the right to manage access to a narrow circle.
- Keep strict default mode in modules with client and financial data.
- When changing a policy, write a clear reason — it stays in the history.
- Review access periodically: remove what is no longer needed as roles and projects change.
Common mistakes
- Granting broad access across the whole company instead of access by scope.
- Confusing the right to see with the right to change — an employee accidentally edits someone else's data.
- Leaving open mode as the default in a module with sensitive data.
- Changing policies without a reason — later it is impossible to work out why access ended up this way.
- Not reviewing access after a role change or the end of a project.