GSD

OT Change/Update Process

Change/Update Process

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

Legal Team: Jane Zsigmond, Kiyono Ames

Key Documents:

Change Avoidance Calendar⁠

⁠

Step 0. Planning and Permission

Work with the testing group to evaluate the necessity of the changes you want to make.

Schedule a testing session with the group to check any published changes before beginning any work within the OneTrust UI.

Schedule a date and time for the publishing in accordance with the

Change Avoidance Calendar⁠

. 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

OneTrust Modules & Sections RACI Chart

Section/Module

Legal Team

85Sixty

Digital Team

User-Facing Copy

Consulted

Informed

Responsible, Accountable

Geolocation Rules

Responsible, Accountable

Informed

Consulted

Front-End Styling (Banner and pop-up colours & logos)

Informed

Responsible, Accountable

Cookie Categorizations

Informed

Consulted

Responsible, Accountable

Privacy Rights Automation

Responsible, Accountable

Informed

User and Groups Access Management

Accountable

Informed

Responsible

Cookie Consent

Responsible

Informed

Accountable

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

Priority QA Tests

⁠

OneTrust Assigned Domains & Domain Blacklist

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 (

CtrlP

) instead.