How to Build Your OACI Governance Model (A106)

Planning to build your Governance model

Documenting stakeholders one by one in Elements may seem like a daunting task. Fortunately, you can generate a template file to fill out and then re-import into Elements for mass-update. 

But before you get into mass-updating thousands of metadata components, plan a phased implementation to get accurate and useful data.

Below is the recommended best practice for gradually building up your Org’s full metadata assignment matrix.

Start with objects

Start with Objects as they are the most relevant metadata to your business. Also, Objects, unlike fields, are much easier to remember and identify by business stakeholders.

While ideally you would want to have full visibility of business stakeholders on all Objects, you do not have to aim that high to start with. Some Objects may be more important than others, or you might be planning a big project that is likely to involve changing a specific set of Standard and Custom Objects in your Org. Hence why you might want to start with just the ones that are going to be customized more often or sooner. 

There are two distinct ways you could go about identifying which Objects to document. You could rely on stakeholder’s usage perception, or use the actual usage data from the elements platform.

1) Perception of Metadata use

One component of stakeholder information gathering is perception data. Consult the business leaders and operational areas of your business about the Objects they use most frequently, 

Once you have their responses, you have a list of which business unit uses which Objects. But we don’t know which fields are actually used when, and by whom. This is also a good point to recognise the objects that are used extensively between business units or shared between them. For instance, an Account object can be heavily used by sales, customer success, finance and product alike.

Pros: 

• Business stakeholders are asked to identify Objects they are interested in directly
• This allows you to engage them in building the Governance model with you
• They can identify obscure Objects that could be easily missed

Cons: 

• It is easy for business leaders to forget some Objects, especially if there are many being utilized by a particular team
  

2) Usage Analytics for Metadata use 

Using Org analytics you can find and explore the most used objects. When investigating those Objects individually you can also see how the number of records grows over time by different record types. 

You can then use this data to ask business stakeholders specific questions about if and how they use the most populated Objects. This method allows you to identify Objects where demand can be most easily met, and impact most quickly felt. 

Pros: 

• You can engage with business stakeholders about specific Objects as opposed to relying on them to remember which ones they actually use.

Cons: 

• Objects that are most populated with data do not necessarily have to be populated by end users – or even store the most important business data. 

Move on to Fields

Fields are the key Salesforce metadata. All automations, data visualisations, reporting and integrations rely on fields. Regulations and policies dictate how certain data needs to be configured or presented – which affects how fields need to be configured. However, before you document stakeholders on individual fields you need to decide and design what is the governance model. 

The most established approach is for the fields to inherit the stakeholders from the parent Object. If the Head of Sales needs to authorize changes to the Opportunity Object, it is very likely they would want to approve any changes to existing fields. The easiest thing to do would be therefore to copy and paste the relevant stakeholder onto the child fields in the stakeholder template file. 

Now use the steps and template from the previous steps above to document the status of these most important metadata stakeholders, and then re-import into Elements for mass-update. 

For Objects that have many business stakeholders (e.g. Account) it is almost certain that different business units rely on and use different fields. The finance team is not likely to care about the same scope of data as the sales team. Therefore it is an opportunity to dig deeper with different business units to understand what fields they actually care about and why.

Best practice – Document Automations as well

The purpose of building and documenting your responsibility matrix is to ensure that any system changes that may have significant operational or regulatory impact are consulted or approved by relevant business stakeholders. 

However, a field that has strong regulatory impact may be affected by changes to other metadata, not just to the field directly. 

To ensure you get the most value from utilizing the OACI matrix, we recommend that you extend the stakeholders documented on fields to automations that utilize those fields. That way you can ensure nobody changes an automation without understanding the operational or regulatory impact. 

First, download the dependency set for your Org. Then generate a report on your Org’s stakeholders. You can combine both in a spreadsheet. Then you can identify all process builders, flows, apex classes, workflow rules and other automations that touch fields that require authorization for change. 

Generate a new stakeholder template file for the selected types of automations. Using the analysis done before, document stakeholders on relevant flows, process builders, apex classes etc. Then import that file to mass-update your automations with relevant stakeholder information. The following animation shows you where and how to mass update your stakeholder metadata, and how to generate the template file. 

As we saw in the module related to reducing risk, if an automation is proposed to be changed, it is easy to alter or read the stakeholders on vital fields related to that automation, who should be referenced alongside the object and fields.

In addition, this works both ways. So any proposed changes to a field or object will now also show the automations affected, and the stakeholders reliant on those automations.

Keeping your OACI model up to date

It is unlikely to document your entire Org and all its metadata with accurate stakeholder information all at once. Furthermore, it might not even be necessary. 

To keep enriching your governance model and stakeholder information your team should get into the habit of documenting stakeholder information on metadata during your design and development processes. Any new field, object, automation, or any significant changes to existing configuration, should result in documented stakeholder information (who requested it and why, who will end up using it and why, who built it etc.)

And that is the foundation of your knowledge and understanding needed to build your OACI governance model.

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 “Mark as completed” to complete the course.