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
Conceptual guidance, not a UI screenshot or portal evidence.
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
Conceptual guidance, not a UI screenshot or portal evidence.
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 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
Conceptual guidance, not a UI screenshot or portal evidence.
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.
What a policy controls
Conceptual guidance, not a UI screenshot or portal evidence.
The module selector covers tasks and CRM as well as workflows, chats, projects, users, company, time, automation, the AI assistant, operations, and documents. Choose a scope (company, department, pipeline, stage, project, or user) and a role. For a department, the value can be explicit, inherited from its parent, or taken from the module fallback; Apply to children propagates it down the tree. In an explicit rule, Create and Manage are separate from Read and Write.
Task policies also control assignment down, up, and sideways between departments. Limit direction, depth, target roles, and allow/deny user lists separately from object visibility. For CRM, deal visibility and pipeline/stage targeting belong to the same policy; leave those fields blank when no such scope is intended.
For modules with an automation schema, the editor also shows capability-level controls below the CRUD rights. Set each capability to Allow, Deny, or Inherit; this is separate from read, edit, and manage rights. Bulk actions can set all capabilities at once. For the assistant module, optional presets cover replies, replies plus actions, or reset to inheritance. They only set policy values: they do not run automation or change data.
When a department rule takes its value from a parent or from the module fallback, capability controls are disabled until an explicit source is chosen. If a module has no loaded capability schema, the block shows that state instead of accepting a hand-written technical capability name.
For Operations, the list starts with rights registered for the Operations module and human-readable localized labels. A right already saved in the policy stays visible even if it is outside the normal module list, so it can be reviewed and changed deliberately. A shorter list does not remove access: before saving, check Allow, Deny, or Inherit for every visible right and do not type a technical name by hand.
Reviewing and undoing changes
Conceptual guidance, not a UI screenshot or portal evidence.
Deleting a rule or applying a previous revision requires a reason. Long history summaries can be expanded. CRM administrators can run Explain or Simulate to inspect access without changing the policy.
Default access mode
Conceptual guidance, not a UI screenshot or portal evidence.
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
Conceptual guidance, not a UI screenshot or portal evidence.
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.
The journal uses human labels for changed fields and does not expose internal field names,
system labels or technical details. If a field has no mapped label, it is collapsed into a +N summary
instead of revealing technical data. After saving a rule, the registry switches to
that rule’s module so the new row remains visible; verify it there and then re-read
resulting access.
Good practices
Conceptual guidance, not a UI screenshot or portal evidence.
- 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
Conceptual guidance, not a UI screenshot or portal evidence.
- 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.
Related sections
Conceptual guidance, not a UI screenshot or portal evidence.