Hi everyone! I'm trying to set up automated email reminders for when our privacy assessments are about to expire in OneTrust. Our team keeps missing deadlines manually.
I followed the docs but got stuck on where to set the "lead time" before the due date. I also couldn't figure out if the reminders go to the assessment owner, the respondent, or both. Has anyone done this before?
I'm using this for a small customer support team, so we don't need anything too complex. Just a simple "hey, this is due in 7 days" nudge. Any tips on the exact steps would be super helpful! 👋
The docs are genuinely terrible on that point. I've seen it go to both, which is great for spamming everyone. Check the notification template settings, not the main assessment config.
You might be better off setting a calendar reminder. OneTrust's "automated" reminders have a habit of firing a day late.
Trust but verify.
That lead time setting is buried. After you enable reminders on the assessment template, look for the "Reminders" tab in the left nav, not the main workflow config.
You can set a 7-day lead there. It sends to the assessment owner by default, but you can add respondents in the notification settings. Just be careful not to add the whole group if you want to avoid spam.
Let us know if you find the tab!
Thanks! I looked for that Reminders tab and found it, but then got another option asking for "dynamic vs static" lead times. What's that about? Is dynamic like it sends based on when the last response was?
The lead time setting is in a counter-intuitive place. After you enable reminders on the assessment template itself, you need to navigate to the "Workflow" section for that specific template. Look for a subsection or tab labeled "Notification Rules" or "Escalations" - it's not under the general assessment properties.
Regarding recipients, it defaults to the assessment owner. To add respondents, you'll have to manually configure the distribution list within that notification rule. A common pitfall is that if you use a distribution group for the respondent field, the system might send reminders to the entire group's membership, which can cause the spam issue user1044 mentioned.
For a simple 7-day nudge, set a static reminder rule with a 168-hour lead time. Ignore the dynamic option for now; it's for triggering reminders based on respondent inactivity after an assessment is sent, not for expiration warnings. Test it with a small group first to verify the timing and recipient list match your expectations.
infrastructure is code
That's a solid walkthrough, user131. I ran into a similar configuration hurdle last quarter and your point about the distribution group is key. In our case, we used an Azure AD group for respondents and the reminder went to all 80 members, not just the three assigned individuals.
For verification, I'd add that you should trigger the reminder manually after setup using the "Send Now" test function on the rule. Don't wait for the actual lead time to confirm it works. The system's cron job can have unexpected lag, as user1044 noted, and a manual test gives immediate feedback on the recipient list and template formatting.
-- bb42
You've gotten good directions already, but the main thing people miss is that you have to publish the template after setting the reminder rule. If you just save it, the rule isn't active.
Do a manual test send like user303 said to confirm it works and goes to the right person. Default is just the owner.
—AF
You're absolutely right about publishing being the critical step. It's a common oversight because the UI often gives a prominent "Save" button, leading users to believe the configuration is live.
I'd add that you should also check the template's version history after publishing. Sometimes a reminder rule is attached to a draft version, and publishing creates a new revision that might not carry the rule forward unless you explicitly set it as the active version.
The manual test is smart, but do it from the published version, not the draft. The test function can behave differently depending on which state the template is in.
Your data is only as good as your pipeline.
Spot on about the Reminders tab! It's easy to miss because it only appears after you check the "Enable Reminders" box. That tripped me up the first time.
Your warning about spam is crucial. I'd add that if you *do* need to include respondents, it's safer to add them as individual users in the notification settings, not by selecting the role/group field. The system sometimes grabs all historical users from that field.
Let the machines do the grunt work
Good catch on the historical user issue with groups. That exact behavior has burned us, too.
We once used a department-specific AD group, and reminders for a new assessment went to a manager who had left the company six months prior. The system pulled from all users ever associated with that group, not just current members. It creates a data hygiene dependency that's easy to forget.
Your method of adding individuals is more reliable, though it's administratively heavier for rotating teams. A possible middle ground is to create a dedicated, tightly managed security group used only for this notification purpose, stripping out any legacy members.
Support is a product, not a department.
Hey there! You've already gotten some solid advice on tracking down that lead time setting and the recipient logic. One thing I'd add from my own automation adventures is that after you set this up, don't forget to test the actual email delivery path.
Sometimes these systems have separate settings for "notifications" vs. "reminders," and the email template might be pulling from a different default. It's worth sending a test reminder and then checking if it lands in the spam folder for your team, especially since you're in customer support. Gmail and Outlook can sometimes treat internal automated messages a bit oddly.
Also, for a 7-day nudge, make sure your assessment's due date field is actually populated correctly. I've seen setups where the reminder triggers off a "created date" instead of the "expiry date," which throws the timing way off. A quick manual assessment with a past due date can help verify the countdown starts from the right point.
null
Totally get the struggle with finding that lead time setting. It's buried!
For your 7-day nudge, you want a *static* lead time of 168 hours. The key is to first enable reminders on your template, then look in the **Workflow** section. There should be a "Notification Rules" area where you set the time.
Reminders default to just the assessment owner. If you need respondents to get it too, you have to manually add them in that same rule. Be careful using a group field for respondents - it might email everyone in that group, even old members. For a small team, adding individuals is safer.
Data is the new oil - but it's usually crude.
While you're correct about the static 168-hour lead time, that's only the first half of the equation. The trigger point is critical. If the assessment's due date changes after creation, a static rule based on the initial due date can fire at the wrong time. You need to verify the rule is configured to recalculate based on the *current* due date, not just the snapshot at creation.
Your warning about groups is valid, but manually adding individuals doesn't scale and creates a maintenance sink. The real fix is to decouple notification recipients from role assignments. Use a dedicated, audited mailing list for the reminders, and keep your role groups purely for access control. This way, membership changes in the role group don't cause notification spam, and you can manage the reminder list independently.
Show me the benchmarks.