Workflows
- Testify
Table of Contents
Under "Administration" in the "Workflows" area, the Testify environment can be automated. The principle is similar to an "if-then logic": Certain events can be defined that trigger actions. For this purpose, triggers/filters and parameters can be stored to set restrictions. These workflows can be edited, deactivated and reactivated, but not deleted.
Searching for specific workflows is facilitated by the search button in the upper right corner. After selecting the magnifying glass, a specific workflow title can be entered to be searched for.
It is possible to apply specific filters to the listed workflows. To filter the workflows, click on the Filter button. Several filters can be selected at the same time. The filter will take effect if the field is actually selected (example restriction to test object type "Machine"). The filter does not take effect if the "Machine" test object type was selected in the filter, but no workflow was explicitly restricted to it.
Create workflow
When adding a new workflow, a title must be defined. The title should be meaningful so that it is already clear in the menu which task the workflow fulfills. A description can be added optionally.
The triggering event must be created first, followed by the subsequent action. If needed, multiple triggering events and actions can be added. Each event, each action and the entire workflow must be saved separately.
Examples under Workflow Examples
Logic
To create a successful and functioning workflow, it must actually be possible. Illogical combinations cannot be executed. If a workflow was created, triggered, but not executed, this is a sign that it has failed. In this case it is recommended to check and change the workflow for correctness. Examples of possible errors at: Workflows | Possible errors or uncertainties
Depending on the action and event, there are different types of filters/triggers.
Example: Test object type, status
There are different choices per filter type.
Example: Status Done or Verified
The different filter types add up. The workflow is then triggered if both filters apply.
Example: Test object type Business Units AND Status Done
It is also possible to select multiple choices within a filter. These are in an OR-relationship, which means that one of the two variants must apply in order to trigger the workflow. The workflow is then triggered when one of the two statuses applies.
Example: Status Done OR Verified
If different selection options were selected for several filter types, a combination of both logics takes place.
Example: Test object type Control Cabinets OR Business Units AND status Done OR Verified
Reuse field value from event if possible (overrides selection above): If this fallback is enabled, values from an event are used for the action. This is only possible if there are actually previous values.
Example: Event checklist Done → action create checklist. Toggle (fallback) is activated for the action at the "Assigned to" filter → new checklist is automatically assigned to the same person/group from the event.
Pay attention to the permissions: If notifications are sent due to an event, only those users with the appropriate permissions will receive them.
Events
In the "Events" section, steps must be defined that must be fulfilled in order to trigger the action. Before creating further events or actions, it is important to save the event. When creating events, the following information must be specified:
Mandatory
Scope: the scope defines the entity in which the event takes place. Possibilities: Checklist, issue, test object, PDF, user, timer
Type: the type defines the entity change and depends on the entity. Possibilities: created, changed, generate
Not mandatory
Filter/Trigger: Filters can be used to specify the conditions. Here it can be defined that the event is valid only under certain conditions. Depending on the selected type, the following choices appear:
Type created:
Filter: Filters according to properties of the object.
Example: Test object type Machines → The workflow is triggered if the test object type Machines was selected.
Type changed:
Important: The workflow is only triggered when the status or assignment has changed.Trigger: Defines a field that must be changed to a specific value to trigger the workflow. This condition must be met for the workflow to be triggered.
Example: Status Verified → The workflow is triggered when the status changes to verified.
Filter before change: Filters according to properties of the object before the change. The filter before change is only applied if the property has actually changed. If the property before and after the event is the same or incorrect, the workflow is not executed because the filter does not apply.
Example: Status Done → The workflow is triggered if the status before the change was done and after the change is different (e.g. verified).
Filter after change: Filters by properties of the object after the change (This condition must be true at the time the workflow is executed).
Example: Status Verified → The workflow is triggered when the status changes to verified after change and was previously different (e.g. Done). A filter before change can, but does not have to be defined.
It is possible to combine the filter types with each other. The prerequisite for this is again logic and meaningfulness. Faulty workflows do not work.
The following combinations are possible:
Trigger & Filter before change
e. g. Trigger: Status Done & Filter before change: Status Open
Filter before change & Filter after change
e. g. Filter before change: Status Open & Filter after change: Status Done
Trigger & Filter after change
e. g. Trigger: Status Done & Filter after change: User XY
Trigger & Filter before change & Filter after change
e. g. Trigger: Status Done & Filter before change: Status Open & Filter after change: Status Done
Scope: Checklist
Type: created
Possible filters: Test object (types), State, Assigned to, Created by, Modified by, Checklist templates, Custom fields (test objects)
Type: changed
Important: When using filters, the workflow will only be triggered if the status or assignment has changed.Possible triggers: State, Assigned to, Modified by
Possible filter before change: Test object (types), State, Assigned to, Modified by, Checklist templates
Possible filter after change: Test object (types), State, Assigned to, Created by, Modified by, Checklist templates, Scoring, Custom fields (test objects)
Scope: Issue
Type: created
Possible filters: Test object (types), State, Assigned to, Created by, Modified by, Category, Severity, Custom fields (issues), Custom fields (test objects)
Type: changed
Important: When using filters, the workflow will only be triggered if the status or assignment has changed.Possible triggers: Test object, State, Assigned to, Changed by, Category, Severity
Possible filters before change: Test object (types), State, Assigned to, Modified by, Category, Severity
Possible filters after change: Test object (types), State, Assigned to, Created by, Modified by, Category, Severity, Custom fields (issues), Custom fields (test objects)
Scope: Test object
Type: created
Possible filters: Test object types, Created by, Custom fields (test objects)
Scope: PDF
Type: Issue PDF generated
Possible filters: Test object (types), State, Assigned to, Created by, Modified by, Category, Severity, PDF protocol profiles
Type: Checklists PDF generated
Possible filters: Test object(s), State, Assigned to, Created by, Modified by, Category, Checklist templates, PDF Protocol Profiles
Scope: User
Type: created
Possible filters: Roles, Groups
Scope: Timer
Type: trigger
Parameters: Cron timer
The timer feature allows tasks to be scheduled periodically. This is possible via a cron timer. The timer feature can be set based on minutes, hours, days, weeks or months. The cron trigger always refers to the UTC time zone, times must therefore be converted if necessary (e.g. 12:00 UTC is 14:00 CEST in Austria).
The desired repetition can either be specified directly in the cron format or selected and converted manually in advance. There are two possibilities when converting the desired repetition:
External converter: select desired repetition online and convert it
Selection of the desired repetition including automatic conversion directly in Testify:
Minutes
e.g. every 30 minutes
Hours
e.g. every 2 hours or always at 10:00 AM UTC
Daily
e.g. every 2 days or weekdays incl. desired time (e.g. 10:00 AM UTC)
Weekly
Specification of the desired weekdays e.g. only Mondays, Monday & Friday or Monday-Saturday incl. desired time (e.g. 10:00 AM UTC)
Monthly
Specification of the exact day (e.g. 4th day per month) or
Last day of the month or
Last weekday of every month or
Indication of days before the end of the month (e.g. 2 days before end of month)
incl. desired time (e.g. 10:00 AM UTC)
Example:
Workflow Examples | 6) Timer: Monthly assignment of an issue as a task
Workflow Examples | 7) Timer & Notification: Periodic notifications to user/groups
Actions
In the "Actions" section, the action triggered by the triggering event is defined. Before creating further actions or saving the workflow, it is important to save the action. Since some actions are only enabled after saving an event, it is recommended to create actions only as a second step.
When creating actions, the following information must be specified:
Scope: The scope defines which action should be triggered.
Type: The type defines the change of the entity.
Parameters: Parameters for the triggered action must be defined here (such as test objects, checklist templates, etc.). In this section, the values already defined in "Filter" above can be easily reused by selecting the "Reuse field value if available from event" button.
Defining all parameters is mandatory in this section.
Scope: Checklist
Type: create
Parameters: Test object, Assigned to, Created by, Checklist templates, Due date
Type: change
Parameters: Assigned to, Changed by, Due date, Reopen checklist, Remove checklist
Reopen checklist to automatically assign a checklist to predefined persons or groups after completion: Workflow Examples | 9) Reopen and assign checklist after closing
Remove overdue checklists: Workflow Examples | 15) Remove overdue checklists
Scope: Issue
Type: create
Mandatory parameters: Assigned to, Created by, Category, Severity, Due date
Optional parameters: Test object, title, description
Scope: Webhook
Type: trigger
Mandatory parameters: URL
Optional Parameters: Identifier, HTTP request timeout in seconds (default is 20), HTTP status codes that indicate success. Other codes will lead to several retries before failing
Scope: PDF
Only possible for events with scope checklist or issue.
Type: generate
Parameters: PDF protocol profiles, language
Scope: Notification
Type: send
Parameters:
Default language and input field for the custom message.
After that the language can be changed and a custom message can also be translated
Send to: Who will receive the notification (people or groups).
Notification type (mail or in-app)
Workflow Examples | 7) Timer & Notification: Periodic notifications to persons/groups
Scope: Calendar Entry
Type: sende
Mandatory parameters: Send to (a specific user or user of a group or the user to whom the event is assigned or the user who created the event).
Optional parameters:
Deviation from the due date in days (More or Less, e.g. +1).
Deviation from the due date in hours (More or Less e.g. -1)
Duration of the appointment in minutes (e.g. 30 min)
Workflow Examples | 13) Calendar entry at checklist due date
Notes
It is recommended to add two events at once (type created and changed), so that you not only get a calendar entry when it is created, but also an update of it when the event is updated.
The event will be updated only if the due date or assigned user changes.
If the event is later assigned to a new user, the original user will receive a cancellation of the appointment in the calendar.
Scope: Testobject
Type: change
Parameter:
Link Check to custom fields
Select checklist template
Select Check
Select custom fields from test object
Notes
If a checklist is completed and finalised, the test result is saved in the custom field of the test object.
The type of the custom field and the check must match (e.g. numeric and numeric).
Delay
Delays can be added in order to execute actions only at a later time.
Delay calculated from
+/-days
+/- hours
Filter on the event that will be checked after the delay expires. The action will be executed only if this filter applies to the event after the delay expires.
Edit / deactivate workflow
After the workflow has been created, it can be edited or disabled/enabled by clicking on the context menu (the three dots) in the upper right corner of the workflow.
Workflow-History
Workflows have a history where all previous steps are displayed. This feature allows to check the successful and failed executions of all workflows. For each execution attempt, a separate entry is created with all relevant information. Filters can be set to ensure transparent troubleshooting. It also shows when a workflow was activated/deactivated and whether this was done automatically or manually by a person.
The workflow history can be displayed by clicking on the context menu (the three dots in the right corner). This is possible either in the workflow overview, but also within a workflow:
By selecting the desired entry, the history is displayed:
All important information can be seen at a glance. Through the link icon on the right side next to the text, the individual points can be expanded and further details can be displayed:
When using delays, there are the following options that are displayed depending on the status:
Open/Planned Actions: Date and time of the trigger" and "Date and time of planned execution"
Successful and failed actions: "Date and time of execution"
Disabled workflow ""The workflow got disabled during the delay"
Workflow does not match the event: "The filter after the delay did not match the requirements"
Possible errors or uncertainties
Events
Missing or wrong filter/trigger for event
When using filters, the workflow is only triggered when the status or assignment has been updated.
Faulty event: workflow for modified checklists restricting to one checklist template when filtering before modification.
Scope: Checklist
Type: Updated
Filter before change: A checklist template
→ Since the checklist template will not change, the workflow will never be triggered. Users might think that they trigger every checklist change as an event. However, since the checklist template will not change, the workflow will not be triggered.
Corrected and working event
Scope: Checklist
Type: Updated
Filter before change: Status Done, Verified
Trigger Assigned to person X is only possible if the value has actually been updated.
If the property before and after the event is the same or incorrect, the workflow is not executed because the filter does not apply.
Incorrect or illogical filtering
Event: Checklist created → Filter Status Verified.
A newly created checklist is always in status Open. The filter Status Verified makes no sense here.
TTrigger Status Done and filter after change Status Verified
If the workflow is to be triggered on Status Done OR Verified, this must be mapped using Filter after Change.
Frequent ambiguity: Event → Checklist Updated → Status in process.
As soon as a checklist is started, the checklist is in status in process. Already then the workflow is triggered and not only when exiting.
Examples under Workflow Examples