How to Pause a OneTrust Integration Workflow Without Losing Events

This is the first in a short series on the gaps in OneTrust’s integration platform and the workarounds we have built to live with them. To be clear about the spirit of it: OneTrust Integration Workflows do a lot well, and the platform keeps improving. But if you run real integrations in production you eventually hit things it does not natively do yet. Rather than pretend those edges do not exist, this series documents them honestly and shares the patterns we use to get past them.

First up is one that sounds trivial until you need it and discover it is not there at all: pausing a workflow.

The problem

Sometimes you need to stop a workflow processing for a while, then pick up exactly where you left off with nothing lost. A downstream system is in a maintenance window. You are mid-investigation on a data issue and do not want events flowing until you understand it. You are cutting over a configuration and need a clean gap. In all of these the requirement is the same: hold the events, resume later, lose none of them.

There is no button for this. OneTrust gives you activate and deactivate, and neither does what you want.

Why deactivating is not the answer

The obvious move is to deactivate the workflow. Do not. Deactivating stops the workflow consuming, and the events that would have flowed through it are gone. There is no queue waiting for you when you reactivate. You have not paused anything; you have dropped data on the floor for the duration.

For a consent or preference integration that is not a minor inconvenience. Every opt-out or preference change that lands during the deactivated window simply never reaches the downstream system. That is the kind of gap that turns into a compliance conversation later.

So deactivate is off the table. We need a way to stop processing while continuing to retain.

Prerequisite: turn on the message container

Before any of this works, one setting has to be enabled on the integration: Enable message container. With it on, any messages that arrive while the integration is halted are held in the message container for later reprocessing rather than dropped. This is the mechanism the entire workaround depends on. If it is off, halting the workflow gives you nothing to resume, and you are back to losing data.

You will find it in the integration’s settings, and you can inspect what is currently held via the popover next to the integration name, which is useful for confirming your paused messages really are queuing up.

While you are there, check the setting just below it: Default procedure for reprocessing failed and pending messages. Set this to manual reprocessing. You want the queue to drain only when you deliberately resume, not automatically, or an auto-retry could start draining the backlog before you are ready and defeat the point of the pause.

Enable the container once, on any integration where you expect to use this technique, and leave it on. There is no downside to having it enabled in the normal course of events.

The workaround: break it on purpose

The trick exploits how the workflow engine responds to repeated failures. A deactivated workflow discards what would have queued. Repeated errors, by contrast, push the workflow into a HALTED state, and a halted workflow does not throw incoming messages away. It queues them for later.

The threshold is the part worth understanding, because it is what makes this reliable rather than a fluke. OneTrust watches a moving window of executions: once it sees five failures within any ten executions, it halts the workflow automatically. That is a safety mechanism, designed to stop a genuinely broken integration from hammering a downstream system. We simply trigger it on purpose.

So we make the workflow fail, deliberately, at the very first step, before anything downstream can happen.

FreeMarker gives us exactly the tool for this. The <#stop> directive aborts template processing immediately and raises an error:

<#stop "Paused for maintenance">

Drop that as the first thing in the workflow’s initial step. Every incoming event now hits it and fails at step one. Within a handful of executions the five-in-ten threshold trips, the workflow moves to HALTED, and from that point every further message is queued as pending rather than attempted. The small number of executions that failed while the threshold was tripping are not lost either; they are retained as failed executions. Because you broke it at the first step, none of them did anything partial downstream. Everything is simply parked, failed and pending alike.

The string is just a label. Use it to say why you paused, so that when you or a colleague looks at the halted executions later, the reason is right there rather than being a mystery error.

Resuming

When you are ready, remove the <#stop> line and click Resume on the workflow. OneTrust reprocesses both sets: the executions that failed while the threshold was tripping, and the backlog of pending messages that queued up while the workflow was halted. They were never lost, only held, so they now flow through the real logic as if the pause had never happened. That is the whole point: a clean pause and an intact resume, with no data loss across the gap.

A practical pattern

Rather than commenting the line in and out by hand, it is cleaner to gate it on a variable you can flip, so pausing and resuming is a single controlled change:

<#assign paused = true>
<#if paused>
  <#stop "Paused for downstream maintenance 2026-07-25">
</#if>

Set paused to false to resume. Keeping the reason and a date in the message makes the halted executions self-documenting, which matters when a pause outlives your memory of why you started it.

Caveats worth checking before you rely on this

This works, but it is a workaround using an error mechanism for flow control, so go in with your eyes open. A few things to confirm against your own environment and tenant:

• Retention window. Halted events are held, but confirm how long they are retained and whether there is a limit on how many can accumulate. A pause that runs for days under high volume is a different proposition to a pause that runs for an hour. Do not assume the hold is indefinite.
• Monitoring noise. Halted executions will show up as errors in your operational view and may trip alerts. Tell your ops people the pause is deliberate, or you will spend the afternoon fielding questions about a workflow that is failing exactly as intended.
• Resume behaviour. Verify how the halted events reprocess on resume, particularly ordering and whether every held event is picked up. Test this in a lower environment before you trust it with production consent data.
• Break at the first step, always. The safety of this depends on failing before any side effect occurs. If the <#stop> sits after a step that has already called out to a downstream system, you can leave things half-done. Keep it first.

When to use it, and when not to

This is a good fit for short, deliberate, operational pauses: maintenance windows, investigations, cutovers. It is a control you reach for occasionally and remove promptly.

It is not a queueing system and should not be treated as one. If you find yourself leaving workflows halted for long periods or as a matter of routine, that is a signal the design needs rethinking, not a heavier reliance on the workaround. And because it leans on error-handling behaviour rather than a supported pause feature, keep an eye on it across platform updates; the day OneTrust ships a real pause, this should be the first thing you retire.

Used with that discipline, it fills a genuine gap cleanly.