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.