Ticketing System Condition
Overview
You can add a Ticketing System Event Condition to your package so that your package is triggered based on the changes made to a ticket in your ticketing system. This may include adding a new ticket or updating an existing ticket.
One of the example scenarios where this condition is currently used in Pia is in the Triage package. The Triage package is triggered when a new ticket is created, or an existing ticket is updated in a specified board in the ticketing system. When the package runs, tickets are then triaged based on the rules and conditions specified in the package.
The Ticketing System condition can be located in the list of conditions in the package editor:
Here is an example of a basic package that uses Ticketing System condition:
# Pia Automation Package
conditions:
- name: 'system_ticketing'
entity: 'ticket'
action: 'created,updated'
filter: 'ticket.priority.name == "Priority 1 - Critical"'
instancing: 'single'
steps:
- task: cw_get_ticket_by_id
inputs:
ticket_id: =system_ticketing.ticket_id
- task: inline_powershell
inputs:
ticketInfo: =system_ticketing.ticket_id
script: |
Write-Host $ticketInfo
In this example, the package is triggered when a new ticket is created in the ticketing system. The package will then move the ticket to either 'Service Request' board or 'Incident' board based on the rules specified.
Condition Behavior
When a ticket is updated or created in the ticketing system which means that the user has saved the ticket record in the ticketing system, this will trigger the package execution as long as the filter criteria of the ticketing system event condition is met.
The ticketing system may also perform its own workflow actions on a ticket which may cause additional update events to be generated from the ticketing system after the user saves the ticket. To avoid executing multiple instances of a package for a single save action, you can use a combination of the instancing, blocking and delay seconds input properties to control this behavior.
The Ticketing System Event Condition is only active in Live mode, not in sandbox mode. To test your package in sandbox mode, you will need to use the "Test Execute" feature or temporarily add a chat_interaction condition for use via the chatbot.
Input Properties
Use properties to modify the behavior of the condition.
Property Name: entity
Property Required: Yes
Property Options: ticket, opportunity, company
Property Description: The name of the entity to monitor for events which may trigger this package to execute
Property Name: action
Property Required: Yes
Property Options: created, updated, deleted
Property Description: The action on the entity which may trigger this package to execute
Property Name: filter
Property Required: No
Property Description: Use c# syntax to create a logic condition which evaluates to true or false. Refer to the "Filter Condition Expressions" heading at the bottom of this article for examples and details.
Property Name: instancing
Property Required: No
Property Options: 'single' or 'multiple'
Default Option: 'multiple'
Property Description: Specify single if you only want this package to run if there isn't already one running for the entity. This can be used to prevent multiple packages from starting at the same time for a single ticket save events if multiple events are received from the ticketing system in a short timespan for the same ticket (or entity).
Property Name: blocking
Property Required: No
Property Options: 'true' or 'false'
Default Value: 'false'
Property Description: Blocking will make sure only one instance of this package can be run at a time, regardless of the entity id. Any pending events will be queued until the previous instance of the package completes (in other words, blocking will still process the event, it will just be delayed. This is unlike the instancing property which will ignore secondary events while package is already running).
Property Name: delay_seconds
Property Required: No
Default Value: 0
Property Description: A delay seconds property can be used to delay the evaluation of the filter criteria and execution of the package. For example, in the case where multiple events are received from a single Save action in your ticketing system, if a workflow is running in your ticketing system on your ticket, you may want to wait until that workflow completes before evaluating your filter criteria in case the workflow modified properties which your filter criteria relies on.
Output Properties
Here are the output properties which the Ticketing System condition makes available.
Property Name: ticketing_client_id
Property Description: The client id of the client from the ticketing system event
Property Name: client_id
Property Description: The Pia client id of the client for which the package is running
Property Name: opportunity_id
Property Description: The id of the opportunity event for which this package is running
Property Name: ticket_id
Property Description: The id of the ticket event for which this package is running
Filter Condition Expressions
By using the filter input property of the ticketing_system condition, you can limit the circumstances for which your automation will be triggered by a new ticket or ticket update. This is extremely useful for custom automation you create, where you want to do something for a specific condition or for the triage automation where you want to only triage tickets under limited conditions.
Here is a non-exhaustive list of examples you may wish to take and customize for yourself:
| Filter Text | Description |
|---|---|
| filter: '(ticket.board.name == "Service Desk" && ticket.status.name == "New") \|\| (ticket.board.name == "Dispatch" && (ticket.status.name == "New (Portal)" \|\| (ticket.status.name == "New (Email)"))' | Match tickets on the Service Desk board in the "New" status or where the ticket is on the dispatch board in either the "New(Portal)" or "New(Email)" status. |
| filter: 'Regex.Match(ticket.summary, "^Backup for .* failed$").Success' | Match tickets where the ticket summary/subject is in the pattern "Backup for XYZ failed". |
| filter: 'ticket.closedDate != null' | Match tickets which have been closed (Have a closed date) |
| filter: 'ticket.parentTicketId == null' | Match tickets which are not a child ticket (do not have a parent ticket) |
| filter: '((IEnumerable<dynamic>)ticket?.customFields)?.Where(c => c.caption == "Pia Serviceable" && c.value == "Yes").Count() > 0' | Match tickets where the custom field "Pia Serviceable" is set to "Yes" |
| filter: 'ticket.priority == null' | Match tickets where the priority of the ticket is not set |
Depending on which entity you use (opportunity, ticket, company) you will be able to access certain objects and their properties:
| Entity | Available Objects |
|---|---|
| ticket | ticket,company |
| company | company |
| opportunity | N/A (Not Yet Supported) |
Each object you can use in the filter has properties which you can check. These properties are supported across all ticketing systems which Pia supports. The properties are as follows:
| Entity | Property | Sub-Property | Expression | Notes |
|---|---|---|---|---|
| ticket | id (text) | ticket.id | The ticket id (e.g. 34556) | |
| ticket | summary (text) | ticket.summary | The ticket subject/title/summary | |
| ticket | board | id (number) | ticket.board.id | Lookup value associated to the ticket |
| ticket | board | name (text) | ticket.board.name | Lookup value associated to the ticket |
| ticket | type | id (number) | ticket.type.id | Lookup value associated to the ticket |
| ticket | type | name (text) | ticket.type.name | Lookup value associated to the ticket |
| ticket | subType | id (number) | ticket.subType.id | Lookup value associated to the ticket |
| ticket | subType | name (text) | ticket.subType.name | Lookup value associated to the ticket |
| ticket | item | id (number) | ticket.item.id | Lookup value associated to the ticket |
| ticket | item | name (text) | ticket.item.name | Lookup value associated to the ticket |
| ticket | contact | id (number) | ticket.contact.id | Lookup value associated to the ticket |
| ticket | contact | name (text) | ticket.contact.name | Lookup value associated to the ticket |
| ticket | owner | id (number) | ticket.owner.id | Lookup value associated to the ticket |
| ticket | owner | name (text) | ticket.owner.name | Lookup value associated to the ticket |
| ticket | company | id (number) | ticket.company.id | Lookup value associated to the ticket |
| ticket | company | name (text) | ticket.company.name | Lookup value associated to the ticket |
| ticket | priority | id (number) | ticket.priority.id | Lookup value associated to the ticket |
| ticket | priority | name (text) | ticket.priority.name | Lookup value associated to the ticket |
| ticket | status | id (number) | ticket.status.id | Lookup value associated to the ticket |
| ticket | status | name (text) | ticket.status.name | Lookup value associated to the ticket |
| ticket | source | id (number) | ticket.source.id | Lookup value associated to the ticket |
| ticket | source | name (text) | ticket.source.name | Lookup value associated to the ticket |
| ticket | displayId (text) | ticket.displayId | (AutoTask and Service Now Only) this is the "friendly id" of a ticket (i.e. T20231027.001) | |
| ticket | customFields (collection) | caption | ticket.customFields[0].caption | (ConnectWise and Halo PSA Only) this is the display name of the custom field |
| ticket | customFields (collection) | value | ticket.customFields[0].value | (ConnectWise and Halo PSA Only) This is the value of the custom field |
| ticket | closedDate (nullable date) | ticket.closedDate | ||
| ticket | parentTicketId (nullable number) | ticket.parentTicketId |