Permissions and roles

How access works

Kashef combines job roles, access roles, direct user overrides, and subscription feature checks. The job roles are Admin, 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.

Admin and Manager

Admin is the previous Manager role, renamed without changing existing accounts or their full access. Manager has the same daily-work permissions, excluding Lab Settings, Branch Settings, Subscription, Custom Domain, Activity Log, Backup & Restore, and Reset Data.

Choose Manager for daily supervision and Admin for the person responsible for company configuration. Managers can manage ordinary staff and roles, but cannot assign permissions they do not hold or manage Admin accounts unless an Admin explicitly delegates those permissions. Keep at least one Admin account.

Configurable workflow permissions

The permission list includes barcode relabeling, sample pooling and rerouting, order-checklist overrides, lab-incident management, company support coordination, skipping refund confirmation, authorizing Kashef Desktop and Connect, and viewing local emergency status. These actions follow assigned permissions rather than a job title. Assign only the controls needed for the person's responsibilities.

Custom Domain and Activity Log have separate controls, so website editing and staff viewing do not automatically grant those areas. Admin-account management and assigning permissions beyond your own access are separate administrative permissions.

Role records

Roles are managed from Admin > Team & Access > Roles & Permissions. 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.

Entering results versus releasing them

Orders: Enter Results allows entering and saving values. Orders: Approve Results allows approving and rejecting results. Orders: Release Results allows releasing results that have already been approved. Approval and release can be assigned independently to any custom role or directly to an individual user.

In Roles & Permissions, select the required permission in Resources > Orders and save the custom role. For one person, open their user profile and add a direct grant or deny. A deny takes precedence over role permissions. Staff with either approval or release access can open the review sheet and results queue without result-entry permission. Release access does not allow approval, and approval access does not allow release.

Admins and Managers have all three permissions by default; technicians have result entry only. Existing combined approval/release grants and denials carry over to both new permissions. Release still requires approval and the usual payment, sample, and QC checks.

Letting staff give custom discounts

Only Admins and Managers can apply a custom (special) discount to an order by default. To allow a receptionist or another role, tick Orders: Apply Custom (Special) Discount in the Orders section of the Resources tab. To allow one person only, add it as a direct grant on that user's profile instead of changing the whole role. The person also needs Payments: View, which receptionists already have, because the discount is applied from the order's payments page.

Permissions Matrix

Open Admin > Team & Access > Roles & Permissions and select 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.