Due date rules set due dates on service records automatically. Any service record that matches the conditions in a rule receives the due period that rule specifies, so your team doesn't have to set deadlines by hand or remember what each customer is entitled to.
Due dates are what the rest of your service level setup measures against. Escalation rules fire when a due date passes, timers run against it, and SLA reporting counts breaches from it. Getting due dates right is what makes everything downstream meaningful.
How due dates are calculated
A due date rule specifies a due period, not a fixed date. When a service record matches the rule, SysAid adds that period to the submission time to work out the due date.
The period is counted in operating time, not on the clock. SysAid uses the operating times of the request user's agreement, or of their company if they have no agreement of their own. Time outside operating hours doesn't count.
For example, a service record submitted with a due period of 6 hours when only 3 hours of operating time remain in the day falls due 3 hours after the start of the next operating day.
This is why operating times are worth setting up before you build due date rules. A rule built against the wrong operating hours produces due dates that look right and land wrong.
Please note:
Operating times are configured separately under Settings > Administration > Operating Times. See Modify Operating Times.
Limits
A due period can be anywhere between 15 minutes and 8760 hours, which is one year.
Please note: Periods shorter than 15 minutes aren't recommended. Other scheduled processes, escalation rules among them, run on their own intervals and may not act on a due date that arrives sooner than they do.
When due dates are recalculated
By default, a due date is recalculated whenever a service record changes in a way that makes it match a different rule.
The Calculate due dates only on new incidents setting narrows this in two ways at once. Rules run only on Incident-type service records, and only on ones created after you turn the setting on. Records that already exist keep the due dates they have.
Two things also affect recalculation:
Converting a service record from one type to another can trigger a new rule and set a new due date.
Dynamic due dates push the due date forward while a service record sits in a paused status, so time spent waiting on someone else doesn't count against you.
Next steps
Creating and Managing Due Date Rules, for building the rules themselves and choosing what they apply to.
Adding Dynamic Due Dates to Service Records, for pausing the countdown while a record is waiting on the end user or a third party.