Permissions and supervisors¶
Process access decides who can start a process and who supervises its cases. It is where the process stops being a diagram and becomes something a group of people uses.
Two entries in the current designer
The embedded designer exposes Permissions and Supervisors as separate entries. This page covers both.
Permissions¶
The Permissions section adds a rule. A rule is a combination of what, where and who:
| Field | Meaning |
|---|---|
| Type | The kind of object the rule protects: All, Attachment, Cases Notes, Dynaform, Input Document, Messages History, Output Document, Reassign my cases |
| Target task | The task where the rule applies. The selector reads Select an option until you choose one |
| Group or user | Who receives the access. The field suggests existing users and groups as you type, and it is required |
| Permission | What the rule does: View or Block — plus Delete on an output document and Resend on the message history |
Depending on the type, the window also shows a selector for the specific object — a dynaform, an input document or an output document. With All, the rule covers every object of the task.
Reassign my cases is the exception: it grants a capability rather than access to an object, so it adds its own fields, Origin task and Participation required?, and a case status. Use it when someone other than the assigned user must be able to move a case along.
Adding a rule reports that it was assigned; removing one reports that it was removed. Check the wording when you remove: the confirmation should say removed, not assigned.
How rules combine¶
Access to an object is what the View rules grant, minus what the Block rules take away.
- A user who matches two View rules keeps the object once; access is not duplicated.
- A Block rule wins over any number of View rules. Blocking is how you hide one document from a group that otherwise sees the whole task.
- Removing a rule removes only what that rule granted. Access granted by another rule stays.
- Delete and Resend are actions of their own: they do not appear on the View or Block list, and a rule can carry only one of them.
A worked example¶
The pattern that solves most requests: grant the wide access, then exclude the exception.
- Type All, Permission View, Group everyone. Everybody in the group sees every object of the task.
- Type Output Document, Permission Block, Group everyone, the sensitive document. That one document disappears for the group, while the rest stays visible.
The same shape covers a single person: a View rule for the group, a Block rule for the user who must not see that document. Two rules, no per-user duplication.
Supervisors¶
Supervisors can follow the process: they see its cases in Process Supervisor without being assigned to them.
- Add a supervisor: the page confirms the assignment.
- Remove a supervisor: the page confirms the removal.
A supervisor is not a participant: supervising does not let someone work a task unless the task is also assigned to them.
Who can start the process¶
A process is startable by a user when they are assigned to its initial task, either directly or through a group. If nobody is assigned, the process appears in no one's new case dialog.
That is the usual cause of "the process is active but nobody can start it": the diagram is fine, the initial task has no assignment. Check it here before looking anywhere else.
Permissions to edit this page¶
Editing process access requires design permission for the process. See Permission reference.
Related¶
- Task properties — assignment rules per task.
- Processes — activating the process.
- Process Supervisor — the supervisor's view.