We have significantly revised the "Approval workflow" that approves SOP publication and revisions. In addition, Dive can now recognize the language in which an SOP is written, so translation and text-to-speech now operate based on that language.
1. Major overhaul of approval workflows
Until now, the approval workflow was limited to one per group affiliation, and approvers were selected from the administrators of that group and higher groups. Cross-functional departments such as quality assurance and safety management could not be assigned as approvers, and it was not possible to change the routing based on the content of the revision. This release introduces the following improvements. Approval workflows are a Pro plan and higher feature.
We can now provide company-wide approval workflows
You can create as many as needed for different purposes and select from them when publishing an SOP. Teams that have not created any groups can now use approval workflows.
The setting location is the person icon in the sidebar (User management). When you select "Company-wide (team)" in the target bar at the top and click "Approval workflow", you get the company-wide version; when you select a group and then click, you get that group's dedicated version.
- Company-wide approval workflow ... Can be created by the owner or team administrator, and can be selected by everyone on the team
- Group approval workflow ... Can be created by the group administrator or higher for that group, and can be selected by members of that group
Approvers can now be specified by "position" such as job title or credentials
Previously, approvers were designated by naming individuals directly. Now you can set which "position" of person approves at each step. Who actually approves is determined by the initiator and their affiliation and credential status at that time.
- Higher up as seen from the initiator ... Based on the group affiliation of the person who initiated, you designate administrators of that group / one level up / two levels up / three levels up. A single approval workflow can be reused across all departments
- Group administrator ... You designate someone with administrative authority in a specific group. Use this when designating cross-functional departments such as safety managers and quality assurance
- Administrator within the team ... Regardless of group, you designate someone who has the target permission across the entire team
- A specific person ... You designate a person directly (same method as before)
- Holder of a qualification ... You designate someone who validly holds that qualification. Those whose credentials have expired are automatically removed from candidates
When you list multiple conditions in a single step, anyone matching any of those conditions becomes a candidate (for example: direct supervisor OR holder of standardization qualification). Steps can be labeled with names like "direct supervisor" or "safety manager".
Since designations are by position, we have added a "Check who it goes to" button in the edit screen so that whoever configured it can verify "who will ultimately approve". If you provisionally select an initiator, the approver at that time will be displayed.
In the "Advanced settings" for each step, you can configure the distinction between approval and review, passage conditions (pick one when raising / pick any one / all), and reviews that do not wait for approval. If you do not open it, the workflow is simply set up the traditional way with approvers lined up in order.
You can now select the approval workflow and revision reason when publishing
Previously, the approval workflow for your group affiliation was automatically used, but now you select the approval workflow on the publish screen and confirm the approver on the spot.
- For steps marked "Pick one when raising", you designate the actual approver from the candidates
- If you belong to multiple groups, you select "Which affiliation should it be based on?". Approvers such as "direct supervisor" are determined based on the affiliation you choose here
- If there is a step where no approver can be determined, the system displays which step and does not start the request
- If there is an approver who cannot view the destination folder, we will notify you
When you register revision reasons such as "Changes related to allergens" or "Correction of typos" and map an approval workflow to each, selecting that reason at publish time automatically selects the mapped approval workflow. You can also set company-wide defaults and defaults per group.
Also, when a request is started, the approvers and step details at that time are recorded on the requesting side. Even if you edit the approval workflow later, ongoing requests are not affected.
You can now specify the resume position after a revision is sent back, and withdraw requests
Previously, when a sent-back SOP was corrected and re-requested, it always had to start over from the first step. In this release, the person sending back can now choose either "Start over from the beginning" or "It may resume from my step (for minor fixes)". The default is "Start over from the beginning".
Additionally, if a request gets stuck because an approver has resigned or been deactivated, the person who initiated it can withdraw it and return it to draft. You do this from the "Withdrawal" button next to the "In approval flow" indicator at the top of the SOP. The withdrawal record remains in the revision history.
Owners can now set approval rules
The contents of the approval workflow (who approves) are set by the operations staff from User management, and what is approved is now decided by the owner. We have added "Approval settings" to the "Security" tab in Security Settings.
- Approvers with credentials as a condition will also verify validity at the time of approval (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 resuming from the stage of the person who sent back the revision after it is sent back (default: on)
- Require choosing a revision reason when publishing (default: off)
With the setting to verify credential validity at the time of approval, expired approvals do not leave a record. If an approver becomes unavailable due to expiration or other reasons, it automatically redirects to a valid person within the same condition (position).
Impact on existing settings
Approval workflows previously set on groups are carried over as-is as "that group's approval workflow". The approvers, step order, and approval routing do not change. What changes is the location where you edit it: instead of the group's [...] menu's "Approval workflow settings", you now edit it from "Approval workflow" in the target bar of User management.
2. You can now set the "original language" of SOPs
Until now, Dive did not know what language an SOP was written in. For this reason, when SOPs written in languages other than Japanese were read aloud as-is without translation, the synthesized voice did not always sound correct (almost silent in Vietnamese and Indonesian, Japanese-like romanized pronunciation in Portuguese, etc.).
SOPs now have an original language, and translation and text-to-speech now operate based on that language. The text-to-speech rendering of an SOP does not change based on the display language of the viewer's screen.
Set it for each SOP
In the SOP edit screen, open "Basic information" and select the "Original language" within "Playback & display settings". This does not execute translation; it specifies the language that serves as the basis for translation and text-to-speech.
Set the default for SOPs you create from now on
For overseas branches and other situations where an entire team creates SOPs in the local language, you can set the default in the "Language of SOPs you create from now on" setting in the Terminology Glossary (team administrator or higher). This does not affect SOPs already created.
The original language of newly created SOPs is automatically determined in this order: language specified in material's AI analysis → team default → the display language of the person who created it. Existing SOPs are treated as Japanese, so the behavior is the same as before. Only if you have SOPs created in non-Japanese languages should you check the above settings.
3. You can now translate blanks in the Terminology Glossary all at once
The Terminology Glossary is a table where you register the translation of each term in each language. Because there are many languages, filling in the blanks one by one was a time-consuming task.
From "Translate blanks", you can now fill in empty translation cells with machine translation all at once. You can choose the range from "currently displayed language", "all languages", or "Choose a language". If there are many items, you can stop in the middle, and the results so far are retained.
The translation results are entered only in the table being edited and are not automatically saved. Please verify the contents before saving. The Terminology Glossary is a Core plan and higher feature.
4. Other refinements
Question options and the values considered "Normal" in inspections are now translated
Previously, question options were not subject to translation and were displayed in the original language. Question options and the values considered "Normal" in inspections are now translated, and if you have source language display enabled, the source language appears in small text below the translation. The content of recorded responses does not change.
The language list now appears in its own native script
On the screen for selecting the language to translate to, previously only Japanese or English language names were displayed, but now the language is displayed in its own native script (for example, Vietnamese as Tiếng Việt) according to the screen display language. Japanese screens continue to show Japanese language names as before. This makes it easier for local staff to find their own language.
Thank you for continuing to use Dive.