You are reading a guide that explains how to build up your organization's Operational Knowledge. This article covers how to accomplish stage 1 in operational knowledge maturity scale.
Why capture stakeholders against metadata?
Operational knowledge is achieved when systems and their configuration are so well understood that we can pin point which business processes are supported and enabled through specific features in our systems.
However, that level of change intelligence is achieved at stage 3 in operational knowledge maturity and usually takes some time to build out.
Capturing business stakeholders against your system metadata is much faster and can be accomplished very quickly. While it does not tell you why we use certain features, it does help you pinpoint people who know.
Use-cases
There are two main use-cases for wanting to document your metadata stakeholders.
Documenting stakeholders for operational knowledge capture
Documenting stakeholders for operational knowledge capture
When you eventually want to start mapping out your business process diagrams to document your current 'As-Is' state of operations, or 'To-Be' future enhancements, the list of metadata stakeholders will help you gather the list of all essential knowledge holders for different areas of the business.
Read here on how to capture your business process knowledge.
Documenting stakeholders for agile, non-invasive change governance
Documenting stakeholders for agile, non-invasive change governance
Changes implemented without consulting business stakeholders can lead to misalignment with business objectives or stakeholder expectations. They can also result in disrupting business operations, especially if the stakeholders are not educated in advance.
However, business stakeholders are busy people and they don’t want or need to be consulted on every single change. Too much bureaucracy can also kill agility - imagine you want to change some fields on the Account object, which is used by sales, marketing, product and finance departments. You can’t call the committee every time you want to make any change there!
The reality is that even when the same system (like Salesforce) is used by multiple departments, not all features are relevant to all of them. Consider the example below:
Even the Opportunity object, arguable the most important object for the sales teams, is not used exclusively by them. Nor is all information captured on it of equal importance to the sales team.
Some attributes and information are used by finance or sales ops teams for forecasting, other by marketing teams to evaluate effectiveness of their campaigns and contribution to the overall pipeline.
By documenting stakeholders at the metadata level, you can ensure that the right changes are always cleared with just the right stakeholders.
Elements automatically flags when stakeholders need to be consulted when a new story is raised against target metadata component.
Implementation Guide
Prerequisites
In order to follow this guide you need:
Salesforce Metadata Management license
Synced Salesforce Org into Metadata Dictionary
We advise to sync your Production Org or Full Sandbox Org, as this will allow you to conduct steps 1 & 2 of this guide.
If that is not possible for some reason, you will have to skip straight to step 3. This is possible, but you won't be able to use your Metadata Dictionary's insights to identify key metadata or knowledge holders. But if you feel confident in your personal understanding of your Org's stakeholder dynamics and most used capabilities, it is fine to skip the first two steps.
Step 1: Identify key objects to the business
An average Salesforce Org synced by Elements has nearly 300 standard objects, over 230 custom objects, and over 18 different managed packages. Not to mention, hundreds of automation flows.
So while as an admin or platform owner you know your Org very well, chances are you don't know exactly all the areas that are and aren't fully adopted.
You can create a dynamic, custom view of metadata of all of your standard, custom, and managed objects and make sure it includes following attributes:
Name
Full API name
Record count
Description
Last created record date
Last modified record date
You can then filter that list, or export it, to find objects that are and aren't being used in your Org.
Consider tagging or classifying them as 'Important' or 'NotUsed'. You can then amend the custom view of metadata to include the 'tags' column and filter to show only those objects that are used and important to the business.
Step 2: Identify who uses, built and knows the metadata
Knowledge holders are not just business stakeholders. While they might know what their teams use and don't use and why, in order to understand how your automations or other areas of the Org actually work, it is best to consult the architects, admins or developers who built the components.
These are people you might want to document as 'people to be consulted' whenever further enhancements are planned for that area of the Org.
Create a custom view of metadata with last modified by attribute to reveal the last person to work on the metadata.
Step 3: Document metadata stakeholders in a spreadsheet
Your Org is big and complex, and documenting relevant stakeholders one by one may seem dreadful, even if you would want to do this just for the key objects (never mind the fields!) Fortunately, with Elements you can document stakeholders for your entire Org VERY easily.
Consult this feature article on how to export a CSV file of your Org configuration, limited to desired scope of metadata (e.g. only objects and fields), so you can mass-document stakeholder information.
You can use your own personal knowledge and findings from steps #1 and #2 to document your metadata stakeholders as either:
Owner: Responsible for the overall management and integrity of the metadata.
Authorizer: Grants permissions and approves changes to the metadata.
Consulted: Provides input on metadata changes but does not have final authority.
Informed: Receives updates about changes but does not participate directly.
If you define your stakeholders on the object-level, it is a good practice to copy-paste the same ones on child fields UNLESS the object is shared across departments and different fields are relevant to different business units (in which case consult the use-case #2 above)
Step 4: Review the list with stakeholders
It is a good practice to share the documented spreadsheet with the stakeholders. Filter it to only show metadata related to them. They will be able to quickly scan objects and fields they are responsible for or need to be consulted on. If anything is missing, they are likely to notice.
Step 5: Document / import
With a file that has been consulted and approved by all relevant parties, you can now import the file back into Elements.
Why import stakeholder information back to Elements if it already exists in a spreadsheet?
Salesforce Metadata Dictionary in Elements is your central knowledge hub, combining automated insights, planned and delivered changes, manual documentation, and others. Stakeholder information is an important part of the puzzle.
Anything that is documented in Elements becomes visible for the metadata component in context in Salesforce Setup whenever someone wants to change a component.
Stakeholder information documented on metadata in Elements feeds into impact assessment insights.
Read this support article on how to import stakeholder information into your Org.
Step 6: Correct/ change stakeholder
When you need t add or remove another stakeholder from a metadata component, you can simply do it from within the Elements UI.
Limitation: currently there is no way to mass-replace or mass-remove a stakeholder from metadata. This is being worked on urgently.