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?
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.
