Time-based automations

On this page

Introduction

Time-based functionality allows customers to create conditions based on Date or Date and Time fields.

Before creating time-based automations in SolarWinds Service Desk (SWSD), SolarWinds strongly recommends that you understand how automations work. See Automation rules for more information.

Navigation

ITSM customers	ESM customers
Setup > Service Desk > Automation Rules	Service Provider > Service Desk > Automation Rules

Time-based automation examples

• Automatically assign a ticket created during non-business hours to avoid having it sit unassigned for a number of hours. With time-based automation you can automatically assign these tickets to special teams or users.
• Automatically send an email seven days before a ticket’s due date.
• Automatically send an email if there is no Incident index from the requester or agent within a specified period of time.
• Automatically update a ticket's priority if it has no Incident index from a technician after one hour.
• Automatically close a ticket three days after it was resolved.

Understanding regular conditions vs time-based conditions

Although there are two conditions well suited for time-based automation where you can define the Date and Date/Time fields, it is important to understand the difference between them. Each determines when SWSD will check for a match to the condition.

• Regular Condition

  A regular condition performs a check immediately after the trigger occurs.

  Factors to consider: Is the date value in a specific range, for example:

  • Was the incident created during business hours or not?

  • Was the Incident resolved last week?

  • Is the change planned for this month?

• Time-Based Condition

  A time-based condition also checks immediately, but if the time period has not elapsed yet, the condition will schedule a job to recheck at a that point in time.

  Factors to consider: Is the date value relative to a specific moment in time, for example:

  • Is today 7 days before the due date?
  • Is today 3 days after the resolution date?
  • Is now 3 hours after the assignment date?
  • When was the first/last Incident index entered?

Example of the difference

Someone has created two conditions in the same automation rule. One is a regular condition while the other is a time-based condition.

• Regular condition

  Field: Due Date/Time

  Operator: After

  Value: Last Day

  

• Time-based condition

  Amount: 1

  Time Frame: Day

  Operator: After

  Field: Due Date/Time

  

By looking at the conditions you may think they are the same, but they are not.

Regular condition. Because regular conditions check immediately after the trigger occurs, if the trigger were 'object updated', then the condition would immediately check to see if the object was updated after the last day and the result would immediately be True or False.

Time-based condition. When a trigger occurs, the rule runs immediately and checks all the conditions. If there is a time-based condition where the time period has not yet elapsed, SWSD will schedule the rule to rerun in the future after that period has elapsed.

Create an automation rule to test for no comments received

You can test for a situation where a ticket hasn’t been commented on after a specified amount of time by using a Date/Time condition. If you set up a condition that checks the date/time of the last comment, and the ticket has no comments, the reference point will change to the ticket creation time and the condition will resolve to true if the specified amount of time has elapsed since the ticket was created.

You might want to exclude private comments from your automation rule. In the example image below you can see the Public comments only checkbox. In the example, the field selected is Date/Time of Last Comment by Agent.

Agent comments can be public or private, but if the checkbox is selected then only the agent's public comments are counted. If the selected field is Date/Time of Last Comment by Requester, the checkbox is disabled because requester comments are always public.

System fields per condition type

The table below can help you better understand the system fields available for each condition type.

Field	Object	Description
Due Date/Time	Incident	Value of the Due Date field of an Incident
Planned Start Date	Change	Value of the Planned Start Date field of a Change
Planned End Date		Value of the Planned End Date field of a Change
Created Date/Time	Both	Time stamp of the record creation
Last Update Date/ Time		Time stamp of the record update
Resolution Date/ Time		Time stamp of the record resolution
Assignment Date/ Time		Time stamp of record assignment
Reopened Date/ Time		Time stamp of the record reopening

To help you use these fields in regular conditions, the table below defines the dynamic values.

Field	Description
Last Day	Checks if the selected value is 24 hours from the rule trigger time stamp. Last day is available only for Date and Time fields.
Last 7 Days	Checks if the value of the selected field is 7 days from the rule trigger time stamp.
Last 14 Days	Checks if the value of the selected field is 14 days hours from the rule trigger time stamp.
Last 30 Days	Checks if the value of the selected field is 30 days hours from the rule trigger time stamp.
Last 60 Days	Checks if the value of the selected field is 60 days hours from the rule trigger time stamp.
Last 90 Days	Checks if the value of the selected field is 90 days hours from the rule trigger time stamp.
Last Week	Checks if the value of the selected field is in the last week.
Last Month	Checks if the value of the selected field is in the last month.
Last Quarter	Checks if the value of the selected field is in the last calendar quarter.
Last Year	Checking if the value of the selected field is in the last calendar year.
This Week	Checks if the value of the selected field is in this week.
This Month	Checks if the value of the selected field is in this month.
This Quarter	Checks if the value of the selected field is in this calendar quarter.
This Year	Checks if the value of the selected field is in this calendar year.
End of Month	Checks if the selected date or date/ time field is the last day of the month according to that date.
End of Quarter	Checks if the selected date or date/ time field is the last day of the calendar quarter according to that date field selected.
End of Year	Checks if the selected date or date/ time field is the last day of the calendar year (31/12) according to that date field selected.
Business Hours	Checks whether a specific date/time is in the range of the business hours per the specific date and time field. Business hours is available for Date and Time fields only. When using Business Hours it is mandatory to select at least a single site.

Current limitations

As SolarWinds is always looking to enhance your user experience, we would like to point out a few areas that will help you make the best use of the time-based automations feature.

Limitations	Error Message Displayed
Time-based conditions are limited to 13 months.	An automation rule cannot exceed 13 months
Time-based conditions are limited to 400 days.	An automation rule cannot exceed 400 days
Time-based conditions are limited to 9600 hours	An automation rule cannot exceed 9600 hours
Time-based conditions are limited to 57,600 hours	An automation rule cannot exceed 576000 hours
The total amount of scheduled jobs you can have on your instance = 5000	When exceeding this amount, you will receive the following email: Title: Time-Based Automation Jobs Limit Exceeded Body: Hello %{user} You have exceeded your instance’s time-based jobs limit of %{limit}. Please contact Solarwinds Service desk Support at support@samanage.com

More information on time-based automations is available in Thwack.

See Automations for instructions on how to create an automation rule.

Related topics

• Automations
• Automation rule to mirror a three-strike policy