will not be created and a
400 (bad request) error occurs
| | When I update an ServiceNow ticket with status... | ...and the ilert alert... | ...then the/an ilert Alert... | | ------------------------------------------------- | ------------------------- | --------------------------------------------------------------------- | | **New** | does not exist | is created | | **In Progress** or **Complete** or **Closed** | does not exist |will not be created and a
400 (bad request) error occurs
| | **New** | exists | doesn't change | | **Complete** or **Closed** | exists | change status to **Resolved** if not already resolved | | **In Progress** | exists | change status to **Accepted** if not already accepted | ## Advanced configuration ilert's ServiceNow integration allows you to easily configure advanced settings such as dynamic escalation policy routing and priority mapping. {% hint style="info" %} For the next step, we recommend creating a custom user with restricted permissions. {% endhint %}  To get access to the advanced features, you will have to provide access credentials to your ServiceNow instance first. The provided user will need the following permissions in ServiceNow: * `sys_user` * `sys_user_group` * `cmdb_ci_service` * `service_offering` * `sys_choice` * `sys_dictionary` This will grant you access to: ### Dynamic priority mapping When selecting priority mapping, ilert will contact your ServiceNow instance and fetch all available priorities of ServiceNow alerts. You will then be able to choose a mapping for each of these and determine how ilert will treat them when creating alerts in ilert.  ### Dynamic escalation policy routing When selecting escalation policy routing, ilert will contact your ServiceNow instance and fetch all available alert fields. You will then be able to choose an alert field that should be used for incoming alerts in ilert to determine the routing key.  You may choose to give escalation policies in ilert a unique routing key.  With an incoming event ilert will try to find the right escalation policy based on the routing key and assign the alert to the escalation policy. If no routing key is provided, ilert will use the assigned escalation policy of the alert source. ### Bidirectional alert synchronisation When providing credentials you may choose to activate bidirectional mode on the ServiceNow alert sources. This will cause your alert source to be automatically linked with an outbound connector and alert action. This way status changes to ilert alerts will synchronize to ServiceNow tickets.  When saving the ServiceNow alert source with the bidirectional setting enabled, it will automatically create an outbound connector for you and take you to the creation page of the necessary alert action, **please make sure to continue with the setup of the action to finish your bidirectional alert source setup.**  ### Good to know \ In the bidirectional setup, ilert will try to map users automatically (if **Caller ID** in alert action is left empty) based on their email address. This accounts for actions taken in ilert and synced back to ServiceNow, as well as actions taken in ServiceNow and send to ilert. {% hint style="warning" %} Remember to leave the Caller ID field in the alert action empty for automated user mapping to work properly {% endhint %} When providing a **comment** to the alert in ilert while **resolving** it, ilert will make sure sync the comments content as **resolve information** to the alert in ServiceNow. ### Understanding ServiceNOW <-> ilert flows {% hint style="info" %} This refers to the bidirectional setup {% endhint %} Synchronously mapping the the ServiceNOW ticket/incident lifecycle to the immutable lifecycle of an ilert alert, is not a simple back and forth. The connector runs a lot of state comparisons to identify if a ticket/incident update is needed based on the latest change event of an alert. | Incoming event | State check | Outgoing change operation | | ------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **New (1)** ticket event from ServiceNOW | If alert does not exist, it is created, otherwise the event is dropped (even if the corresponding alert for the ticket is in RESOLVED state) this is determined based on the **sys\_id** of the ticket | Nothing, except if the **priority** or **assignment** of the alert differs from the original ticket status e.g. through configurations of the alert source or escalation policy | | **In Progress (2)** or **Complete/Resolved (6)** or **Closed (7)** ticket update from ServiceNOW |If the alert does not exist, the event is dropped, otherwise:
status -> transition
priority -> raise
assignment -> re-routing
Operations might occur