Set Trigger & Conditions

12 Jun 2024
6 Minutes to read

Set Trigger & Conditions

Updated on 12 Jun 2024
6 Minutes to read

Article summary

Did you find this summary helpful?

Thank you for your feedback

In the Set Trigger & Conditions stepper, you have an option to establish Trigger event and Condition that prompts the execution of the workflow. Configure the trigger events (created or updated) to initiate the specified trigger. Ensure that the defined condition criteria are satisfied to activate the corresponding action.

The trigger event relates to the creating or updating of the tickets.

Figure: Set Trigger & Condition

Set Trigger & Conditions section consists of the following sections:

Trigger

You can set an event to trigger the workflow. The events that you can configure are:

Event	Description
Created	Select the check box to trigger the workflow during creation of tickets. When a user configures a Workflow with the Trigger type as Create, the Workflow triggers immediately once the ticket is created. By default, this check box is selected.
Updated	Select the check box to trigger the workflow during an update of ticket. When a user configures a workflow with the Trigger type as Update, the Workflow will only be triggered when a user updates any fields or if the conditions are matched (In this case the workflow will not trigger on creation of a new Incident even if the condition is matched). Select the Updated check box Refresh buttons are displayed. Refresh Workflow, if it had started - Select the radio-button to restart or refresh a workflow based on its initial starting conditions. This functionality enables you to revisit and re-trigger a workflow if certain specified criteria are met. This ensures workflows stay relevant and accurate, adapting to evolving conditions in the initial triggering data. For Example: If a new incident ticket is created and assigned a priority level. Using the Refresh Workflow, if it had started in option, you can set it to rerun the workflow when the priority level is later updated. This keeps the workflow responsive and adaptable to changes. Do not Refresh Workflow, if it has started - Select the radio-button enables that once a workflow has commenced, it should not be restarted or refreshed based on subsequent changes to the triggering conditions. For Example: If a change request workflow that initiates when a request is submitted. When you enable this option any updates to the initial request details, such as additional comments or attachments, will not trigger a restart of the workflow. This ensures that the workflow progresses without interruption, maintaining the integrity of its original execution path and preventing unnecessary repetitions.

Event

Description

Created

Select the check box to trigger the workflow during creation of tickets. When a user configures a Workflow with the Trigger type as Create, the Workflow triggers immediately once the ticket is created. By default, this check box is selected.

Updated

Select the check box to trigger the workflow during an update of ticket. When a user configures a workflow with the Trigger type as Update, the Workflow will only be triggered when a user updates any fields or if the conditions are matched (In this case the workflow will not trigger on creation of a new Incident even if the condition is matched).

Select the Updated check box Refresh buttons are displayed.

Refresh Workflow, if it had started - Select the radio-button to restart or refresh a workflow based on its initial starting conditions. This functionality enables you to revisit and re-trigger a workflow if certain specified criteria are met. This ensures workflows stay relevant and accurate, adapting to evolving conditions in the initial triggering data.

For Example: If a new incident ticket is created and assigned a priority level. Using the Refresh Workflow, if it had started in option, you can set it to rerun the workflow when the priority level is later updated. This keeps the workflow responsive and adaptable to changes.
Do not Refresh Workflow, if it has started - Select the radio-button enables that once a workflow has commenced, it should not be restarted or refreshed based on subsequent changes to the triggering conditions.

For Example: If a change request workflow that initiates when a request is submitted. When you enable this option any updates to the initial request details, such as additional comments or attachments, will not trigger a restart of the workflow. This ensures that the workflow progresses without interruption, maintaining the integrity of its original execution path and preventing unnecessary repetitions.

Condition

A condition is made up of a field, an operator, and a value. You can formulate complex conditions for rules that include several conditions separated by AND or OR operators.

You can use the condition builder to determine when the workflow actions should be executed. When a request arrives, there are two options the user can select:

Note

The field value attributes are dependent on the Table selected while creating a workflow.
You can configure condition for all the attributes (Main Form, Sub Form, and Pop-over Form) based on the Form selected in the General Stepper.

• Based on Condition: Select this button to specify the conditions based on which the action would be executed.

• Always (no condition): Select this button if there are no conditions.

To add a Condition, perform the following steps:

Under Run, select whether you want to run Based on Condition or Always.
Click +Add Filter Set and add the condition using the Field, Operator and Value section.
To add multiple conditions, click the Icon and to delete a condition click the icon.
To Group two or more conditions, click the Group icon.
Click Next.

A condition consists of the following three parts:

Field: The fields related to the selected module are populated in the drop-down list. It lists all the Main Forms, Sub Forms, and Popover Forms.
Operator: Based on the selected field value, the operators are displayed. Select the required operator from the drop-down list. The Possible values for Operator are: Contains, Does not contain, Equals, Not Equals, Is one of, Is not one of, Greater Than, Less Than, Less than or equal to, Greater than or equal to, and Between.

Value: Based on the selected Field type and Operator the options are populated in the Values field.

Condition:

Status = Resolved AND Priority = P4 AND Impact = Low

OR {{Workgroup = Computing} AND {Impact = High}}

If this condition is to be written from left to right in normal code, it would appear as shown below.

{Status = Resolved} AND {Priority = P4} AND {Impact = Low} OR ({Workgroup = Computing} AND Impact = High})

Workflow follows the BODMAS rule and processes the conditions in the Brackets first and then left to right as shown below:

Action: The action will be to close the Incident if the above criteria is met.

Fields

Based on the selected module, the fields related to the module are populated in the drop-down list from which you can select the required option. The supported Fields and Field types are as listed below:

List of fields Supported:

Standard Attributes

Field Name	Field Key	Field Type	Field Data Type	Notification API Key
Incident ID	INCIDENT_NO	number	integer	INCIDENT_NO
Major Incident	MAJOR_INCIDENT	checkbox	integer	MAJOR_INCIDENT
Source	SOURCE	dropdown	string	SOURCE
Scheduled Incidents	SCHEDULED_INCIDENTS	checkbox	string	SCHEDULED_INCIDENTS
Has Attachment	HAS_ATTACHMENT	checkbox	bool	HAS_ATTACHMENT
Response SLA Violation	RESPONSE_SLA_VIOLATION	checkbox	bool	RESPONSE_SLA_VIOLATION
Resolution SLA Violation	RESOLUTION_SLA_VIOLATION	checkbox	bool	RESOLUTION_SLA_VIOLATION
Response SLA	RESPONSE_SLA	singleselection	string	RESPONSE_SLA
Resolution SLA	RESOLUTION_SLA	singleselection	string	RESOLUTION_SLA
CSAT Rating	CSAT_RATING	number	float	CSAT_RATING
Manual Escalation	MANUAL_ESCALATION	checkbox	bool	MANUAL_ESCALATION
Manual Escalation Level	MANUAL_ESCALATION_LEVEL	dropdown	string	MANUAL_ESCALATION_LEVEL
Auto Escalation	AUTO_ESCALATION	checkbox	bool	AUTO_ESCALATION
Auto Escalation Level	AUTO_ESCALATION_LEVEL	dropdown	string	AUTO_ESCALATION_LEVEL
Previous Workgroup / Assigned Workgroup	PREVIOUS_WORKGROUP	dropdown	integer	PREVIOUS_WORKGROUP
Previous Analyst / Assigned To	PREVIOUS_ASSIGNED_TO	dropdown	integer	PREVIOUS_ASSIGNED_TO
Previous Status	PREVIOUS_STATUS	dropdown	string	PREVIOUS_STATUS
Previous Category	PREVIOUS_CATEGORY	treeview	integer	PREVIOUS_CATEGORY
Previous Classification	PREVIOUS_CLASSIFICATION	treeview	integer	PREVIOUS_CLASSIFICATION
Previous Impact	PREVIOUS_IMPACT	dropdown	integer	PREVIOUS_IMPACT
Previous Urgency	PREVIOUS_URGENCY	dropdown	integer	PREVIOUS_URGENCY
Previous Priority	PREVIOUS_PRIORITY	dropdown	integer	PREVIOUS_PRIORITY
Previous SLA Service Window	PREVIOUS_SLA_SERVICE_WINDOW	dropdown	integer	PREVIOUS_SLA_SERVICE_WINDOW
Previous Pending Reason	PREVIOUS_PENDING_REASON	dropdown	integer	PREVIOUS_PENDING_REASON
Previous Closure Code	PREVIOUS_CLOSURE_CODE	dropdown	integer	PREVIOUS_CLOSURE_CODE
Previous Resolution Code	PREVIOUS_RESOLUTION_CODE	dropdown	integer	PREVIOUS_RESOLUTIONCODE
Previous Closure Category	PREVIOUS_CLOSURE_CATEGORY	treeview	integer	PREVIOUS_CLOSURE_CATEGORY
Previous Major Incident	PREVIOUS_MAJOR_INCIDENT	checkbox	integer	PREVIOUS_MAJOR_INCIDENT
Previous Source	PREVIOUS_SOURCE	dropdown	string	PREVIOUS_SOURCE
Previous Scheduled Incidents	PREVIOUS_SCHEDULED_INCIDENTS	checkbox	string	PREVIOUS_SCHEDULED_INCIDENTS
Previous Medium	PREVIOUS_MEDIUM	dropdown	string	PREVIOUS_MEDIUM
Previous Description	PREVIOUS_DESCRIPTION	textarea	string	PREVIOUS_DESCRIPTION
Previous Solution	PREVIOUS_SOLUTION	textarea	string	PREVIOUS_SOLUTION
Previous Symptom	PREVIOUS_SYMPTOM	text	string	PREVIOUS_SYMPTOM
Previous Secondary Analyst	PREVIOUS_SECONDARY_ANALYST	dropdown	integer	PREVIOUS_SECONDARY_ANALYST
Previous Sub Workgroup	PREVIOUS_SUB_WORKGROUP	dropdown	integer	PREVIOUS_SUB_WORKGROUP

Date Attributes

Field Name	Field Key	Field Type	Field Data Type	Notification API Key
Log Time	LOG_TIME	date	date	LOGTIME
Updated Time	UPDATED_TIME	date	date	LAST_UPDATED
Closed Date	CLOSED_DATE	date	date	CLOSED_DATE
Updated Since (in Days)	UPDATED_SINCE	number	integer	UPDATED_SINCE
Pending For (in Days)	PENDING_FOR	number	integer	PENDING_FOR
Resolution Deadline Time	RESOLUTION_DEADLINE	date	date	RESOLUTION_DEADLINE
Resolution Time	RESOLUTION_TIME	date	date	RESOLUTION_TIME
Response Deadline Time	RESPONSE_DEADLINE	date	date	RESPONSE_DEADLINE
Response Time	RESPONSE_TIME	date	date	RESPONSE_TIME
Scheduled Date Time	SCHEDULED_DATE_TIME	date	date	SCHEDULEDATE
Target Completion Date	TARGET_COMPLETION_DATE	date	date	TARGET_COMPLETION_DATE
Current Time	CURRENT_TIME	date	date	CURRENT_TIME
Previous Log Time	PREVIOUS_LOG_TIME	date	date	PREVIOUS_LOGTIME
Previous Updated Time	PREVIOUS_UPDATED_TIME	date	date	PREVIOUS_LAST_UPDATED
Previous Resolution Deadline Time	PREVIOUS_RESOLUTION_DEADLINE	date	date	PREVIOUS_RESOLUTION_DEADLINE
Previous Resolution Time	PREVIOUS_RESOLUTION_TIME	date	date	PREVIOUS_RESOLUTION_TIME
Previous Response Deadline Time	PREVIOUS_RESPONSE_DEADLINE	date	date	PREVIOUS_RESPONSE_DEADLINE
Previous Response Time	PREVIOUS_RESPONSE_TIME	date	date	PREVIOUS_RESPONSE_TIME
Previous Scheduled Date Time	PREVIOUS_SCHEDULED_DATE_TIME	date	date	PREVIOUS_SCHEDULEDATE
Previous Target Completion Date	PREVIOUS_TARGET_COMPLETION_DATE	date	date	PREVIOUS_TARGET_COMPLETION_DATE

User Attributes

Field Name	Field Key	Field Type	Field Data Type	Notification API Key
Username/Caller	CALLER	user_search	integer	CALLER
Logged By	LOGGED_BY	user_search	integer	LOGGED_BY
User Type	USER_TYPE	dropdown	integer	USER_TYPE
Customer	CUSTOMER	user_search	integer	CUSTOMER
Location	LOCATION	user_search	integer	LOCATION
Caller Location	CALLER_LOCATION	user_search	integer	CALLER_LOCATION
Join Date	JOIN_DATE	date	integer	JOIN_DATE
Time Zone	TIME_ZONE	dropdown	integer	TIME_ZONE
User Designation	USER_DESIGNATION	dropdown	integer	USER_DESIGNATION
Approval Required	USER_LEVEL	dropdown	integer	USER_LEVEL
Previous Username/Caller	PREVIOUS_CALLER	user_search	integer	PREVIOUS_CALLER
Previous User Type	PREVIOUS_USER_TYPE	dropdown	integer	PREVIOUS_USER_TYPE
Previous Customer	PREVIOUS_CUSTOMER	user_search	integer	PREVIOUS_CUSTOMER
Previous Location	PREVIOUS_LOCATION	user_search	integer	PREVIOUS_LOCATION
Previous Caller Location	PREVIOUS_CALLER_LOCATION	user_search	integer	PREVIOUS_CALLER_LOCATION

Usage of Dynamic Tables

Dynamic tables refer to tables in a user interface or in the backend of an application that can change their structure, content, or appearance dynamically based on certain conditions, user interactions, or data changes. These tables are highly flexible and adaptable, allowing developers to create interfaces that can accommodate various data formats and user requirements.

Consider an example where we want to use Dynamic table to add a condition where the Workgroup should be selected dynamically through an admin Table.

The Dynamic operator function can be used to map the admin table as shown below. Upon selection, all the admin tables get populated.

Operator

Based on the selected field value, the operators are displayed. Select the required operator from the drop-down list.

List of Operators Supported

Operator Id	Operator Value
1	=
2	!=
3	>=
4	<=
5	>
6	<
7	IN
8	NOT IN
9	Between
10	Contains
11	Today
12	Yesterday
13	Tomorrow
14	This Week
15	Last Week
16	Next Week
17	This Month
18	Last Month
19	Next Month
20	Last 3 Months
21	Last 6 Months
22	Last 9 Months
23	Last 12 Months
24	Last Quarter
25	Last Two Quarter
26	This Quarter
27	Next Quarter
28	Last year

Value

Based on the selected Field type and Operator the options are populated in the Value field.

The value field can be one of the following four types:

Date: Represents a calendar date. This can be used for inputting or displaying dates in various formats (e.g., MM/DD/YYYY or YYYY-MM-DD). In programming, date-related operations and formatting are commonly used for managing time-sensitive data.
Dropdown: A dropdown, also known as a drop-down menu or list, is a user interface element that allows users to select one option from a list of available options. This is often used when you have a predefined set of choices, and the user can choose one from the list.
Numeric: Refers to numerical data, including integers and floating-point numbers. Numeric input is used when you need users to enter numerical values, such as quantities, amounts, or any other numeric data. Validation is typically applied to ensure that only valid numeric input is accepted.
String: Represents a sequence of characters. String input is used for text-based data, such as names, addresses, or any other textual information. It's a versatile data type that can accommodate a wide range of alphanumeric characters.

Note

When workflows have both "created" and "updated" check boxes are selected, and "Select Refresh workflow if it has started" is enabled. Any new condition in record updates should trigger the workflow immediately, irrespective of prior approvals.

Was this article helpful?

What's Next

Overview

Table of contents

Trigger
Condition