Internal roles, external users and scopes of visibility

Users and permissions

2 min readUpdated August 2026

Permissions in Xedul mirror the practice's real responsibilities: who governs, who works on cases, who may only see what concerns them.

The roles

RoleScope
**Admin**Practice governance: settings, user management, configuration of states and mandatory fields. Full access to the organisation's work
**User**Daily work on the practice's clients, cases, tasks and documents
**External user**Limited access to only the information that concerns them

Inviting someone

From the Users section, an admin sends an invitation with an email address and a role. The invitee receives a message, sets their own password and enters the practice's space.

A user belongs to exactly one organisation. There is no account spanning several practices: that's a direct consequence of the data isolation model.

External users

The external user is designed for someone outside the practice who nonetheless takes part in the work: the client themselves, a consultant, an occasional collaborator.

The scope is narrow by construction: they see the information that concerns them and have no visibility into the rest of the organisation — neither other client records nor other people's cases.

Before enabling external access, check what is actually visible using a test account. It's quicker than finding out afterwards.

Changing someone's role

A role is changed from the user record. The change takes effect on subsequent access: it's worth verifying together with the person concerned, particularly when reducing a scope.

Who sees what

Scope of visibility follows the role and, for external users, the link to work entities. In practice:

  • Admin — all the organisation's work, plus settings.
  • User — the organisation's work, without governance of settings.
  • External user — only what they are linked to.

Traceability

Actions on work entities leave a trace. It serves two distinct but equally concrete purposes: reconstructing what happened on a case, and answering a client who asks when a given piece of work was carried out.

Good practice

  • Few admins. The role is for governance, not daily work.
  • One user per person, never shared accounts: a shared account destroys the value of traceability.
  • Periodic access review, particularly of external users no longer active.
  • The minimum sufficient role at onboarding, widened later if needed.
Users and permissions — Xedul