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.

Open

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.

Open

 

 

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: https://testify.atlassian.net/wiki/spaces/TWN/pages/1606615347/Workflows#Possible-errors-or-uncertainties

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.

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

  • Example: Free Online Cron Expression Generator and Describer - FreeFormatter.com

• 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:

• https://testify.atlassian.net/wiki/spaces/TWN/pages/2376990727/Workflow+Examples#6)-Timer%3A-Monthly-assignment-of-an-issue-as-a-task

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

    • Reopen checklist to automatically assign a checklist to predefined persons or groups after completion:

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)

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)

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

• Example:

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.