Policy Design for Service Failures

Alloy's Workflow and Journey builder includes several features specifically designed to improve resiliency at the policy layer. Properly configuring these features allows Alloy to deliver valid decisions even when individual vendor services experience failures. This article covers the available tools in order from least to most interventional: tag-level configuration, workflow-level parsing, journey-level retry orchestration, and full application reruns.

Workflow Failure Tags

Within Alloy's workflow builder, you can configure tags that are applied when a specific service fails. Using the Apply Tag action on service failure conditions allows you to track and filter failure events in the Alloy dashboard over time.

Failure tags are policy-specific and can be used in tandem with Rule-Based Notifications.

Service Failure Handling

Service Failure Handling is a configuration option available on individual Workflow tags and service nodes. It determines how Alloy evaluates affected tags when a vendor service fails or returns no data — allowing you to define how your policy behaves in failure scenarios rather than defaulting to Manual Review for every partial evaluation.

When a service failure occurs and a tag depends on data from that service, you can configure one of three behaviors:

Alloy recommends configuring service failure handling liberally to maintain control over application outcomes during vendor failures.

Best Effort Parser

The Best Effort parser is a Workflow-level setting that changes how threshold logic is evaluated when some input data is null or undefined.

In the default evaluation mode, if a tag's threshold logic references unavailable data, the tag immediately falls back to failure handling — even if the available data would already be sufficient to evaluate the condition. Best Effort Parser changes this: it attempts to evaluate the threshold using only the data that is available, resolving conditions wherever possible.

Example

Consider a phone_risk tag with the following thresholds:

If Ekata: Primary Phone: Is Prepaid is true
  or Ekata: Primary Phone: Line Type is Fixed VOIP | Non-fixed VOIP
  or Ekata: Phone: Matched is false
  or Ekata: Primary Phone: Country Code is matching (regex) /^(DO|UG|NG|LK)$/i
Then set tag phone_risk

If Ekata returned Is Prepaid as true but Phone Country Code was missing from Ekata's raw response:

• Traditional parser: The tag defaults to service failure handling due to the undefined Country Code threshold.
• Best Effort parser: The tag is set to true because the first OR clause resolved to true, making the entire condition safely resolvable.

Resolution Table

Unlike the traditional parser, Best Effort always keeps processing the Evaluation until completion instead of exiting early. This reduces manual review outcomes from partial vendor data without requiring service failure handling on every tag.

Beta Feature: Best Effort parser is currently in beta. To enable it, reach out to [email protected] or your dedicated Alloy contact.

Manual Review, Action & Retry Nodes

When service failures can't be resolved through tag- or workflow-level configuration alone, Alloy's Journey Orchestration supports a retry pattern using Manual Review or Action Nodes. This is suited for transient service failures unrelated to data validation issues or configuration errors.

Setup

1. Configure a dedicated outcome — Set up an Exception or Service Failure outcome in your Workflow for the failure scenario you want to handle.

2. Route to a Review or Action Node — Route Journey Applications that hit this outcome to a node in your Journey:

   • Action Node — Automatically triggers retries on an exponential backoff timer. Recommended for initial retry attempts up to a defined limit. Use the Update Journey Application Action Node endpoint to trigger retries via PUT requests.
   • Manual Review Node — Allows agents to review the failure before triggering a retry. Can be combined with an Action Node for an automated → manual fallback approach.

3. Connect to a Retry Node — Connect the Review/Action node outcome to a Retry node, which loops the application back through the Workflow containing the failed service.

This pattern retries service requests while maintaining a single consolidated Journey Application across all attempts.

Important: This approach is not suitable for errors caused by data validation issues or Workflow/Journey configuration problems. If data or policy changes are needed to resolve the error, use Journey Application reruns instead (see below).

Rerunning Journey Applications

Journey Application reruns are the most flexible retry option — they offer a consistent retry solution for all failure types, including those caused by invalid data on the original submission. Unlike Retry Nodes, reruns always go through the latest active version of the Journey, making them the right choice when a policy update is also required.

Alloy defaults to the same Entity data submitted on the original application, which may be helpful when using Journey Application reruns to retrieve updated results for the same applicant(s). Optionally, you can modify or append fields on resubmission — supported both via API and in the dashboard.

Reruns can be initiated via API using the Rerun Journey Application endpoint or through the Alloy dashboard.

Automated Reruns

To trigger reruns automatically, configure a custom terminal Journey outcome dedicated to service failures. The outcome will be populated in the Journey Application complete_outcome field once processing finishes. Use this field, along with the completed_application webhook event, as the signal to trigger a rerun.

Dashboard Reruns

Reruns can also be initiated manually from the Alloy dashboard — useful when data modifications or policy updates are required before the application can process successfully.

Tracking Reruns

When a rerun is initiated, Alloy sends a started_rerun_evaluation webhook event attached to the original Journey Application in the _embedded.events[] array. Use this event to track rerun history in your system.

External ID Behavior

• external_application_id carries over automatically to the rerun.
• external_group_id does not carry over, but is available in the response under _embedded.rerun:

{
	...
  "_embedded": {
    "rerun": {
      "initiated_by": "api",
      "previous_journey_application_token": "JA-8amRtBU3M98EWa4Hq8j7",
      "root_external_group_id": "8331a098-4238-4e26-bbdf-9a5a103ce509",
      "root_journey_application_token": "JA-8amRtBU3M98EWa4Hq8j7"
    }
  }
	...
}