Triggers Use Cases

Triggers Use Cases

Triggers 

Pointers 

  1. Triggers can be configured for All Customers or a specific customer. Once configured, the Customer cannot be changed.
  2. Triggers are module-specific and not site-specific. However, you can configure for specific sites of customers under Conditions.

Requests  

Use case 1: ITSM Three strike rule via Timers 

Info
Timers are not customer-specific.  However, notification templates must be created for each customer individually.
Scenario 1:
Technicians often forget to follow up on hold requests, causing them to stay longer in the request queue. To address this, Zylker wants to send periodic reminders to end users for three days until they reply. If there is no reply within this period, the request must be closed automatically with a final notification to the end user.
Action:
  1. Create custom request status and notification templates for reminder and final notice.
  2. Under Zylker, create a timer for on-hold requests.
  3. Set Wait Duration for 3 days.
  4. Specify the reminder email to be sent when the timer is running.
  5. Set conditions to abort the timer if the requester responds to the reminder email.
  6. Select actions to be executed (field update and send final notification) when the timer ends and the requester has not responded to the reminder emails.
  7. Invoke the timer via a trigger configuration.
Preconditions:
Create a custom request status - Waiting for End User:
  1. Go to Setup > Customization > Helpdesk > Status.
  2. Create a new status with the following details:
    1. Name - Waiting for End User
    2. In Progress - In Progress
    3. Stop Timer - Toggle ON
  3. Click Save.
Create Reminder Notification Template:
  1. Go to Setup > Automation > Custom Actions > Notifications.
  2. Create a reminder notification template for on-hold requests.
    1. Name – On-hold reminder notification
    2. Mode – Email
    3. Applies to Requests
    4. Notify – Select the required Recipients from Organization Roles, Request Users, Technicians, and Requesters.  
    5. Subject – Provide the subject line for the reminder.
    6. Message – Draft the message template and save.

Create Final Notification Template: Follow the steps above.

You can also create the notification template while configuring Timer action. 
  1. From the Custom Actions drop-down under the required section within the timer configuration page, select Send Notification.
  2. In the Select Notification pop-up, click + New Notification on the right pane.
  3. Follow the notification creation steps and enter relevant values for the required notification.
  4. Click Save to save only, or click Save and Select to use the notification template immediately.
Configuration:
The following steps will assist you in configuring a timer to send reminders and close the request automatically as per the three-strike rule:
Step 1: Create a Timer
Info
Pointer: Timers are not customer-specific.  
Go to Setup > Automation > Custom Actions > Timers, select Requests from the module filter, and create a new timer as follows:
 
Sections
Fields and Values
Name
Request On-Hold Timer
Schedule Timer
Timer Duration – User Defined
Wait for – 3 days
Enable Consider Operational Hours
Actions – When Timer is running
Configure Actions
Level 1 Execution Rule
Number of Days initiate after 1 day of timer start
Repeat – Enable the checkbox.
Every 1 day
End after 2 Execution
Add Level 1 Actions – Send Notification – select the On-hold reminder notification template.
Abort Timer
Abort this timer on Request – Based on Conditions
Condition - Status is not Waiting for End User
Actions – When Timer Ends
 
Select Custom Actions
Field Update – Status > Closed
Send Notification – Select the Final Notification template.
Options
Enable Automatically clear timer on Request Closure
 

Info
When the requester replies, the request reopens automatically based on the configuration set under Setup > General Settings > Advanced Portal Settings and aborts the timer.

Step 2: Invoke Timer via Trigger
Go to Setup > Automation > Trigger.
Create a new trigger with the following fields:
 
Section
Fields and Values
Name
Follow up and close
Customer
Zylker
Applies to
Requests
Execute when a request is
Created and Edited
Execute During
Within Operational Hours
Enable Trigger
Select the checkbox
Apply this trigger on request
Based on Conditions
Condition – Status is Waiting for End User
Execute trigger when a request is edited
When any field in the condition is edited
The trigger will execute when the field specified in the condition (Status) is updated with the exact value (Waiting for End User).
Actions
Timer – select Request On-hold timer
 
Scenario 2 
To ensure that hardware return requests are accurately managed, Zylker wants to send periodic reminders starting after 70% of the To Be Returned date is reached. If the end user does not respond by then, the issue must be escalated and handled as per company policy automatically.

Action
  1. Create necessary notification templates under Setup > Automation > Custom Actions > Notifications > Requests. Follow these steps. 
  2. Create a timer with three days wait duration and escalation emails to be sent to respective authorities. You can define up to three escalation levels.
  3. Within the timer configuration, define criteria to abort the timer and actions to be taken when the timer ends.
  4. Create a trigger and invoke the timer.
 
Configuration 
Step 1: Create a Timer
Go to Custom Actions > Timer and create a new timer as follows:
Sections
Fields and Values
Name
Hardware Return Follow-up Timer
Schedule Timer
Timer Duration – Based on Date/Time field
<Pick the Date/Time field from the asset request template>
Wait for – Percentage at 70% of To Be Returned On relative to Timer Start
Actions – When Timer is running
Configure Actions
Configure Level 1 Actions - Percentage > initiate at - 80% of timer duration
Add Level 1 Actions - Send Notification to Reporting Manager [select relevant notification]
Configure Level 2 Actions - Percentage > initiate at - 90% of timer duration
Add Level 2 Actions - Send Notification to Department Head [select relevant notification]
Configure Level 3 Actions - Percentage > initiate at - 100% of timer duration
Add Level 3 Actions - Send Notification to Regional Manager and General Manager [select relevant notification]
Abort Timer
Abort this timer on Request – Based on Conditions
Condition - Status is changed FROM Awaiting Hardware Return TO Any
Actions - Send Notification to inform about the returned asset [select relevant notification].
Actions – When Timer Ends
 
Select Custom Actions
Add a Task - Add task to the IT department Head to mark the inventory state as Lost and Not returned.
Send Notification – Send a final notification to inform requesters about unreturned asset.
Options
Enable Automatically clear timer on Request Closure
 
Step 2: Invoke the timer via Trigger
  1. Go to Setup > Automation > Trigger.
  2. Create a new trigger with the following fields:
Section
Fields and Values
Name
Hardware Return Follow-up 
Customer
Zylker
Applies to
Requests
Execute when a request is
Created and Edited
Execute During
Any time
Enable Trigger
Select the checkbox
Apply this trigger on request
Based on Conditions
Condition – Status is Awaiting Hardware Return
Execute trigger when a request is edited
When any field in the condition is edited
The trigger will execute when the field specified in the condition (Status) is updated with the exact value (Awaiting Hardware Return).
Actions
Timer – select Hardware Return Follow-up Timer

Use case 2: Send customized notifications 

Scenario:
In addition to the default notifications, an administrator at Zylker wants to trigger customized notifications when a high-priority request is raised by a VIP user.

Action:
  1. Configure a Request trigger for Zylker.
  2. Define the user and priority criteria for the trigger: User – VIP User and Priority - High.
  3. To send an email/SMS notification for such events, select Notification as the trigger action and create or select the relevant notification template.
Configuration:
Section
Fields and Values
Execute when a request is
Created
Execute during
Anytime
Enable Trigger
Enable the checkbox
Apply this trigger on request
Based on condition
Condition 1: Requester > VIP User is Yes
Apply AND logical operator
Condition 2: Priority is High
Action
Select Custom Action > Notification
Create or select the relevant notification template for the scenario.
 Notification templates created for Zylker under Setup > Automation > Custom Actions will be available for selection. 
 To spot create a notification template, click + New Notification on the left.  
 
 

Use case 3: Condition-based approvals 

Pointers 
  1. Condition-based approvals can be configured only for service requests. 
  2. To define a common, module-specific approval workflow for All Customers, go to Setup > General Settings > Approval Settings. Learn more.
  3. To set approval reminders, go to Setup > General Settings > Advanced Portal Settings > Approval Reminder Settings. Learn more.
Scenario:
Zylker wants to automatically send approvals when onboarding users for the Finance department.

Action:
  1. Under Zylker, configure an approval workflow and email template for user onboarding.
  2. Create a trigger for auto-approval of user onboarding requests.
  3. Define department and organizational role criteria for trigger.
  4. Execute the approval workflow for the set criteria.  
Configuration:
Step 1: Create an approval action
  1. Go to Setup > Automation > Custom Actions > Approvals. Select Service Requests from the module filter.
  2. Service request approval templates cannot be created for specific customers.
  3. Create a new approval with the following fields:
Fields
Values
Approval Name 
Approval for User Onboarding
Approval Rule
Everyone to Approve
Approvers
Organizational Roles > Select the roles who should approve the user onboarding.
Email Notification Template
Use Global/Custom Template
Approval Settings
Use Global/Custom Settings
 
Step 2: Create trigger
  1. Go to Setup > Automation > Trigger. Select Zylker from the customer filter and Requests from the module filter.
  2. Create a new trigger with the following fields:
 
Section
Fields and Values
Name
Department-Based Trigger for User Onboarding Approval
Execute when a request is
Created and Edited
Execute During
Any time
Enable Trigger
Enable the checkbox.
Condition
Based on conditions
Condition 1 – Department is Finance.
You can choose site-specific departments.
Execute trigger when a request is edited
When any field in the condition is edited
The trigger will execute when the field specified in the condition (Department) is updated with the exact value (Finance).
Actions
Approval > Select Approval for User Onboarding.
 
 

 Changes 

Use case 1: Trigger based on  Change Priority

Scenario:
For high-priority change requests, Zylker wants to send notification to the relevant Change Roles periodically to ensure swift release.

Action:
  1. Create notification templates. For the scenario, you can send three levels of notifications until the change is scheduled:
    1. Level 1 – Notify the implementation due to All Change Roles
    2. Level 2 – Notify Change Owner to prioritize the schedule
    3. Level 3 – Escalate to Change Manager
  2. Define a timer schedule for each level.
  3. Create and define trigger criteria and invoke the timer via the trigger.
Configuration:
Step 1: Create Notification Templates
  1. Create the notification template to be sent to the relevant Change Roles under Setup > Automation > Custom Actions > Notifications > Changes. Follow the notification creation steps. 
  2. You can also create notification templates while configuring timer actions. Follow the timer creation steps.
Step 2: Create a Timer
To send notifications periodically, configure a timer under Setup > Automation > Custom Actions > Timers > Changes.
 
Sections
Fields and Values
Name
High-priority Change Request Follow up timer
Schedule Timer
Timer Duration – Based on Conditions
 Timer will run until it matches the Abort Timer conditions.  
 
Actions – When Timer is running
Configure Actions
Level 1 Execution Rule
Number of Days initiate after 3 days of timer start
Repeat – Enable the checkbox.
Every 1 day
End after 3 Execution
Add Level 1 Actions – Send Notification – select the Implementation Due notification template.
 
Level 2 Execution Rule
Number of days initiate after 1 days of Completion of Level 1
Repeat – Enable the checkbox.
Every 1 day
End after 3 Execution
Add Level 2 Actions – Send Notification – select Notify Change Owner notification template.
 
Level 3 Execution Rule
Number of days initiate after 1 days of Completion of Level 2
Add Level 3 Actions – Send Notification – select Escalate to Change Manager template.
 
Abort Timer
Abort this timer on Change – Based on Conditions
Condition 1 – Priority is High
Apply AND logical operator
Condition 2 - Scheduled Start is not empty
Actions – When Timer Aborts
 
Select Custom Actions
Send Notification – Notify Change Roles to prioritize the release.
Options
Enable Automatically clear timer on Change Closure
 
Step 3: Create Trigger
  1. Go to Setup > Automation > Trigger.
  2. Select Changes from the module filter.
  3. Create a new trigger with the following fields:
Sections
Fields and Values
Name
High-Priority Change Schedule Trigger
Customer
Zylker
Trigger applies to
Approval Levels
Execute when a change is
Created and Edited
Execute During
Any time
Enable Trigger
Enable the checkbox
Condition
Apply this trigger on Change - Based on conditions
Condition 1 – Priority is High
Apply AND logical operator
Condition 2 – Scheduled Start is empty
Execute trigger when a request is edited  
 
When any field in the condition is edited
The trigger will execute when the fields specified under Condition are updated with the exact values.
Actions
Timer > select the High-priority Change Request Follow up timer
 

Use case 2: Trigger based on Approval Level 

Scenario:
Zylker follows the following approval process for changes impacting their base site.
  1. Approval Level 1: Initial Review by Change Manager and Department Head
    1. Task 1 → Review and approve the change request based on initial risk assessment and impact level.
  2. Approval Level 2: CAB Approval
    1. Task 2 → Review and analyze risk, dependencies, rollout plans, and downtime conflicts with major changes.
Zylker wants to initiate Task 2 automatically based on the Approval Level and its status.

Prerequisite:
Change request with approval levels defined under CAB Evaluation stage, impact and schedule details.

Action:
  1. Create the Task 2 under Setup > Custom Actions > Tasks > Changes.
  2. Create a trigger with approval level criteria to invoke the Task 2.
Configuration:
Step 1: Create Task
Info
 Tasks are module-specific and not customer-specific.  
  1. Go to Setup > Automation > Custom Actions > Tasks.
  2. Select Changes from the module filter.
  3. Create a new task:
    1. Task Name: Review and Analyze Risk and Conflicts
    2. Change Stage: CAB Evaluation
  4. Click Save.
You can also create tasks while configuring trigger action.
  1. From the Custom Actions drop-down, select Add Task.
  2. Click + New Task on the right pane of the pop.
  3. Specify the task details.
  4. Click Save to save only, or Save and Select to use the task with the trigger immediately.
Step 2: Create Trigger
  1. Go to Setup > Automation > Trigger.
  2. Select Change from the module filter.
  3. Create a new trigger with the following fields:
Sections
Fields and Values
Name
Trigger for CAB Approval Tasks
Customer
Zylker
Trigger applies to
Approval Levels
Execute when a change is
Created and Edited
Execute During
Any time
Enable Trigger
Enable the checkbox
Condition
Based on conditions
Condition 1 - Changes/Site is Base Site
Apply AND logical operator
Add the following as nested conditions:
Condition 2 - Approval Level Name is CAB Approval
Apply AND logical operator
Condition 3 - Status is Approved
Execute trigger when a request is edited  
 
When any field in the condition is edited
The trigger will execute when the fields specified under Condition are updated with the exact values.
Actions
Task > select the Task 2: Review and Analyze Risk and Conflicts

Use case 3: Close requests initiated by a change during the closure of the change 

Scenario:
A network engineer raises a change request to upgrade the firewall firmware. As part of the change, several service requests are initiated, such as scheduling a maintenance window, notifying the security team, and rerouting network traffic.
Once the upgrade is complete, the change manager closes the change. Without this capability, the associated service requests would remain open, requiring someone to manually close each one.
With this capability, closing the change automatically closes all associated requests — no manual follow-up needed.

Configuration:
  1. Set the trigger to be executed on all changes during edit.
  2. Set the trigger to execute when a change is status is Completed >> Close.
  3. Choose to execute the trigger when any field in the change condition is edited.
  4. Execute the following custom function:
Notes
To ensure accurate execution, check the syntax of the following code once from your end before using it. 

id = changeObj.get("id");
params = Map();
// fetching requests initiated by this change
response = zoho.sdp.invokeurl
[
url :"/api/v3/changes/" + id + "/initiated_requests"
type :GET
parameters:params
];
requests = response.get("initiated_requests");
close_success_requests = "Closed Requests ID : ";
close_failed_requests= "Unclosed Requests ID : ";
for each  request in requests
{
associated_request_id = request.get("request").get("id");
        // trying to close the request
close_response = zoho.sdp.invokeurl
[
url :"/api/v3/requests/" + associated_request_id + "/close"
type :PUT
];
        // request close is unsuccessful
if(close_response.get("response_status").get("status_code") != 2000 && close_response.get("response_status").get("messages").get(0).get("status_code") != 4007)
{
close_failed_requests= close_failed_requests+ request.get("request").get("id") + ", ";
note = zoho.sdp.invokeurl
[
url :"/api/v3/requests/" + associated_request_id + "/notes"
type :POST
parameters:{"input_data":{"request_note":{"description":"Associated change with ID " + id + " is closed"}}}
];
}
else if(close_response.get("response_status").get("messages").get(0).get("status_code") == 4007)   // request is already closed
{
close_success_requests = close_success_requests + request.get("request").get("id") + ", ";
}
else
{
close_success_requests = close_success_requests + request.get("request").get("id") + ", ";
}
}
description = close_success_requests + "<br>" + close_failed_requests+ "<br>";
change_description = "<h3>Change Initiated Requests are closed as the change has been moved to closed state<br>Status:-<br></h3>" + description;
notes = zoho.sdp.invokeurl
[
url :"/api/v3/changes/" + id + "/notes"
type :POST
parameters:{"input_data":{"note":{"description":change_description}}}
];

    • Related Articles

    • Workflows Use Cases

      Workflows Pointers Workflows can be configured for All Customers as well as for a specific customer, but not site-specific. This setting is module-specific. Separate workflows for incident requests and service requests can be configured. If an asset ...

    • Use Cases

      Scenario: Convert Incident to Service Request Currently, only incident requests can be created via email using the default template. However, Zylker wants to create service requests based on specific keywords found in the email, aligning with their ...

    • Triggers

      Triggers execute automated actions when certain events occur in the service desk. Triggers are useful for executing condition-based actions across modules or in third-party applications. Use Case: Triggers automate several processes, such as sending ...

    • Triggers

      Trigger specify conditions under which predefined actions must be performed on incoming requests. These are useful for calling actions after the requests are created, especially for performing actions in other modules or in third-party applications. ...

    • Notification Rules Use Cases

      Notification Rules Pointers Supported Modules: Requests, Problems, Changes, Projects, Release, Solutions, Assets, Purchase, Contracts, Tasks, and other general events. Supported Notifications: Email, SMS, and Push. Actionable Messages can be enabled ...