An approval workflow is a mechanism that prevents an SOP from being issued or revised unless the designated people approve it. If you choose an approval workflow and publish, the SOP will not be published until all approvers have approved it.

Only customers on the Pro and Enterprise plans can use this feature. Settings are made from a PC browser.

Types of approval workflows

There are two types of approval workflows: “Company-wide,” which everyone on the team can choose, and “Group approval workflow,” which only people who belong to that group can choose. You can create as many of each as you need for different purposes, and you choose one when publishing an SOP.

Company-wide approval workflow – Can be created by Owners and Team Administrators. Everyone on the team can choose it. It can also be used by teams that have not created any groups.
Group approval workflow – Can be created by a Group Administrator of that group or above. People who belong to that group can choose it.

Create an approval workflow

Click the person icon (User management) in the sidebar.
In the target bar at the top, select “Company-wide (team)” to create a Company-wide approval workflow, or select the target group to create a group approval workflow.
Click [Approval workflow] in the target bar.
Click [Create], then enter a name (for example: Review registration flow) and a description.
For each step, set a label and the approver conditions (see “Specify approvers” below).
Click [Save].

From the list, you can edit, duplicate, disable, or delete the approval workflows you have created. When you disable one, it stays in the list but can no longer be selected when publishing.

Specify approvers

An approval workflow does not name specific people directly. Instead, you set “the position of the person who approves.” Who actually approves is determined by the initiator, and by the initiator's affiliation and qualification status at that time.

You can set the following five conditions for each step.

Higher up as seen from the initiator – Based on the initiator's affiliation, people who hold the target permission in the initiator's Group Affiliation, one group up, two groups up, or three groups up become candidates. One approval workflow can be used across all departments.
Group administrator – People who hold administrative permission in a specified group become candidates. Use this to designate a department at the same level, such as safety managers or quality assurance.
Administrator within the team – Regardless of group, people who hold the target permission across the entire team become candidates.
A specific person – You name a person directly. Because approvals tend to stall when someone is transferred or leaves, we recommend specifying a group instead.
Holder of a qualification – People who currently hold the qualification become candidates. People whose qualification has expired are automatically removed from the candidates.

If you list several conditions in one step, anyone who matches any one of them becomes a candidate (for example: Line manager or Holder of a qualification). You can give a step a label such as “Line manager” or “Safety manager.”

“Any admin permission,” which you can choose when narrowing candidates by permission, means that people who hold any one of the following roles become candidates: Owner, Team Administrator, or Group Administrator.

Only people with the Owner, Team Administrator, or Group Administrator permission can become approvers. A person named as “A specific person” must also hold one of these three permissions. Created user, View-only user, and Guest cannot be named. The exception is “Holder of a qualification”: regardless of permission, anyone who currently holds the qualification becomes a candidate (Created users and View-only users can also become approvers this way). Also, if you change the permission of a person you have already named to a level below Group Administrator, that person is removed from the approver candidates.

Advanced settings (type, pass condition, do not wait for approval)

Open [Advanced settings] for each step to configure the following three options. If you leave it closed, the step works in the default way: “Arrange approval steps in order.”

Type – “Approve” is final sign-off, and “Review” is a check of the content. They are recorded separately in the approval history.
Pass condition – “Pick one when raising”: the initiator names one person from the candidates. “Any one”: approval from any one candidate is enough to pass. “All”: approval from all candidates is required, in any order.
Do not wait for approval – When this is on, people in that step only receive a notification, and the process moves on to the next step without waiting for their approval. This can only be set when the type is “Review.”

Check who it goes to

Because approvers are specified by position, the actual approvers change depending on who the initiator is. If you temporarily select an initiator in [Check who it goes to] on the edit screen, the approvers for that initiator are displayed. The selection here does not affect the saved content.

If a step cannot be resolved, that initiator cannot start a request. For example, if a person who belongs to the top-level group goes through a step set to the Group administrator of “One group up,” no approver can be determined because there is no higher group.

Set the default approval workflow

At the top of the List of approval workflows screen, you can choose “Company-wide default” or “Default for this group.” An approval workflow set as the default is already selected when you publish an SOP. The initiator can also choose a different one.

Link revision reasons to approval workflows

Register the “Revision reason” you choose when publishing, and link an approval workflow to each reason. Once linked, the matching approval workflow is selected as soon as that reason is chosen.

On the List of approval workflows screen, open [Revision reason].
Set the reason name (for example: allergen-related change, correction of a typo) and the Mapped approval workflow.
If needed, set a “Reason preselected from the start” for “When publishing for the first time” and for “From the second time onward (revisions).”

If you set as the default a reason linked to an approval workflow without any approval steps, the SOP will be published without approval as long as the default is left as it is. Please be careful when configuring this.

Request approval

On the SOP edit screen, click [Publish] to display the screen for choosing an approval workflow.

Choose a revision reason (if one is set).
Choose an approval workflow. Company-wide and group approval workflows are listed together in one list.
If you belong to more than one group, choose “Which affiliation should it be based on?” Approvers such as “Line manager” are determined based on the affiliation you choose here.
For a step set to “Pick one when raising,” choose an approver from the candidates. No need to name anyone if there is only one candidate, or for steps set to “Any one” or “All.”
Click [Request].

If a step has no approver determined, you cannot start the request as it is. Choose a different approval workflow, or ask your administrator to check the settings. If an approver cannot view the storage folder, a message will tell you so. The request is still delivered, and the approver can check the content of this submission, but they will not be able to open the SOP after it is published. Approval itself can be done even by approvers who are not allowed to edit the storage folder. On the other hand, if the initiator has chosen a storage folder that they cannot view themselves, you cannot start the request. Please choose the folder again, and then submit the request.

When a request is started, the approvers and step details at that time are kept on the requester's side. Even if you edit the approval workflow later, requests that have already been started are not affected.

Choose whether to require a re-check after revision

When you request approval for a revised version of an SOP in a team that uses the Skill Map (Core, Pro, and Enterprise plans), under “Re-check after revision” you can choose whether to ask the person who performed the previous version to re-check the revised version. For revisions that do not change the content, such as typo fixes, choose [Do not require re-check for this revision (typo fixes, etc.)]. The approver sees the initiator's selection, so if it is wrong, reject the request and let the initiator know. When publishing without approval, only the selection by an Owner, Team Administrator, or Group Administrator is attached. For details, see Managing re-checks after revising an SOP (deadlines, response records, no re-check needed, record export).

Approve or send back

Approvers are notified by email. Open the target SOP from “Drafts / Approvals,” check the content, and then either approve it or reject it (send it back).

When you send an SOP back, you choose where the process resumes after the initiator has made corrections. The default is “Start over from the beginning.” If you choose “Allow resuming from my step,” the process resumes from the step of the person who sent it back. Use this for minor changes, such as correcting a typo. Owners can prohibit this option in their settings.

Add the next approver when approving

If you decide during approval that “this content should also be seen by someone else,” you can add a person to approve after you when you approve. This can be used when the Owner has turned on [Allow approvers to add the next approver after themselves when approving] under “Approval settings” (see “Set approval rules (owner)” below).

On the approval screen, in the [Add approvers (optional)] field, choose the person you want to add from [Select who approves after me].
Check the content and approve.

The person you chose joins as an approver for the step right after yours.

If you choose more than one person, all of them receive the request, and the process moves on once any one of them approves.
Only people with the Owner, Team Administrator, or Group Administrator permission can be added. You cannot choose yourself or people who are already in the current step or a later step.
If you add someone to a step that requires approval from all, the request is sent to the added person after everyone in that step has approved.
Even when an SOP is sent back and resubmitted, the added step remains. If the request is withdrawn, the added step is not kept.
If you choose someone who cannot view the storage folder, a message will tell you so. The request will be delivered, but they will not be able to open the SOP after it is published.
This field is not displayed for steps whose type is “Review.”

For how to re-edit an SOP that was rejected (sent back) in an approval workflow, see How to re-edit an SOP rejected (sent back) in an approval workflow.

Withdraw a request

The initiator can withdraw a request while the approval is in progress. Click [Withdraw], which is next to “In approval flow” at the top of the SOP, and the SOP returns to draft. You can then edit it and resubmit it. This can also be used when approval cannot move forward, for example because an approver has left the company or been disabled.

Only the person who submitted the request can withdraw it. The withdrawal is recorded in the revision history.

Set approval rules (owner)

Who approves is set in User management, while what is permitted is set by the Owner. In the [Business rules] tab of [Owner Functions], you can configure the following seven items under “Approval settings.”

Check the expiration date of qualification-based approvers at the time of approval too (default: on).
Allow the initiator to also be an approver (default: off).
Allow publishing without approval (default: off).
Allow building an approval workflow on the spot when publishing (default: off).
Allow approvers to add the next approver after themselves when approving (default: off).
Allow resuming from the step of the person who sent it back (default: on).
Require choosing a revision reason when publishing (default: off).