Permissions and roles

How access works

Kashef combines job roles, access roles, direct user overrides, and subscription feature checks. The classic job roles are Manager, Operations, Technician, and Receptionist. Access roles are more detailed permission bundles for the current lab company. Direct user permissions can grant or deny individual permissions when a specific person needs an exception.

When the system checks a permission, it first checks the user's access role and overrides. If no access-control setup exists for the lab company, it falls back to the legacy job-role defaults. After that, subscription feature availability is checked, so a role cannot unlock a feature that the current plan does not include.

Role records

The Roles resource stores access roles. Each role has a name, slug, description, permissions list, system lock flag, legacy preset value, permission count, user count, and update time. Default system roles are provisioned automatically for the lab company and stay locked. Custom roles can be created for local teams such as Branch Supervisor, Senior Technician, Finance Reviewer, Inventory Keeper, or Website Editor.

The slug is a stable internal reference. It is generated from the name but can be edited before saving. Keep slugs readable and avoid renaming them unless the role purpose truly changes.

System roles open as read-only review pages. Their name, slug, description, and permission checkboxes cannot be changed, and no save or delete action is available. Kashef refreshes these roles from application defaults so they remain aligned with supported workflows and new permission keys.

Custom roles are company-scoped and editable. The create and edit forms reject an empty normalized slug, a slug already used in the same lab company, permission keys outside the current catalog, and any attempt to submit a role for another company.

Permission tabs

Permissions are organized into tabs for Resources, Pages, Widgets, and Custom Permissions. Inside each tab, permissions are grouped into sections with checkbox lists. This helps administrators scan by subject instead of reading a flat list.

Examples include orders, samples, patients, catalog, pricing, lab-to-lab, inventory, quality control, CRM, finance, admin, AI assistant, website management, and automations. Each permission usually describes both the subject and the action, such as view, create, update, delete, manage, approve, post, receive, dispatch, print, or override.

Permissions Matrix

Use Permissions Matrix for a read-only comparison before changing roles. It shows every company system and custom role as a column and groups permission rows by domain. A check means the permission is bundled into the role; a minus means it is not. Each role heading also shows whether it is a locked system role or custom role and how many users are assigned.

Expand only the permission groups relevant to the review and scroll horizontally when the company has many custom roles. Permission keys are shown below their labels so support and administrators can discuss an exact rule without relying on translated wording. Select Manage roles to edit the underlying custom role or Create custom role to add a reusable responsibility bundle. The matrix itself never changes access.

Editing a role safely

Before changing a custom role, check how many users are attached to it. A role with many users may affect reception, technicians, finance, inventory, and managers at once. If you need a temporary exception for one person, use a direct user permission instead. If the change should apply to a whole staff group, edit the role.

Use the permission count as a quick sanity check. A role with too many permissions may be too broad. A role with too few permissions may produce confusing missing actions during daily work.

Kashef blocks deletion while any user still has the custom role. Remove or replace the role on every affected Users profile first, then return to Roles and delete it. System roles can never be deleted. Role creates, edits, and deletes are written to the activity log.

Table and actions

Search by role name or internal slug. The table identifies system presets versus custom roles, shows whether the role is locked, and displays permission count, assigned-user count, and last update time.

Select Review for a system role to inspect its permission bundle. Select Edit for a custom role to change its details and permissions. Select Create role only when the responsibility will be reused by multiple staff members; direct user overrides are the better choice for one-person exceptions.

Direct user overrides

Direct permissions are configured on the user form. A direct grant allows an action even if the attached roles do not provide it. A deny blocks a permission even if a role includes it. Grants and denies are stored per lab company, so the same user can have different access across multi-branch contexts.

Use overrides for named exceptions and document the reason internally. For example, one senior technologist may need QC override release permission, or one operations user may need dispatch assignment permission. Do not use overrides to compensate for poorly designed roles across the whole company.

Permissions and auditability

Access control affects audit logs. If several people share one broad account, the activity log cannot tell who changed a result, posted a receipt, approved a transfer, or edited a patient. Strong permissions are useful only when user accounts are individual and roles are reviewed periodically.

Review roles after adding new branches, enabling new subscription features, changing finance responsibilities, or introducing automations. New pages may introduce new permission keys, and custom roles should be updated intentionally rather than relying on manager-level access everywhere.

Checklist

• Default system roles exist and are understood before custom roles are created.
• The Permissions Matrix is reviewed before broad role changes.
• System roles are reviewed but never edited or deleted.
• Custom roles describe real responsibilities, not temporary staff names.
• Role permission counts match the expected breadth of the role.
• Assigned users are removed or moved before a custom role is deleted.
• Direct user permissions are rare and tied to a clear reason.
• Managers review roles after workflow, finance, inventory, website, or branch changes.
• No shared accounts are used for controlled actions.