Hi Brent,
Sorry for the delay, I’m having reactions to my 1st covid vaccine shot which I received last week.
Indeed that type of error handling requires knowing all the possible ways to handle errors within an automation and to plan for the ability for failed transactions to be retried.
Transaction retries are the easiest to understand. The system lets you retry from an action, either the one that reported the error or one that precedes the failed action. On its own the system cannot retry a failure that occurs within a sequence of logic built into an action assembly.
So on one hand that can determine whether large complex action assemblies are built in the assembly editor, or if that logic needs to be broken into smaller actions that are orchestrated in the automation editor.
There is a possible way to handle retry logic internal to large action assemblies. But it would be basically brute force, where the assembly logic would use the Simple DB modules as a way to store processing state and logic would have to be built to know where to start processing based on the saved state. This is sort of theoretical, I don’t think it has actually been done in practice yet.
It sounds like at the moment you are more in need of a way to update the last action in the automation’s chain, Salesforce, to record the success/failure of the processing that occurs beforehand.
But you need to understand that error handling and retry logic go hand-in-hand. From the system’s point of view if you don’t halt automation processing of a failed transaction via built-in error handling (e.g. configure actions to “continue on error”) and instead let it fall through such that the last action is to record the error in Salesforce, then from the point of view of the system the transaction was a success and you won’t be able to retry it.
Based upon what you have described, I think your desired solution will have to involve multiple automations. One automation is the parent, which has the trigger. The chain of actions would be to invoke another automation (child) that performs your Intacct logic on the data row. This would be via the System app’s “execute automation” action, configured to “wait to complete” so that any error message will be returned. Pass the data row to be processed via the “webhook payload”. Then the parent automation has a conditional to inspect for that error message and actions to update Salesforce accordingly.
To receive the webhook payload in the child automation, use the “Webhook” app’s “new webhook received” trigger. You will need a sample data row to send that trigger when configuring via Postman or some other tool that can invoke the webhook URL and POST the data row to it.
I believe this multi-automation approach will let you keep your existing Intacct action logic as-is, assuming it meets your needs for failed transaction retries. I was describing the retry logic in hopes that you understand why I think trying to do everything you need in a single automation will most likely be difficult.
I don’t think we have used the webhook payload mechanism in practice yet to send a data row from one automation to another. I recommend you do some experimentation with the multi-automation approach first, if you decide to go down that path.
Keep in touch and let us know how we can help!
