Integrations: Halting and Errors

This article is intended to provide guidance and responses to common integration retry options and halting scenarios. For more information on reprocessing methods, including manual, automatic, and long term, see Reprocessing Methods for Integration Workflows .

Short-Term Retry

If a step in a task fails, OneTrust will retry the action up to three times. After the fourth attempt, the action will fail. During this time, no error emails will be sent.

Once the maximum retry attempts are reached, the original event message is sent to the Message Container (if enabled for the workflow). No messages are lost or purged during failure.

  • Default max retry: three retries with four attempts

  • Default intervals between failures: five seconds, ten seconds, twenty seconds.

    Retry Number

    Result

    Action

    1

    Failure

    Wait 5 seconds before second attempt

    2

    Failure

    Wait 10 seconds before third attempt

    3

    Failure

    Wait 20 seconds before final attempt

    4

    Failure

    Fail action, messages are sent to Message Container.

Halting and Errors FAQs

When is a workflow set to the halted state?

A workflow is set to the halted state when the workflow fails five times in a moving window of ten executions.

What happens when a workflow is in the halted state but the trigger event occurs (e.g., a DSAR ticket creation). Are they lost? Will they be picked back up if the system is fixed?

Before a workflow execution begins, the OneTrust application will perform a quick check to see if the workflow is in a halted state. If it is halted, the events will go directly to the Message Container. Active workflows will continue to process.

Does OneTrust accept messages under any circumstances?

Event messages are always recorded regardless of a halted or open state. The difference is when the workflow is in the halted state messages are directly sent to the Message Container without execution since the workflow will knowingly fail.

Event messages are naturally lost if the workflow is deactivated.

How long are messages held in the Message Container when a workflow is halted?

Messages are held in the below app environments for 14 days. All other environments will hold messages for 7 days.

  • app-apac

  • app-au

  • app-br

  • app-de

  • app-eu

  • app-prod

  • app-uk

If we have two workflows with same trigger event (e.g., Consent Updated), one of the workflows will be in the halted state and the other will be active. What happens when the event occurs in this case? Does the active workflow consume the event message as a result of the second workflow never triggering if it the prior is fixed and reactivated?

Individual message events are created per workflow. The active workflows will continue processing, while the halted workflow will have its messages delivered to the Message Container after following the standard halting and retry logic attempts.

What errors does OneTrust not attempt to retry for individual actions in a workflow?

OneTrust Integrations retries on network errors and all HTTP errors except those resulting from a redirect as server-side redirects are disabled for the application.

Halting & Errors Use Case

Assume there is an external system we are integrating with, and it goes down for six hours. What is the proper course of action?  

We will receive ten messages for that system. The first five messages will fail (as the system is down), and the workflow will be halted. We will then see five failures in the window of the last ten executions.

Messages six through ten will go to the Message Container directly because the workflow is halted. The first five messages will be retried three times, then sent to DLQ. No messages will be lost; however, these will have to be moved back from the Message Container manually.