---
title: "Triggering OneTrust Collection Points Programmatically"
canonical_url: https://ot.webclat.com/guides/trigger-onetrust-collection-points
description: "A collection point doesn't have to be a static embedded form - triggering it from your own application code puts purpose-specific consent prompts exactly where the user journey calls for them."
source: Webclat | OneTrust Solutions (OneTrust partner, independent consultancy)
---

# 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

- [Responding to consent state changes without polling](https://ot.webclat.com/guides/respond-to-consent-state-changes)
- [Multi-profile consent management for multi-brand and multi-region sites](https://ot.webclat.com/guides/multi-profile-consent-management)
- [DSARs handled without drowning the team](https://ot.webclat.com/use-cases/dsars-without-drowning-the-team)

Contact: ot@webclat.com | (813) 694-4451 | https://ot.webclat.com/#contact