Case access

QMPlus checks several access rules before it displays a case. Passing one rule does not always end the process: restrictions configured on the case or its form may still apply.

This page describes access when someone opens an individual case. Visibility in case lists, searches, reports, and department filters may have additional rules.

Access checks in order

1. Identity and organization

QMPlus first confirms that:

• The user has a valid login or API token.
• The organization exists and is active.
• The organization’s subscription permits access.
• The user’s current roles and permissions can be loaded.

This establishes who the user is, but does not by itself grant access to a particular case.

2. Case and record

QMPlus confirms that the requested case type is supported and that both the case and its underlying record exist.

The underlying record may be a message, action, document, hearing, audit, CRM record, or advanced checklist. Access stops if the requested record cannot be found.

3. Roles required by the case

A case can contain its own list of required roles. When it does, the user must normally have every role listed on the case.

These requirements are checked before follower access, task participation, creator access, or general case permissions. A QMPlus super administrator can bypass roles stored directly on the case.

4. Pending hearing and audit assignments

Hearings and audits have an assignment-based access route. A user included as a participant in a pending task can open the case without the ordinary processing permission for that case type.

Roles required directly by the case still apply.

5. Message followers

A follower of a message case may be allowed to open it according to the form’s follower-access setting.

Follower access is an additional route to reading a message case. It does not override roles required directly by the case or additional form restrictions.

6. General case permissions

If an assignment or follower rule has not granted access, the user needs at least one suitable general permission. Examples include:

• QMPlus super administrator
• Permission to see other users’ cases
• Permission to see all messages
• Permission to process the requested type of case

Processing permissions are specific to the case type. Messages, actions, documents, hearings, audits, CRM records, and advanced checklists do not all use the same processing permission.

See Application permissions for the complete permission catalogue.

7. Access for the case creator

The person who created a case may still be allowed to open it when they do not have a suitable general processing permission, provided the earlier case and form restrictions are satisfied.

In this situation, QMPlus returns a limited case view containing general information such as:

• Name and status
• Important dates
• Departments
• Categories and tags
• Basic metadata

Detailed information such as tasks, fields, attachments, references, and followers is not returned.

A user who did not create the case and has no other valid access route is denied access.

8. Roles required by a message form

A message form can define additional required roles. When this restriction applies, the user must have every role required by the form.

Form roles are an additional restriction. They are not an alternative way to gain access.

See Custom permissions for guidance on configuring role-controlled forms and messages.

Access outcomes

Being able to open a case does not automatically grant permission to edit, transition, close, delete, download from, or otherwise change it. Those operations can perform their own checks.

Departments and direct case access

The direct case-access decision described on this page does not compare the user’s current department with the departments stored on the case.

Department selection is still used elsewhere in QMPlus, including list filtering, visibility, case routing, and audit context. A case appearing under a department is therefore not, by itself, a guarantee that every user in that department can open it.

Access history

QMPlus records case access information for security and audit purposes. An access record can include the user, user type, department, IP address, and time.

An attempted read may be recorded before every access check has completed. The access history can therefore include an attempt that was ultimately denied.

Troubleshooting

For an overview of finding and working with cases, see Cases.