Triggering OneTrust collection points programmatically
What it is
A OneTrust collection point is a defined moment for capturing a specific kind of consent or preference - a newsletter opt-in, a purpose-specific consent inside a product flow. Triggering it programmatically means invoking that collection point from your own application code at the moment it's actually relevant, rather than only ever presenting it as a static embedded form a visitor happens to land on.
When you need it
You want a preference-center flow embedded inside a logged-in application, not just a standalone page a visitor has to navigate to separately.
You need to capture purpose-specific consent at the exact moment a feature requires it - prompting for marketing consent when someone starts a checkout, for example, instead of on every page load.
Your application needs to read back a collection point's submitted state to update its own product logic, not just record the consent choice in OneTrust and move on.
How to implement it
- 1
Identify the collection point ID already configured for the purpose you need
Confirm the collection point exists and is configured correctly in OneTrust before wiring a trigger to it - this is a lookup against your existing OneTrust configuration, not something the trigger call creates on the fly.
- 2
Call the trigger from the application event that should surface it
Fire it from a specific user action (a button click, entering a specific flow) rather than on page load, if the goal is a contextual prompt rather than a blanket one.
- 3
Handle the trigger's response/callback
Your application needs to know whether the visitor completed the prompt, dismissed it, or already had a valid recorded choice for that collection point - branch your application logic on that outcome rather than assuming completion.
- 4
Check existing consent state before triggering, to avoid duplicate prompts
A visitor who already has a valid recorded choice for a given collection point shouldn't see it fire again - read existing state through whatever method your SDK version exposes for this before deciding to trigger.
- 5
Log the trigger event itself, not just the outcome, for debugging
When a collection point doesn't appear for a specific visitor as expected, having a log of whether the trigger call even fired (versus fired but was suppressed by the duplicate check) is what actually narrows down the cause.
How to verify it worked
Trigger the collection point manually in a test session at the intended moment and confirm it appears then, not earlier or on page load.
Complete the flow and confirm the resulting consent record appears in OneTrust's reporting, correctly attributed to that collection point's ID.
Trigger it again for the same test visitor immediately after and confirm your duplicate-prompt suppression correctly prevents a second prompt.
Related
Want this scoped against your specific OneTrust tenant?
We scope every engagement in discovery, before implementation - no assumptions about your stack.