How Ignio marks a ticket from external tool (ServiceNow etc.) to be duplicate
rishabh.vermaParticipant2 years, 1 month ago #3620
Recently we have seen due to some issue, Updates from Ignio to SNOW broke, which caused external ticket stuck with Ignio user as fields in SNOW were not updated, later when we saw the issue we manually reassigned the ticket, and again Ignio picked them as they failed under the filter criteria and triggered the Usecase and updated the ticket.
Since Ignio already worked on the ticket and a usecase was also triggered in first run, there comes a question, Why Ignio did not mark it as duplicate or how Ignio is internally managing to mark the external tool ticket as duplicate when fetched again?
Amit ShastriParticipant2 years, 1 month ago #3621::
ignio’s ‘Duplicate Suppression’ policy should help answer questions on using the type, priority and timeline criteria while marking a particular alert as a duplicate. You can read more here : https://digitate.atlassian.net/wiki/spaces/ID/pages/2178549376/Alert+Suppression+Configuration+SP7#AlertSuppressionConfigurationSP7-_Toc6567385
In addition to that, every time ignio workitem progresses through its lifecycle, ignio sends an update/acknowledgement to the third-party tool (ServiceNow or for that matter any other tool). Typical lifecycle is Acknowledged –> In-progress –> Success/Outtask and you define this in ‘Outward Transformation’ for a particular integration. Considering your scenario, in case of manual update of SNOW tickets, if the same status change pattern is followed, it will be consistent as if ignio is changing the status. This will be useful and act as an additional filter while ignio picks up the tickets/alerts as you would instruct ignio to only pick up the tickets in ‘new’ status (and nothing else). This should help avoid duplication explicitly.
Hope this helps.
You must be logged in to reply to this topic.