Service Now SDIM connector max retry exceed and REQ still exist in Snow

Hello everyone,

I’m encountering a rather annoying case via the SDIM connector with Service Now: an REQ that has been open for +30d falls into error in the IDN events and is no longer tracked, but it remains active in Service Now.

image

The operational problem encountered was that the REQ had been processed and validated after the 30 days of tracking by IDN, resulting in a difference in access level between reality (the target application had indeed created the employee) and the information in IDN.

It seemed to me that in such cases, the connector recreated a new ticket for the same request and followed up the new ticket (at the risk of creating duplicates if too many application groups don’t manage their account creation/deletion tickets within 30 days).

I couldn’t find what I was looking for in the documentation :

Thank you in advance for your help on this subject,
Thomas

*30 days in our config, maybe not this by default

You can extend that time by updating the status check config

Hello Mark,

Thank you for this response, which unfortunately does not completely answer my problem which I will rephrase:

How to manage Snow requests if the IDN timeout has expired? (whether this is 30 days or more if we update the config).

It seems to me that the case “the request is not processed on time” handled via “we leave the request open but a subsequent response will never be taken into account” is problematic: might as well close the REQ in this case?

Furthermore, I am convinced that a few months ago expired REQs were recreated by IDN in Snow to follow the new REQ (which is also not a viable solution in my opinion).

If any of you have feedback from your companies/clients on a similar subject,

Thanks in advance,
Thomas

I have also tried to figure out how I can look more into the guts of that process, without success.

Honestly, it sounds like you’re seeking a technical solution to a human problem. If people aren’t taking their responsibilities seriously enough to complete these assigned tasks in a timely manner, coming up with a technical solution to allow that behavior to continue is less than ideal. That of course is just my opinion.

If it were me, I would attempt to apply downward pressure by telling leadership that failure to complete these tasks in a timely manner is preventing us from properly operating our audit controls and could lead to a control exception or deficiency.

1 Like

I completely agree with you on this point Mark, unfortunately it is always towards me that the auditors will turn to demand accountability and not towards the application supports / product owner and I really do not want to waste time on this point :sleepy::sweat_smile:

In any case, thank you for the research on your side and the answers provided :+1::tada:
Beautiful day

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.