OneTrust is an extremely powerful program that exists across nearly every domain of the Alterra network. Even a small change can create a domino effect that can very easily disable business-critical components such as single sign-on (e-commerce), as well as any and all analytics tracking. Those are real examples of things OT has broken in the past.
There is no preview state or sandbox environment currently enabled for most OneTrust changes.
Be Careful.
Key Stakeholders:
Testing Group:
Alterra: Jonathan Meier, Kiyono Ames, Miriam Schachtman, Andy Villas,
85SIXTY Team: Mahesh Reddy, Patrick Heavey
. Schedule a time at the beginning of the work week, never the end of it. This ensures that the change does not interfere or conflict with any other web development, and in the eventuality of a problem occurring with the publishing there will be the maximum number of staff available to help diagnose and redress the issue.
Any change in OneTrust must be vetted by the Legal Department and the Digital Team before any work is done within OneTrust.
OneTrust Modules & Sections RACI Chart
Section/Module
Legal Team
85Sixty
Digital Team
Section/Module
Legal Team
85Sixty
Digital Team
1
User-Facing Copy
Consulted
Informed
Responsible, Accountable
2
Geolocation Rules
Responsible, Accountable
Informed
Consulted
3
Front-End Styling (Banner and pop-up colours & logos)
Informed
Informed
Responsible, Accountable
4
Cookie Categorizations
Informed
Consulted
Responsible, Accountable
5
Privacy Rights Automation
Responsible, Accountable
Informed
Informed
6
User and Groups Access Management
Accountable
Informed
Responsible
7
Cookie Consent
Responsible
Informed
Accountable
8
Domain/Subdomain Assignments
Informed
Consulted
Responsible/Accountable
There are no rows in this table
Step 1. Build Safeguards
Wherever possible, check the Version # that OneTrust is currently on and make a note of it. If there are any issues that arise after publishing a change, this is the version you will want to return to.
If modifying an existing rule or template, make a copy of the current version and modify the copy. Keeping the current functionality intact is an important way to safeguard against unexpected errors, and can be a valuable resource in diagnosing any unwanted behaviour after a change.
Step 2. Publishing
Make your changes one at a time. For example; if you are editing multiple geolocation rules, make the edits to one rule, then publish, then test. Once testing has concluded satisfactorily, continue with the next change to the next geolocation rule.
Every change needs to be tested. Seemingly superficial changes, even something as small as modifying the colour of a button on a pop-up template, can have unexpected effects.
All Publishing should be done early in the week, preferably Monday morning.
Every Published change needs to be posted in the 85sixty-alterra Slack channel with a short overview or a link to a Jira ticket.
Step 3. Testing
Test twice. A testing session should be scheduled with the Testing Group before any development is undertaken. The change should be going live immediately before the group runs the first tests.
The OneTrust cache can take up to 4 hours to refresh. After 4 hours has elapsed from the time of the change published the testing group needs to run another set of tests.
Priority QA Tests
OneTrust Assigned Domains & Domain Blacklist
Want to print your doc? This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (