← All writing

Turning OneTrust Integration Workflows Inward: Automating OneTrust With Itself

·7 min read·

Almost every Integration Workflow you have ever seen points outward. Consent flows to a marketing platform, a DSR fans out to source systems, a preference change lands in a CRM. The mental model everyone carries is that the workflow engine is a pipe from OneTrust to somewhere else.

That model is holding you back. An Integration Workflow can call any API it can authenticate against. OneTrust exposes a large public API. Put those two facts together and the conclusion is straightforward but rarely acted on: you can point a workflow back at OneTrust and use it to automate OneTrust itself.

Once you see the engine as a general-purpose automation runtime rather than an export mechanism, a lot of manual, repetitive privacy-operations work becomes automatable without any external system involved at all.

The mental model shift

An Integration Workflow is, at heart, a trigger, some conditional logic, and one or more HTTP calls. Nothing about that requires the HTTP call to go to a third party. OneTrust’s REST API is just another endpoint, reachable with an OAuth token, and the workflow engine is perfectly happy to call it.

So the pattern is: something happens in OneTrust, a workflow reacts to it, evaluates some conditions, and calls back into OneTrust to take an action. No middleware, no external platform, no scheduled script running on a box somewhere. The automation lives inside the product it is automating.

The mechanism

Calling OneTrust from a workflow is the same as calling any external API, with three parts to set up.

Authentication. OneTrust’s API uses OAuth2 client credentials. You create an API client, grant it the scopes it needs, and the workflow exchanges the client credentials for a bearer token at the token endpoint:

POST https://app-uk.onetrust.com/api/access/v1/oauth/token

Grant the client the least privilege it needs. For the example below, which writes a subtask, that is the DSAR write scope and nothing more. Do not hand a workflow client blanket access it will never use.

The call. From there it is an ordinary authenticated HTTP request step, with the bearer token in the Authorization header, pointed at whichever OneTrust endpoint does the job.

The trigger. The workflow fires off a OneTrust event, and the triggering object’s data arrives as workflow context you can branch on. For a Privacy Rights request, that means the request reference, its type, subject details and so on are available to your conditional logic without a single extra call.

The exact regional hostname matters. UK tenants use app-uk.onetrust.com, EU tenants app-eu.onetrust.com, and so on. Use the one for your tenant.

Worked example: a manual DSR subtask, only when it is actually needed

Here is a real scenario. Most data subject requests in a given workflow can be fulfilled automatically. A minority cannot, because they touch something that genuinely needs a human: special category data, a request flagged as complex, a particular jurisdiction, a specific system with no automated connector. For those, and only those, you want a manual subtask created and assigned to the privacy team. For everything else, you want the request to sail through untouched.

Done by hand, that is a person reviewing every request to decide whether it needs a manual step. Done with an inward-facing workflow, the review becomes a condition and the subtask creation becomes an API call.

The decision. The workflow is triggered when the request reaches the relevant stage. It inspects the request context it was handed and evaluates whether manual handling is required. That test is yours to define; it might be as simple as a flag on the request or as involved as a combination of request type, data categories and jurisdiction. Expressed as a guard, it is just a boolean:

<#assign needsManualReview = request.involvesSpecialCategoryData
  || request.jurisdiction == "restricted"
  || request.type == "COMPLEX">

If that resolves false, the workflow does nothing and the request continues automatically. If it resolves true, and only then, the workflow proceeds to the next step and calls the API.

The action. OneTrust exposes an endpoint specifically for adding a subtask to a request:

POST https://app-uk.onetrust.com/api/datasubject/v2/requestqueues/{requestQueueRefId}/subtasks

The requestQueueRefId comes straight from the trigger context, so you are acting on the exact request that fired the workflow. The body describes the subtask. The two fields that matter most for this use are type, set to MANUAL to create a human task rather than a system one, and required, set to true so the request cannot be closed until someone deals with it:

{
  "taskName": "Manual review: special category data",
  "description": "This request references special category data and must be reviewed manually before fulfilment.",
  "type": "MANUAL",
  "required": true,
  "assignedTogroup": true,
  "groupName": "Data Privacy Team",
  "commentRequired": true,
  "resolutionRequired": true
}

assignedTogroup with a groupName routes it straight to the right team rather than an individual, and commentRequired with resolutionRequired forces whoever picks it up to record what they did and why, which is exactly the audit trail you want on a manual privacy decision.

That is the whole automation. A review that used to happen in someone’s head, on every single request, now happens only when it needs to, creates a properly routed and audited task when it does, and leaves everything else alone.

If you would rather not hand-build the body, there is also a template variant, POST .../subtasks/template, which lets you define the subtask once as a template in OneTrust and have the workflow reference it. For anything you create repeatedly, that is the tidier option and keeps the wording out of your workflow.

What else this unlocks

The subtask case is one instance of a general capability. Anything the OneTrust API can do, an inward-facing workflow can do in reaction to an event. A few that come up often:

  • Auto-assigning or re-routing requests based on their attributes, rather than a person triaging a queue.
  • Moving a request to the next stage automatically once a condition is met.
  • Enriching a request or assessment with data pulled from another OneTrust module.
  • Closing out system subtasks programmatically when an external condition clears.

The common thread is the same each time: react to an event, decide with conditions, act via the API, all without leaving OneTrust.

Caveats worth respecting

This is a supported use of supported APIs, but a few things will bite if you ignore them.

Beware the loop. This is the big one. If a workflow is triggered by a change to a request and then itself changes that request, you can re-trigger the same workflow, and now you have a loop that creates subtask after subtask. Design the trigger and the action so the action cannot satisfy the trigger, or guard against re-entry explicitly. Think this through before you switch it on.

Make it idempotent. Workflows re-run. Halted executions get reprocessed, retries happen. If your workflow fires twice for the same request, you do not want two identical subtasks. Check whether the subtask already exists before creating it, or design so a duplicate is harmless.

Mind the rate limits. The API is rate limited and returns a 429 with a Retry-After header when you exceed it. That is fine for occasional event-driven calls, but if you are reacting to a high-volume event, respect the backoff rather than hammering through it.

Least privilege on the client. The API client the workflow uses should hold only the scopes the automation requires. A workflow that creates subtasks needs write access to DSAR objects and nothing else. Scope creep on an automation credential is a risk that quietly accumulates.

Token handling. The workflow needs a valid bearer token for each call. Configure the credential as a managed connection rather than pasting a static token into a step, and let it refresh properly.

The takeaway

The moment you stop thinking of Integration Workflows as an export pipe and start thinking of them as an automation engine that happens to sit inside OneTrust, a whole category of manual privacy-operations work opens up to automation. The API is there. The trigger is there. The conditional logic is there. Pointing it inward is mostly a matter of realising you can.