This article will walk you through some of the common use cases you could implement business rules,
Showing/ Hiding fields based on Ticket Type
Oftentimes you’ll have specific fields that are shown for Incidents and another set of fields for Service Requests. The Ticket Type field is only available when you are editing a Ticket, so this field only shows up when you’ve created a rule that’s specific to the Edit Form. Here’s an example of how to set this up:-
Actions based on specific Requested Item
There are times when you’d need to mandate/show a Ticket field only if a certain Requested item is part of the Service Request. You can accomplish this by leveraging the Current Ticket based condition in the use case below, where the Agent has to fill in a field called Onboarding Summary before Resolving a ticket that contains an Employee Onboarding service item:-
Mandating specific levels for a dependent field like Category
There are specific use cases that require you to mandate Sub Category, allowing the Item field to remain empty. The Mandate action doesn’t support mandating a specific level, however, this can be accomplished by setting up a simple validation rule by making use of the “Is Empty” operator. Here’s an example below:-
Prevent Agents from directly Closing a Ticket
If you’d like to prevent agents from directly closing tickets for a ticket needs to be resolved first before being auto closed after a specific amount of time using a Supervisor Rule, you can set up the rule below.
Mandate the Additional Details field before an Agent moves a Ticket to the Pending State
Ticket Transitions: Prevent a ticket from being marked as closed if it’s awaiting approval. Here the Current Ticket status captures what status the Ticket is currently in and Ticket Form status captures what the agent is trying to move the status to.
Prevent Updates to Ticket Properties for Closed Tickets: Another Ticket lifecycle use case, where updates to ticket properties should not happen once a ticket is closed.