Overview #
Exception Strategies allow you to control how SiPHON responds when an error occurs during a process. You can define a
Default action (a fallback for any unhandled exception) and one or more
Classed Exception Strategies (targeted rules for specific exception types).
The Exception Strategies Panel #
The
Exception Strategies panel is divided into two sections:
- Default — defines the fallback behaviour for any exception not covered by a classed rule
- Classed Exception Strategies — defines targeted behaviour for specific exception classes
(interactive walkthrough to be added here)
Default Exception Action #
The
Default Exception Action dropdown controls what happens when an exception is encountered and no matching classed strategy exists.
| Option |
Description |
None (Inherit) |
No action is defined at this level. Behaviour is inherited from a parent process or platform default. |
Continue |
The process continues past the exception without interruption. |
End |
The process terminates. Additional fields appear to configure the outcome. |
When End is selected #
Two additional fields become available:
Default Exception Workflow Status
Sets the status the process will end with.
| Value |
Description |
Success |
The process is marked as successfully completed. |
Warning |
The process ends with a non-critical warning state. |
Error |
The process ends in an error state. (Default) |
Default Exception Flow
An optional dropdown to select a flow that will execute when the exception is encountered. Use this to trigger notifications, logging, or compensating actions.
When Continue is selected #
Only
Default Exception Flow is shown — no status is required since the process continues.
Classed Exception Strategies #
Classed strategies let you override the default behaviour for specific categories of exceptions. Use the
Add Classed Action dropdown to add one or more exception classes.
Each class you add appears as its own section with its own configuration fields. A
Remove Class button is available on each section to delete it.
Exception Classes #
| Class |
Description |
| System Exception |
Unexpected system-level failures, such as timeouts or infrastructure errors. |
| Throttle Exception |
Rate-limiting responses from an external service. |
| Authentication Exception |
Authentication or authorisation failures. |
| Data Exception |
Data validation or transformation failures. |
Configuring a Classed Exception Strategy #
Each classed strategy section displays the exception class name at the top (e.g.
Exception Class: Throttle Exception) and contains the following fields.
Flow Action Type #
Defines the action to take when this exception class is encountered.
| Option |
Available for |
Continue |
All classes |
End |
All classes |
Retry |
System Exception, Throttle Exception only |
Note: Retry is not available for Authentication or Data exceptions. Auth failures are unlikely to resolve by retrying, and data errors are deterministic — the same input will produce the same failure.
When End is selected #
Exception Flow (optional)
Select a flow to execute when this exception is encountered.
Exception Flow Status
Sets the status the process will end with:
Success,
Warning, or
Error.
When Continue is selected #
Exception Flow (optional)
Select a flow to execute when this exception is encountered. The process will continue after the flow completes.
When Retry is selected #
The following fields appear to configure the retry behaviour.
| Field |
Required |
Type |
Description |
| Max Retry Count |
Yes |
Number |
The maximum number of retry attempts before the retry strategy is exhausted. |
| Back off |
Yes |
Boolean (toggle) |
When enabled, the delay between retries increases with each attempt. |
| Delay Before First Retry |
No |
Number (ms) |
Delay in milliseconds before the first retry is attempted. Only active when Back off is on. |
| Subsequent Retry Delay Multiplier |
No |
Number |
Multiplier applied to the previous delay to calculate the next retry delay. Only active when Back off is on. |
| Retries Exhausted Action Type |
No |
Dropdown |
Action to take once all retries are exhausted. Options: None, Continue, End. Defaults to End. |
| Retries Exhausted Flow Status |
No |
Dropdown |
Status to end the process with when retries are exhausted. Options: Success, Warning, Error. Defaults to Error. |
| Retries Exhausted Exception Flow |
No |
Dropdown |
A flow to execute when retries are exhausted. |
| Retries Exhausted Exception Flow Input Mapping |
No |
Mapper / Expression |
Input mapping to pass data into the retries exhausted exception flow. |
Backoff Behaviour
When
Back off is enabled, each retry waits longer than the previous one. For example, with a
Delay Before First Retry of
1000 ms and a
Subsequent Retry Delay Multiplier of
2:
| Retry |
Delay |
| 1st |
1000 ms |
| 2nd |
2000 ms |
| 3rd |
4000 ms |
Field Visibility Summary #
The fields displayed depend on the
Flow Action Type selected for each section:
| Field |
Continue |
End |
Retry |
| Exception Flow |
 |
 |
— |
| Exception Flow Status |
— |
 |
— |
| Max Retry Count |
— |
— |
 |
| Back off |
— |
— |
 |
| Delay Before First Retry |
— |
— |
 |
| Subsequent Retry Delay Multiplier |
— |
— |
 |
| Retries Exhausted Action Type |
— |
— |
 |
| Retries Exhausted Flow Status |
— |
— |
 |
| Retries Exhausted Exception Flow |
— |
— |
 |
| Retries Exhausted Exception Flow Input Mapping |
— |
— |
 |
Examples #
Example 1 — Default End on error, continue on data issues #
A common setup: end the process with an error by default, but silently continue past any data validation failures.
Default:
- Default Exception Action:
End
- Default Exception Workflow Status:
Error
Classed Exception Strategies:
- Data Exception → Flow Action Type:
Continue
Example 2 — Retry throttle errors with backoff #
Retry up to 5 times when rate-limited, with increasing delays between attempts.
Classed Exception Strategies:
- Throttle Exception → Flow Action Type:
Retry
- Max Retry Count:
5
- Back off:
On
- Delay Before First Retry:
2000
- Subsequent Retry Delay Multiplier:
1.5
- Retries Exhausted Flow Status:
Warning
Example 3 — Trigger a notification flow on auth failure #
End the process on authentication failure and trigger a notification flow.
Classed Exception Strategies:
- Authentication Exception → Flow Action Type:
End
- Exception Flow:
notify-auth-failure
- Exception Flow Status:
Error