Exceptions and Retries
An exception means something unexpected happened while a workflow was running. Most often that is a problem reaching or communicating with an outside system: your PSA, a webhook endpoint, an AI provider, or any other third-party API.
This applies to every product. Email Processing, Scheduled Tasks, Forms, and Workflows all run on the same engine, so they all handle exceptions the same way.
MSPintegrations does not fail on the first sign of trouble. It classifies the problem, retries anything that looks temporary, and only gives up when retrying cannot help.
Transient Errors and Fatal Errors
Every error falls into one of two categories.
Transient errors are problems that are likely to resolve on their own: the API is down for maintenance, a request timed out, a rate limit was hit, a connection dropped. MSPintegrations pauses the workflow and tries again later. The first retry happens within seconds, and the wait grows with each failure, up to roughly ten minutes between attempts. It keeps retrying for several days before giving up, which is long enough to ride out most third-party outages without losing work.
Fatal errors are problems that retrying cannot fix: invalid credentials, a request the other system rejected as invalid, a permission the API user does not have, a required field left empty. Retrying produces the same rejection, so MSPintegrations stops immediately rather than wasting time.
Some errors do not clearly announce which kind they are. MSPintegrations retries those a few times over several minutes, then treats them as fatal.
What You See While a Workflow Retries
A retrying workflow is not a failed workflow. In history, its status alternates between Waiting and Processing, and the log records each attempt as a yellow warning:
TEMPORARILY FAILED. Will retry in 30 seconds (will continue to retry up to 3 more times)
You do not need to do anything. If the underlying problem clears, the workflow picks up where it left off and completes normally.
When MSPintegrations gives up, the log records a red error instead:
PERMANENTLY FAILED. Will not retry.
What Happens When a Workflow Fails
Three things happen together:
- The run stops. No further action steps execute.
- History marks the run Failed. The entry shows a red ✕, and the log contains the error, the message returned by the outside system, and how long the run took before it failed.
- MSPintegrations emails your notification addresses. The email identifies the run, includes the error message, and links straight to the history entry.
If you have no notification addresses configured, no email goes out and nothing tells you the run failed. Set them up: Exception Notifications.
Some errors are not safe to display, so history shows Internal Error or a message with a correlation ID instead of the raw detail. The full error is recorded on our side. Send the correlation ID or the history link to support and we can look it up. See Requesting Support for a Specific Email.
Diagnosing a Failure
Work through it in this order:
- Open the history entry from the notification email or from history in the console.
- Read the log. It shows every step, every call made to an outside system, and the exact response that came back. The failing step is marked with a red triangle.
- Decide whether it is your configuration or the other system. A rejection that names a field, a permission, or a value is almost always something to fix in your rule. A timeout or an outage is not.
- Fix the rule, then replay. The Play button on a history entry re-runs the same trigger through your current configuration. You do not need to send a new email, wait for the next schedule tick, or resubmit a form.
Learn more → Core Concepts: The Processing Log
Choosing What an Action Does on Failure
Many actions let you choose what happens when they cannot complete. The option is usually named something like Action When Complete, or an explicit setting such as Generate an exception if no results.
| Choice | Effect |
|---|---|
| Exception | Stop the workflow, mark the run failed, and send a notification |
| Continue | Record the problem in history and run the next step anyway |
| Stop | Stop this rule but let later rules run |
| Stop All | Stop this rule and all remaining rules, without marking the run failed |
Use Exception when a failure means the automation did not do its job and somebody needs to know. Use Continue when a step is genuinely optional.
A common mistake is choosing Continue to quiet a noisy alert. That hides the problem rather than fixing it, and later steps then run against missing data. If an action fails often enough to be annoying, the configuration usually needs attention.
Query actions have their own Generate an exception if no results setting. Leave it unchecked when finding nothing is a legitimate outcome, such as checking whether a ticket already exists. Enable it only when an empty result means something is genuinely wrong.
Suppressing Exceptions
Autotask actions have a Suppress Autotask API exceptions checkbox that lets the workflow continue when Autotask rejects a call. It is unchecked by default, and it behaves differently from the options above. See Autotask Exceptions before you use it.
There is no equivalent setting for ConnectWise PSA or HaloPSA.
What's Next
- Exception Notifications: configure who gets emailed when a workflow fails.
- Autotask Exceptions: how Autotask errors are classified and what the suppression checkbox does.
- Core Concepts: the processing log, replay, and the model shared by every product.