Error handling for Flow Designer outbound REST integrations

[Tom Sienkiewicz]

Hi, I'm curious if anyone has some interesting patterns/concepts in term of handling integration errors.

Some general thoughts I always have around this:

• If triggered manually, should current user  be notified immediately of error? Perhaps via info message/email/work notes? So that they can take some action? This suggests synchronous approach, especially if we want to display error to user.
• Do you use custom logging table for your integration payloads? I like to store the request/response, response status and other useful information in a dedicated table. I'm not really very happy with the OOTB logging for this.
• Should a dedicated team be notified of errors, or some incidents created automatically? If so, probably it would be bad to notify them for every single error. So what I do is set up a scheduled process looking at above table, and then send a summary of errors every X time.

Do you have any useful suggestions, good practices for this? Do you also use the FD error handling/retry policy? However it only makes sense to do retries in case of network errors I suppose, so it has limited usage IMO.

Thanks for any thoughts on this.

[Paul Ciarfella]

We have automated access requests that add users to various apps like Okta, Github, internal apps, etc. 

REST failures, like user already exists, user doesn't exist, API rate limiting exceeded, will generate an exception task (catalog task) to the ServiceNow admin team.  We then review the error and can replay the transaction via the workflow, manually make the REST call, or get help from other teams to clear the error condition in the target application.

Some integrations, such as with peer ticketing systems, will log the errors, and then we'll get a report on a daily basis about the errors.

We don't use a custom logging table, but that is a good idea, as I get very frustrated when the OOTB REST logging truncates the request body and its difficult to see if the request was malformed.  We have built  our own API libraries to Okta and other apps, and have various logging levels in the APIs.  But that doesn't help to debug prior calls if logging is not enabled.