Error handling best practices

Trying to find a good way to handle errors and notifications

Say for example I have an automation with salesforce and intacct. Trigger is for any new or updated invoice in SF, i write the invoice in intacct. There are obviously a few lookups along the way and multiple actions.

(trigger) new invoice → (action)lookup project in intacct → lookup customer in intacct → create invoice → update record id back to salesforce

There could be errors anywhere along that path. maybe a bad reference and the project doesnt exist, or the customer doesnt exist, etc. What i am looking to do is find the best way to get those specific errors out (if they happen) and map that to the update record at the end.

Currently most assemblies have the fatal error module which notifies me as the admin but instead i want to be able to catch that error and push it out to the end so i can use it and update the record in question. catch is it then fails the automation, it stops there and i cannot perform any subsequent steps (like writing anything back)

I could remove that module and pass the value through the action output, do a bunch of conditions after each and update the record but then i lose the ability to reprocess failed. And if one error caused an error in the next action, then i have multiple false errors.

Do you have a preferred way to handle this or any ideas?

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!

Hi Robert,

I have been working on this and trying to get the best of both worlds. I realize what would be great would be a fatal error module that you could nest a subassembly in to perform a final act. say an email, update a record, etc. just a way to do something else with it to write your results back and still maintain the ability to handle the errors in the logs/automation and retry.


Hi Brent,

Sorry for the delay, the forum software apparently didn’t send me an email about your response.

I think that’s a great idea, will build that Fatal Error module for the next system release.

We just installed the latest system release into for live testing last weekend. Seems to be running ok. I anticipate we will install the new release to your server either this weekend or next weekend.


awesome. thanks.

if you happen to get that pushed out early, i would be happy to be the guinea pig for it. would really come in handy with a particular client.


Have installed into your system:

Let us know if it doesn’t work for you.

wow that was fast. thanks

I will give it a run and let you know. appreciate it

this has been working well but i find it to be a bit limited. in what i am able to do.

using the above example, if i have the new fatal error module setup on one of the intacct actions and there is an error, i am able to send an email from within the action. great. the catch is since i can only assign one set of credentials for the app, i can only perform actions tied to that app or generic actions that i can pass knows values through the action input and carry them down (which is basically what i am doing now for emailing errors out and it seems to work well enough).

Ideally (if even possible) we could have the fatal error recognize the app in its sub assembly to dynamically assign a second set of credentials.

So say I have an action that i want to reuse often, it is specifically for creating SF accounts in Intacct. As is I can only assign intacct credentials to perform that action. But if it could recognize that I have a SF subassembly in the fatal error, then i could assign two sets of credentials and when the error happens I can write it directly back to SF. I know I could build the action to carry credentials from the action input but then i have to know them and cant just use the system stored credentials which kind of defeats the purpose.

I am sure there are multiple and probably better ways to handle this. just spit balling and trying to see what else can be done or if you have any good ideas


It sounds like you want to pass in the account to use to the nested subassembly, which can be done. You need to enable this setting shown. Then modules that operate upon accounts will show the account field, which you can then pass into the nested subassembly to control which account is operated upon: