Workflow Examples
- Testify
- Tina Schuett
Table of Contents
- 1 Actions
- 2 Complete workflows
- 2.1 1) Initiation of a checklist when adding a test object
- 2.2 2) Initiation of a checklist when an issue was created
- 2.3 3) Initiation of a sequence of connected checklists
- 2.4 4) PDF generation after checklist execution
- 2.5 5) Webhook: Save PDF protocol to external system
- 2.6 6) Timer: Monthly assignment of an issue as a task
- 2.7 7) Timer & Notification: Periodic notifications to user/groups
- 2.8 8) Delay: Notification 1 day before a checklist expires
- 2.9 9) Reopen and assign checklist after closing
- 2.10 10) Assign checklist for verification after completion
- 2.11 11) Dynamic checklists: Assignment of checklists depending on custom fields
- 2.12 12) Dynamic checklists: actions depending on the check result by using scoring
- 2.13 13) Calendar entry at checklist due date
- 2.14 14) Check result in custom fields of a test object
- 2.15 15) Remove overdue checklists
- 3 Connected workflows
Actions
Example: Action Webhook
Based on events within Testify, webhooks can also be added independently as actions in workflow management. This is possible by selecting the scope "Webhook" with the type "trigger". An URL has to be specified as parameter, optionally an identifier, a HTTP request timeout and HTTP status codes that indicate success can be entered:
Example: Action Generate PDF
The generation of PDF protocols can now be automated as an action via a workflow. This process automation is to start the generation of PDFs for the filtered checklists. Filters can be set based on the events to define exactly for which test objects or checklists the automated PDF generation should take place.
As a prerequisite for this automatism, it is necessary to define a corresponding event in advance:
Scope: checklist
Type: changed
Remaining filters as desired
After that the action can be defined:
Scope: PDF
Type: generate
Parameters: Selection of the desired PDF protocol profile and language.
Example: Action Send notification
Notifications can be triggered by checklists, issues, test objects, users or timers. The language, message, recipient (user or group) and notification type (mail, in-app) can be defined. In addition to this, the custom messages can be translated.
Event "Test object created" triggers the action "Notification":
Complete workflows
1) Initiation of a checklist when adding a test object
Event:
When a new test object is added from "Testify Admin" to "Frankfurt Airport", the action is executed.
Action:
A checklist is created by "Testify Admin" for the added test object, which is assigned to the user "Testify Admin" and due in 7 days at 12:30.
2) Initiation of a checklist when an issue was created
Event:
When a new issue with the category "Logistical Error" is added to "Frankfurt Airport", the action is executed.
Action:
A "Logistic Issue - Checklist" checklist is created by "Testify Admin" for the test object where the issue occurred, assigned to the "Engineering" area and due in 3 days at 12:01
3) Initiation of a sequence of connected checklists
Event:
When a “General Checks” checklist get created on a “Airport Frankfurt“ test object then the action will be carried out.
Action:
A “Electrician - Checklist“ checklist gets created for the same test object by “Testify Admin”, assigned to “Electricians”, “Due date (+days since event): 7; Time of day: 12:00pm”.
A “Mechanics - Checklist“ checklist gets created for the same test object by “Testify Admin”, assigned to “Mechanics”, “Due date (+days since event): 7; Time of day: 12:00pm”.
4) PDF generation after checklist execution
Event:
When a checklist is created for a test object "Frankfurt Airport", the action is executed.
Action:
The Extended Standard Protocol is generated the checklist is updated.
5) Webhook: Save PDF protocol to external system
PDF protocols can also be automatically stored in external systems. For this purpose, an interface can be built by the customer, based on our webhook, which stores the generated protocols at the desired folder.
Event:
When an extended standard protocol is created for a checklist with the test object "Airport Frankfurt", the action is executed.
Action:
The created PDF protocol is stored in an external system through the interface with the Webhook action.
6) Timer: Monthly assignment of an issue as a task
* in this example, issues are used to map tasks.
Event:
By the timer, on the last day of the week of each month, the action is executed.
Action:
An issue with category Projektleitung#13, Severity A, Due date 2 days from event at 08:00, with predefined title and description is created by Testify Admin and assigned to Backoffice.
7) Timer & Notification: Periodic notifications to user/groups
Event:
Through the timer, the action is executed weekly on Fridays.
Action:
A notification with custom message will be sent to the electrician by email and in-app.
8) Delay: Notification 1 day before a checklist expires
Event:
When a checklist is created by Testify Admin, the action is executed.
Delay:
The action is triggered 1 hour before the due date of the checklist, if it is still in Open or In Progress status.
Action:
A notification with custom message is sent in-app to the user to whom the checklist is assigned (fallback).
9) Reopen and assign checklist after closing
Event:
When a checklist is completed using the Product Audit checklist template, the action is executed.
Action:
The checklist is reopened, assigned to the carpenter, and is due 1 day later at 12 noon.
10) Assign checklist for verification after completion
a) without individual notification
Event:
When a checklist is completed using the Product Audit checklist template, the action is executed.
Action:
The checklist is assigned by Test Admin to Testify Admin in the Done status and is due 1 day later at 12 noon.
b) With individual notification
Event:
When a checklist is completed using the Product Audit checklist template, the action is executed.
Actions:
The checklist is assigned by Test Admin to Testify Admin in the Done status and is due 1 day later at 12 noon.
A custom message (e.g. "Please check and verify") is sent via email and in-app.
11) Dynamic checklists: Assignment of checklists depending on custom fields
Different checklists are assigned depending on the custom field of a test object.
Use case: Depending on whether the container (= the new test object) contains a dangerous good or not, different checklists are assigned automatically. This example works both when a new test object is created manually and when it is transmitted via an interface*.
Custom field > Dangerous goods
*If the information comes via an API, the "Data field" toggle must be activated. More information under Custom fields.
Test object type > Container
Example: Dangerous goods Yes
New container is created as a test object and contains dangerous goods:
Workflow is triggered:
Checklist is assigned:
Example: Dangerous goods No
New container is created as a test object and does not contain dangerous goods:
Workflow is triggered:
Checklist is assigned:
12) Dynamic checklists: actions depending on the check result by using scoring
Use case: Different actions are triggered depending on the check result.
Example: Answer Yes → Assignment to “Konstrukteure”; Answer No → No action.
Implementation: By storing scores, check results are given a weighting. Actions are triggered based on the number of points achieved in the scoring. Several dependent checks can be mapped per checklist using different workflows. This dynamization works for all types of checks using scoring. It is important that the checklist is completed as a trigger for the workflow.
Example: Answer Yes = 2 points and No = 1 point in scoring.
Scoring must be submitted to the appropriate checks* in preparation. The following scoring is recommended:
Answer Yes: 2 points & No: 1 point
Answer Yes: 12 points & No: 11 points
Answer Yes: 22 points & No: 21 points
Event:
When a checklist is done using the Annual Maintenance checklist template and has scored above 1 but below 3, the action is executed. So the answer must be "Yes" for the workflow to be triggered.
Action:
The checklist is opened again and assigned to the constructors.
Event:
When a checklist is done using the Annual Maintenance checklist template and has scored above 10 but below 13, the action is executed. So the answer must be "Yes" for the workflow to be triggered.
Action:
The checklist is opened again and assigned to the assemblers.
Event:
When a checklist is done using the Annual Maintenance checklist template and has scored above 20 but below 23, the action is executed. So the answer must be "Yes" for the workflow to be triggered.
Action:
The checklist is opened again and assigned to the group AV.
13) Calendar entry at checklist due date
Event:
When a checklist is created with the “Abgasmessung” checklist template, the action is executed.
When a checklist is modified using the “Abgasmessung” checklist template, the action is executed (e.g. updating the status from In Progress to Completed).
Action:
A calendar invitation is sent to the user by e-mail, but only if a valid e-mail address is stored. When the second event is added, the calendar entry is also updated when the status of the checklist or the due date changes.
14) Check result in custom fields of a test object
Event:
When a checklist is completed with the flue gas measurement checklist template, the action is executed.
Action:
The defined custom fields are filled with the value of the selected check.
15) Remove overdue checklists
Event:
If a checklist with the Annual maintenance checklist template is overdue, the action is executed.
Action:
The checklist will be removed.
Connected workflows
Workflows can also trigger a sequence of other workflows. This allows processes to be mapped and automated even further. The feasibility of the workflow sequence must be taken into account. Workflows can only trigger further workflows if these are also meaningful and no loop is created as a result. For this reason, manual intervention may be required between two workflows so that the further workflows are pushed through, otherwise the sequence is not possible. Here is an overview of possible related workflows:
Checklist or issue
Workflow 1
Action: Checklist or issue created or updated
Workflow 2
Event: Checklist or issue
Valid actions: PDF, notification, webhook
Invalid Actions: Checklists, Issues
Test object
Workflow 1
Action: test object created or updated
Workflow 2
Event: Test object
Valid actions: Notification, Webhook
Invalid actions: Checklists, Issues
A test object triggers a sequence of checklists
A test object triggers a checklist, which triggers another checklist. This can be repeated as often as required.
Workflow 1
Event: New test object created
Action: New checklist created (status: Open).
→ Checklist is created and completed manually.
Workflow 2
Event: Checklist modified (Status: Done)
Action: New checklist created (Status: Open)
→ It would not be possible if the checklist just created (status: Open) directly triggers a new checklist (status: Open), otherwise a loop may occur. The checklist must be edited manually beforehand (for example, Execute and complete Checklist → Status Done). After that, the further workflow is possible.
One test object triggers several checklists
If several checklists are to be instantiated at the same time due to an event (e.g. new test object), these can simply be created as actions in the same workflow. Example: Workflow Examples | 3) Initiation of a sequence of related checklists