Utilising OACI Matrix in Elements (A106)
Designing your own OACI matrix
Before you move on to documenting your metadata stakeholders, you need to decide and design how you will utilize the OACI matrix in your Org.
Click to open Learning Objectives
LO1-1 Apply stakeholder tags on selected nodes
LO1-2 Construct stakeholder matrix for one of the standard objects
Not all roles need to be used and you can choose what they mean to your governance model.
Click to open illustrative example
How you utilize the OACI model may depend on your organization’s size and team structure. Consider the following:
Zenalpha is a huge, global organization with a team of 70 administrators and developers overseeing an Org for 50 000 users.
Those 70 people are grouped into separate teams responsible for different areas of the Org.
That is why they use ‘Owner’ role to specify which team member is responsible for changing which objects and fields.
Zengamma is a much smaller organization with a team of 5 administrators overseeing an Org for 500 users.
The Org is too big and requests too many to divide it into spheres of influence for different admins.
That’s why they do not utilize the ‘Owner’ role in their matrix and just rely on ACI.
How you utilize the OACI model may also depend on your organization’s regulatory and technical landscape. Consider the following:
Zenalpha specifies which users need to ‘Authorize’ changes to specific fields, reports, dashboards and automations that touch financial data as required by The Sarbanes–Oxley Act of 2002.
Any system software release is coordinated with the training team and hence there is no separate need to ‘Inform’ anyone about changing certain components.
Zengamma has an Org integrated with many other external systems.
The technical architect is marked as ‘Authorizer’ on all fields and objects that are used in external integrations to ensure data flows between systems aren’t compromised.
To ensure relevant teams are aware of planned changes, all objects and fields are tagged with relevant people that need to be ‘Informed’ of coming changes.
The above example illustrates that the use of OACI operators is dependent on what is most appropriate for your business. Only use those which are necessary and important. Some changes need to be consulted and approved in a thorough process, others may only need cursory input by those involved.
When designing your responsibility matrix ask yourself…
What do you expect to happen when an admin or a developer comes across metadata?
What sort of action are they supposed to take when they see an ‘Owner’ or an ‘Authorizer’?
How is specifying who needs to be ‘Consulted’ or ‘Informed’ meant to alter the behaviour?
Answering these questions will help you decide which roles to use and what do they mean for your governance model.
Don’t feel the need to fill out every metadata item, with the full range of OACI roles. You may need to define your own interpretations for these terms.
Specifying stakeholder information
Documenting metadata stakeholders in Elements is extremely easy.
To add a stakeholder, navigate to the right panel in your Org or Reference model. From the first tab, click “Add stakeholder“.
This will open a window allowing you to search for the user you want to add as a stakeholder. You can only add users who are currently a member of the Space – as you type their name or email in, they should show in the dropdown.
Here you can also select which role they have as a stakeholder, and leave a descriptive comment on the nature of this role.
You can add up to 20 stakeholders on any given node. Further information about editing or removing stakeholders can be found in the support article here
Using Stakeholder roles in Elements
The adding of stakeholders, and their roles, can be a key component in other org governance and optimisation processes.
For example, understanding who is responsible for metadata items can support the documentation of your org, as it will be clear who can make decisions, edits, and who is responsible for recording both the improvement planning, and process documentation within that item.
Learn a great deal more about this in our course on Documenting your Org, after you complete this course.
Click to reveal course link
Documenting your Org , opens in new window.
What’s next
Next, you will take a short, theory and practical quiz. Select it from the menu below.
This quiz will help you to recognise the skills and knowledge you have gained, and identify any areas you still need to explore and learn.
Remember, you can revisit these pages, or ask us for help if you get stuck. Once you pass the quiz, click “Next Module” to move on to Module 3.