Timer Actions

Timer actions allow you to execute time-delayed automated actions on requests and records.

Supported modules: Requests and Custom Modules

Requests

When an incoming request satisfies a predefined timer criteria-condition, ServiceDesk Plus calculates the wait time of requests and schedules the timer accordingly. When the wait time is completed, the timer actions will be executed.

Custom Modules

The system calculates the wait time for records that meet specific conditions and triggers the action after the delay period ends.

 

Configuring During Rules and After Rules is essential for the smooth execution of timer actions. 

 

Role required: SDAdmin and HelpdeskConfig

 

 

This page discusses timer actions under the following topics:

 

When Can I Implement Timer Actions? 

An incoming request goes through several stages before resolution and closure. During its transit, the request may stay idle in multiple stages for various reasons. Timer actions help you identify such prolonged wait times and trigger specific actions so that requests can be resolved quickly.

 

For instance, if a request is waiting for customer input, you can configure timer actions to send reminders for 3 days, and cancel the request on the fourth day of no response, along with a notification to the requester.

 

 

Timer actions, like other automation rules, can be configured to execute specific actions when specific conditions are met. However, there are some differences between timer actions and other automation rules.

Execution Order

ServiceDesk Plus provides several types of automation rules. When a Timer Action updates a request, multiple automation rules may be applicable to the request. In such cases, a clear order execution is defined in ServiceDesk Plus, as shown in the following diagram: 

 

 

Besides the above order, Custom Schedules can be executed anytime.

 

Configure Timer Actions

Go to Admin > Automation > Timer Action > Request/Custom Module. Click New and fill out the attributes as specified below:

➤ Initial delay: Set up a time delay to execute timer actions at a specific time or stage. For multiple stages, the wait time is calculated based on the execution time of the previous stage.

 

User defined

Manually set the wait time by days, hours, and minutes.

For example, 1 day and 6 hours.

Date field duration

Automatically calculates the wait time by before, after, percentage, and date matches of a request.

Before - Execute rules before the request reaches the specified date/time.

After - Execute rules after the request reaches specified date/time.

Percentage - Execute rules when the request reaches specified completion percentage of date/time.

Date matches - Execute rules when the request matches the specified date/time.

 

➤ Repeat Every: Choose whether to repeat the action. Set the frequency and number of repetitions from the drop-down.

➤ Consider delay time on (applicable for requests only): Choose whether to consider the initial delay time only during business hours or SLA hours. If you choose SLA hours, you can pause the timer when the request moves to onhold, completed, or resolved states. If the delay time is not configured, the timer will run 24x7.

If a request has an SLA with the Should be resolved/responded irrespective of operational hours/holidays/weekends condition selected, the timer will be scheduled based on SLA hours.

➤ Configure Actions or During Rules, and After Rules. After configuring actions or during and after rules, you can use cascade execution option to execute actions/rules in sequence or break the rule execution. Click Reorder to organize the rules.

You can configure either actions or during/after rules, but not both.

Supported Actions

Requests: Field Update, Notification Action, Custom Function, Execute Script, Webhook, If-If, and If-Else.

Custom Modules: Field Update, Notification Action, Custom Function, Execute Script, If-If, and If-Else.

 

 

Request history records the updates performed by timer actions.
Timer (running) will be suspended if a request is trashed and will resume when the request is restored.
Deleting a timer action clears the timers associated with the requests.

 

List View Actions

Edit - Click to modify the details of timer action.

Delete/Enable/Disable Timer Actions - Select the timer action and click the Actions menu to select the required option. You can also use the Toggle button beside the timer action to enable or disable it.

During Rules

During rules are used to automate actions on requests when the stage delayed time is reached for a request. For each stage, you can add up to 5 During Rules, which will be executed in sequence. The request data modified by a During Rule will be considered when the next rule is validated.

 

You can reuse During Rules for other stages and timer actions.

 

 

Create During Rule

Click During Rules > Add New Rule.

Use the pointers below to create a new rule:

➤ Execute custom actions - The custom action will be executed on a request that meets the configured criteria. Select the custom action. Turn on Toggle to Override request values with rule.

To learn about updating a request field, click here.
To learn more about writing a custom script, click here.
To learn more about request custom function, click here.

To learn more about If-If action, click here.

To learn more about If-else action, click here.

You can configure a maximum of 5 actions in a During Rule: Script/custom function (1), field update (2), If-If (1), and If-else (1).

➤ Abort process execution - This option stops current stage execution. In case of stage repetition, executes actions after the wait time and proceeds to the next stage.

 

 

Associate Existing During Rule

If you want to reuse the existing During Rules, hover over the during rule section and click Associate Rule. Select the rules you want to associate and click Associate.

 

During Rule List View Actions

Edit During Rule - Click beside the During Rule to modify its details.

Delete/Enable/Disable Rule - To delete, enable, or disable the rules, select the rules. Click Actions and select the required option. You can also use Toggle to enable or disable the During Rules.

 

After Rules 

After rules are used to automate actions within ServiceDesk Plus or third-party applications when the stage delayed time is reached for a request. For each stage, you can add up to 5 After rules, which will be executed in sequence.

 

You can reuse After Rules for other stages and timer actions.

 

 

Create After Rule

Click After Rules > Add New Rule.

Use the pointers below to create a new rule:

 

 

Associate Existing After Rules

If you want to reuse the existing After Rules, hover over the after rule section and click Associate Rule, select the rules, and click Associate.

After Rule List View Actions

Edit After Rule - Click beside the After Rule to modify its details.

Delete/Enable/Disable Rule - To delete, enable, or disable the rules, select the rules. Click Actions and select the required option. You can also use Toggle to enable or disable the after rules.

If-If Action

The If-If action allows you to bundle multiple custom actions and execute them when the specified criteria is met.

 

You can configure only one If-If action for a request timer.

 

Scenario: You can use If-If action to update multiple fields and assign the request to a technician.

For instance, if the service category is Application Login, you can configure to update the value of the impact field as Affects Business and if the request type is a Major Incident, you can move the level to Tier 1 and assign the request to a technician.

 

How Does If-If Action Work

The blocks in the If-If action are evaluated sequentially and executed based on criteria match. You can add up to 10 If blocks and configure up to three actions in each If block.

 

Configure If-If Action

You cannot configure custom functions and custom scripts within the same block.

 

 

If-Else Action

You can use the If-Else action to configure actions when the criteria is met and when it is not met.

You can configure only one If-Else action for a request timer.

 

Scenario: You can use the If-Else action to update the impact field of the incoming requests based on the keywords in the subject and description fields.

 

How Does If-Else Action Work

The blocks in If-Else action are validated sequentially.

If-Else action has three types of blocks: If, Else-If, and Else.

 

If block*

  • Executes actions based on criteria match.

  • One If block is available by default.

Else-If block

  • Validates the Else-If block only when the If block is not executed.

  • Executes actions based on criteria match.

  • You can add up to 8 Else-If blocks in between If and Else blocks.

Else block*

  • Executes Else block only when both If block and Else-If block are not executed.

  • One Else block is available by default.

* Mandatory blocks

 

Configure If-Else Action

You cannot configure custom functions and custom scripts within the same block.

 

How Do Timer Actions Work

Timer actions are part of the automation processes available in ServiceDesk Plus. They are applied to requests in the following sequence.

 

  1. Match Criteria: When a user creates or edits a request, ServiceDesk Plus checks whether the request matches the defined timer criteria.

 

  1. Schedule Timer: The timer is then scheduled, and ServiceDesk Plus calculates the initial delay time to execute the configured actions.

 

  1. Execute During Rules/After Rules: After the configured time delay, the During Rules configured within the stage are triggered followed by after rules.

 

  1. Check for Stage Progress: If stage repetition is configured, the repeat time is set, and actions are triggered again. For multiple stages, the workflow will be repeated for each stage sequentially.

 

  1. Complete Timer Action: After all stages and actions are executed, the timer action is completed.

 

If the request is updated mid-way and the criteria doesn't match anymore, the timer scheduled on the request will be cleared.
Request history records all updates performed via timer actions after each timer stage is scheduled and executed.

 

 

Use Cases

Following are some scenarios where Timer Actions can be configured:

These use cases are specific to requests.

 

Scenario

Actions

When a request is waiting for customer input, send reminders to requester and concerned stakeholders for a specific number of days. If there is no response from the customer, cancel the request and notify the requester about request cancellation.

Stage 1:
After Rule: Configure an email notification to send reminder.


Stage 2:
During Rule: Configure a field update to change the status as cancel.
After rules: Configure an email notification about request cancellation.

Make all notes public two days after the request is closed.

Stage 1:

During Rule: Configure a custom script to make notes public.

When a request is logged, search for resolution in all instances. If no resolution is found, assign the request to a technician one day after the request created date.

Stage 1:

During Rule: Configure a custom function to check keywords and copy resolution to the request.

Stage 2:

During Rule: Configure a field update to assign a technician.

When a request is on hold for more than 3 days, send reminders to the technician to update the status. If no action is taken, escalate to group or site incharge.

Stage 1:
After Rule: Configure an email notification to remind the technician.


Stage 2:
After Rule: Configure an email notification to group or site incharge to escalate the issue.

To mark a technician as inactive in Active Directory after being relieved from the workplace.

Stage 1:

After Rules: Configure a custom function or webhook to mark the technician as inactive in Active Directory when the specified time is reached.

Automatically create a request to extend technicians' access permission to the server. The request should be created one day before the end of expiry date.

Stage 1:

After Rules: Configure a custom function to create a request one day before the end date to extend access permission to the server.

Move the ticket to In-Progress status and notify group incharge if the employee's relieving date is due.

Stage 1:
During Rule: Configure a field update to change the ticket's status.
After Rule: Configure an email notification about employee's relieving date.