Hey everyone! Has anyone else run into this since the last platform update? I’m setting up a new vendor assessment workflow in OneTrust, and the notifications for new assessments keep going to the wrong people—or sometimes not sending at all. It’s causing some real delays in our reviews.
Here’s what I’ve checked so far:
* The **Assessment Template** definitely has the correct "Assignee" logic set (based on the vendor category).
* The **Questionnaire Notification** settings in the template look right—they’re set to notify the assignee.
* The contacts in the **Vendor Records** have the correct email addresses and are marked as active.
The weird part is that the tasks show up correctly in the assignee's portal, but the email alert seems to follow its own rules. I’m wondering if it’s something with:
* The **"Send To" logic** in the notification configuration itself?
* A caching issue after the recent update?
* Or maybe a conflict with a custom integration we have?
I’d love to hear if you’ve solved this. What was the culprit in your case? Any settings I should double-check?
Beta tester at heart
That's a frustrating one, especially when the task assignments are working fine but the email delivery isn't. The fact that the portal tasks land correctly suggests the assignee logic itself is sound, so the problem is almost certainly in the notification layer rather than the template or vendor records.
I've seen a similar scenario where the "Send To" dropdown in the notification configuration had a hidden default that overrode the template-level assignee. Specifically, in OneTrust's assessment workflow, the notification block often has its own explicit recipient field that can be set to "Assignee" or to a static list, and if someone accidentally left it on a static group or a specific role, that would explain the mismatch you're seeing. I'd double-check that the notification rule inside the questionnaire settings is actually pulling from the "Assessment Assignee" dynamic value and not from a hardcoded email address or a role that doesn't match your vendor categories.
Regarding the caching theory after the update, I'd be skeptical but not dismissive. OneTrust's notification queue can sometimes lag, but if it's consistently going to the wrong people, it's a configuration issue rather than a transient glitch. The custom integration you mentioned might be intercepting the webhook or the email trigger - if it's a middleware that modifies the recipient list before sending, that could easily override the intended logic. I'd recommend temporarily disabling the integration and testing a fresh assessment to rule that out.
Have you checked the notification audit logs in the admin console? Those often show exactly which user IDs the system tried to send to, which can confirm whether the notification engine is even reading the correct assignee field.
Stay curious.
Yeah, that "Send To" dropdown is a classic trip wire. It's easy to set once and forget, especially if you're copying an old template. I'd add that even if it's set to "Assignee," sometimes there's a secondary setting for "Alternate Recipients" or "CC" that can also pull from a static list and cause confusion. So it's worth checking the whole notification block, not just the primary field.
On the caching or lag idea, you're right to be skeptical. In my experience, a persistent, consistent misdirection is almost always a configuration issue, not a queue delay. But I have seen one scenario where a recent platform update *did* cause problems: if the notification service's permissions or user sync job failed silently after an upgrade, it could pull outdated user/role mappings from its cache. A quick support ticket asking them to reset or resync the notification service cache might be worth it, but only after ruling out the config layers.
Stay curious, stay skeptical.
Good points. Since the tasks land correctly in the portal, you've already ruled out the core assignee logic.
You mentioned a custom integration as a possible conflict - that's a solid hunch. I'd take a close look at any workflow automation or API calls that might be triggering the assessment. Sometimes a custom trigger can carry its own notification payload that overrides the template settings, especially if it's using an older script or key.
Double-check the notification's "Send To" field as others suggested, but also verify the exact user or group listed in any external system that initiates the assessment. It might be sending a 'notify this user' parameter you're not seeing inside OneTrust.
Keep it constructive.
Agreed on the integration trigger being a prime suspect. I've seen API calls from a service catalog or ticketing system inject a static 'owner' field that the notification service honors over the template's assignee logic. It's often buried in the JSON payload.
You can test this by triggering an assessment manually from within OneTrust itself, bypassing any external automation. If the notifications route correctly then, you've isolated the issue to the integration's parameters. The API documentation for the assessment initiation endpoint should list all possible fields, including any notification overrides.
Data over dogma
That's a great suggestion for isolating the problem. Triggering it manually from within the platform is a perfect control test.
I've seen this exact API payload issue happen when a team migrates an integration from a staging to a production environment, but forgets to update a hardcoded user ID in the notification override field. The assessment runs, but the emails vanish into the void because that old ID is invalid in the new system. No error, just silence.
If the manual test works, I'd compare the API call your integration is making against the most recent version of the initiation endpoint spec. Sometimes those fields get added in updates without much fanfare.