Table of Contents

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:

Open

Open

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:

1. 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”.

2. 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*.

Example: Dangerous goods Yes

1. New container is created as a test object and contains dangerous goods:

    

2. Workflow is triggered:

   Checklist is assigned:

Example: Dangerous goods No

1. New container is created as a test object and does not contain dangerous goods:

2. Workflow is triggered:

3. 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.

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.

13) Calendar entry at checklist due date

Event:

1. When a checklist is created with the “Abgasmessung” checklist template, the action is executed.

2. 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

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