A document approval blocks a generated document from being sent until an approver accepts it. This walkthrough configures one complete example: a letter that the author’s supervisor must approve before the letter can be issued.
Each section covers the decisions and the order of work. For field-by-field detail, follow the links to the reference articles.
How document approvals fit together
Five parts combine to produce a document approval. The document template names an approval model. The model holds one or more approval steps. Each step calls an allocation rule, and the rule returns the user or team who receives the approval task.

Before you start
- You need access to Modeller and to Documents Admin.
- The document template that needs approval must already exist.
- A Supervised By connection must exist for every author whose documents need supervisor approval. See Create a Supervised By connection for a user.
- Clio recommends that you test the configuration in a non-production environment before you enable it for end-users.
Prepare Document is a core work type
Clio Operate flags the Prepare Document work type as CORE. Changes that you make to a core work type might not survive an upgrade. The core product can change the default configuration of the type at any release.
Read the phase plan and the phase feature to understand how approval works. If you need different behaviour, use Create derived type on the work type and configure your own behaviour against the derived type.
Step 1: Choose the approval model
Clio Operate supplies two approval models for the core Prepare Document work type.
| Model | What it does |
|---|---|
Prepare Document - Always Approved |
Approves the document automatically. No approval task is created. |
Prepare Document - Supervisor Approval |
Creates an approval task for the author’s supervisor. |

A separate pair of models covers the Prepare Document: Internal work type. Your own environment can hold further models, so the list you see might be longer.
The rest of this walkthrough uses Prepare Document - Supervisor Approval. To review the model, navigate to Modeller > Rules > Approval models, then open it.

| Setting | Value on this model |
|---|---|
| Approval Type |
Phase Transition. Document approvals must use this type, because the approval controls the movement of the document from one phase to the next. |
| Sharedo Type Context |
/task/task-activity/task-activity-prepare-document/. The work type that the model applies to. |
| Always Approve |
No. Set this to yes only for a model that approves everything, such as Prepare Document - Always Approved. |
| Is enabled | Must be enabled before the model can be used. |
For the full list of settings on an approval model, see Create an Approval Model.
Step 2: Check the phase plan and the phase feature
The core Prepare Document work type includes an Approving phase and a Rejected phase as standard. You do not need to create them.

Four transitions matter here.
| Transition | What it does |
|---|---|
Approving |
Moves the document from Verifying into Approving. The approval task is created at this point. |
Approve |
Moves the document from Approving to Ready to Send. |
Reject |
Moves the document from Approving to Rejected. |
Approval Not Required - Complete |
Moves the document from Verifying straight to Ready to Send, and skips approval. |
To see how the approval is wired to the phase, open the Approving phase, then expand Manage Phase Features.
Helpjuice Warning Callout Body

Select the arrow beside Approval Phase configuration to open the feature.

| Field | What it does |
|---|---|
| Approval Model | Read only here. Approval models are configured against individual document templates, so this feature uses whichever model the template names. |
| Approved Transition | The transition that runs when the approver approves. On this phase, Approve (to Ready to Send). |
| Rejected Transition | The transition that runs when the approver rejects. On this phase, Reject (to Rejected). |
| Enable valid approvers to approve in-line | Lets a valid approver approve from the work item itself, rather than from the approval task. |
| Message for valid approvers | An alternative message for in-line approvers. Leave it blank for the default approval message. |
| Allow originator to retract approvals | Lets the author withdraw an approval request after it has been sent. |
For the wider set of phase features, see Phase Features.
Step 3: Configure the approval task
Open the approval model, then select the edit icon on the approval step. The Approval Task panel controls the task that the approver receives.

| Field | What it does |
|---|---|
| Task Type | The type of task that Clio Operate creates. Approval is a dedicated task type that links to the document work item. |
| Title | The task title that displays in the approver’s worklist. Tags insert values from the work item. On this model the title is Approve - workitem.title. |
| Description | The longer description that the approver reads on the task. Tags are supported here too. |
| Priority | Displays as the coloured flag on the left of the worklist. Approvers can filter their list by priority. |
| Due Date Offset | The period from the day of creation until the task is due. Choose the unit, for example Working Days, then enter the number. |
| Process Tags | Identifies specific task instances so that an execution engine plan can trigger further workflow. |
Description is not a default column in the worklist. Add the column to the worklist configuration if your approvers need to read the description without opening the task.
Step 4: Set the approval assignment
The Approval Assignment panel names the allocation rule that resolves the approver. Prepare Document - Supervisor Approval uses the Lookup supervisor rule.

The rule itself lives at Modeller > Rules > Allocation Rules. You can also open it directly from the Assignment Rule field.
Lookup supervisor holds a single criterion that assigns on Core - Existing Role Membership with ODS Connection.

| Field | Value on this rule |
|---|---|
| When the rule matches | No business rule is selected, so the criterion always applies. |
| Then assign based on |
Core - Existing Role Membership with ODS Connection. |
| Participant Role |
Primary Owner. On a Prepare Document task, the Primary Owner is the author of the document, unless someone has changed the ownership. |
| ODS Connection | Two parts. The connection type is Supervision, and the direction is Supervised By. Change the direction to Supervises to resolve the other way round. |
Helpjuice Warning Callout Body
Other ways to resolve an approver
Supervision is one option among several. A rule can also resolve an approver from a role on the case, for example the matter partner. It can resolve from a team, for example a team of team leaders.

For what each option does, see Create an Allocation Rule.
Add more criteria to the rule
An allocation rule can hold any number of criteria. Add one with Add line at the top right of the Allocation Rule Designer panel.

Clio Operate processes the criteria from top to bottom and stops at the first match. Reorder them by dragging.
If no criterion matches, Clio Operate uses the Default Allocation on the rule. The default can be a user or a team.

Step 5: Decide whether approvals can be skipped or reassigned
Auto approval
Auto approval covers the cases where no approval is needed. Where an auto approval applies, Clio Operate creates no approval task and moves the item straight to its approved phase.

- Auto approve if the approval originator is a valid approver (enable self approval): whether the author can approve their own document, in the case where the allocation rule returns the author as the approver. If you leave this off, Clio Operate adds the originator to the step as a restricted approver.
- Auto approve if business rules are satisfied: if the selected business rule returns true, Clio Operate approves the document automatically. For example, the rule can test the author’s seniority, or a competency on their profile.
In a multi-step approval, auto approval skips only the steps whose business rule returns true. Tiered approval, for example by value, is built this way.
Valid and restricted approvers
Two sections control what happens if the approver reassigns or delegates the approval task.

- Valid Approvers for Manual Reassignment: the users or teams who are authorised to perform the approval. Clio Operate adds them to the approval task as a security barrier. The person that the allocation rule returned is always a valid approver.
- Restricted Approvers for Manual Reassignment: the users or teams who must never receive the approval task by reassignment or delegation.
Both sections apply to manual reassignment only. Neither limits the allocation rule itself.
If a reassignment breaks one of these limits, Clio Operate blocks the reassignment and displays a warning.

For more on how these limits work, see Security Barriers.
Step 6: Add further approval steps
Add a step with the plus icon at the top right of the Approval Steps panel. Clio Operate processes the steps from top to bottom. After the approver completes step 1, Clio Operate creates the approval task for step 2.
If an approver rejects any approval task, Clio Operate closes and removes the task, then marks the document as rejected. The author can amend the document and complete it again. The approval process then restarts from step 1.
Step 7: Attach the model to the document template
- From the launchpad, select Open Documents Admin, then select Document Templates.
- Open the template, then expand Approval.
- Select the model in Default Approval Model.

- Select Confirm, then save the template.
The Default Approval Model list shows every approval model whose Sharedo Type Context matches the work type of the template. A firm that has built its own models sees those in the list too.
Set a different model for users who hold a competency
Two fields below Default Approval Model create an exception to it.
- Except when the user has one of the following competencies: the competencies that trigger the exception.
- When the following approval model should be used: the model that applies to those users instead.
An author who is experienced enough not to need supervision is the usual case. To remove approval altogether for those authors, select Prepare Document - Always Approved as the alternative model.
For the other settings on a template, see Creating a Template. For competencies, see Defining Competencies.
What your end-users will see
When the author completes the drafting task, Clio Operate creates two tasks in the worklist: the document task and the approval task. The document task cannot be emailed or issued until the approval is granted.

The approval task belongs to the approver that the allocation rule returned. Other users cannot change the assignment.
An approval task always arrives in the approver’s inbox. Your end-users control emails and in-app notifications in their own notification settings.
You can add dedicated worklists to the workbench. For example, a list of pending approvals for authors, and a list of approvals awaiting action for approvers.
For the approver’s side of the process, see Working with Approvals.
If the approval does not behave as expected
| Symptom | Likely cause |
|---|---|
| The approval task went to the wrong person, or to a team | The Primary Owner has no Supervised By connection, so the rule used its Default Allocation. Check the connection on the author’s profile. |
| No approval task was created, and the document was approved | One of three things applies. The template names Prepare Document - Always Approved. An auto approval business rule returned true. The author holds a competency listed on the template. |
| The document is approved but still cannot be sent | The document has not reached Ready to Send. Check the Approved Transition on the Approval Phase configuration feature. |
| A reassignment fails with a security barrier warning | The valid or restricted approver settings on the approval step exclude the target user or team. |
| The model does not appear in Default Approval Model | The Sharedo Type Context on the model does not match the work type of the template. |