02 · Partner steering & governance
Salesforce partner governance for multi-vendor programmes
When several implementation partners work on one Salesforce org, every partner delivers its part and nobody owns the whole. I set up one common governance and release framework on the client side and review what partners deliver, before it gets expensive.
Book a call (opens Microsoft Bookings in a new tab)Typical situation
- Several partners and internal teams work on the same org, and changes overwrite each other because nobody coordinates who deploys what and when.
- Nobody has defined which team owns which processes, objects and metadata.
- Similar problems are solved in very different ways, depending on which partner built them.
- Partner deliveries are accepted without a technical review, and problems show up in UAT or production.
- Repository, pipeline or backlog sit with one partner, which makes it hard to compare or replace partners.
What I do
- Governance and release framework that applies to every partner and internal team
- Development and architecture standards, from naming conventions to rules for automation and test coverage
- Object ownership matrix: which stream is responsible for which object and its metadata
- Pull request reviews on the client side, including technical review of partner deliveries
- Center of Excellence format to agree on standards and upcoming changes across streams
- Onboarding of new partners into a documented setup
- Handover of the process to an internal colleague
What you get
- Written standards that every partner follows and that reviews enforce
- Clear ownership for processes, objects and metadata across all streams
- Comparable partners, because they all work by the same rules
- Repository, pipeline and tools owned by the client, not by a partner
- An internal owner who runs the process after the handover
How we work together
- 01
Assessment
I look at how the teams actually build today: repository, deployments, pull requests, ownership and the main conflicts between streams.
- 02
Framework and standards
Together with the teams I write down standards, the object ownership matrix and the review rules. The first version covers most cases, edge cases follow.
- 03
Reviews and Center of Excellence
Every change goes through a pull request with review. Regular Center of Excellence calls raise new topics early, with enough lead time for all streams.
- 04
Handover
Once the process runs, I hand it over to an internal colleague and train them, so the client owns governance long term.
Partner governance on the client side is what keeps a Salesforce programme with several implementation partners in control. It means one set of standards, clear ownership for every object and process, one release process and someone who technically reviews each delivery before it moves on. Without it, every partner optimises its own scope, and the client pays for the conflicts between them. I take on this role as an independent architect, without ties to any vendor or partner.
What does this look like in a real programme?
The largest programme I steered had more than 30 developers in eight streams, delivered by five implementation partners plus internal teams. At the start, nobody had clearly defined who led which processes, objects and metadata. Changes overwrote each other, and the technical approaches of the teams had drifted far apart.
The first step was simple and effective: every change went through a pull request with a review, and for a while every single one crossed my desk. From those reviews we wrote down standards. They covered the usual topics, such as naming conventions, one automation per object and context, and test coverage. Two elements made the biggest difference:
- An object ownership matrix, which defined which stream was responsible for which object. Before a team changed an object it did not own, it had to coordinate with the owner.
- Rules for configuration, for example which values belong in custom metadata types or custom labels instead of being hardcoded.
It took about three months until the standards were stable. The first version covered roughly 80 percent of the cases. New edge cases came up over the following weeks. We addressed them in regular Center of Excellence calls, where upcoming changes were raised with enough lead time for all streams. After a while the edge cases disappeared, because topics came up before they turned into conflicts. Once the process ran smoothly, I handed it over to an internal colleague who now owns it.
Why does governance belong on the client side?
A partner can write good standards. But if one partner owns the rules, it also decides how every other partner builds, including its competitors. The same applies to the repository, the pipeline and tools like Jira or Miro. I explain this in more detail in why clients should own their DevOps tools.
When the client owns the standards, the review rights and the tools, partners become comparable. A new partner can be onboarded into a documented setup, and a partner who leaves hands over nothing but their user accounts. That is also the basis for a fair comparison of offers and for honest conversations about quality.
How do reviews fit in without slowing the programme down?
Reviews are the instrument that turns written standards into daily practice. They work when pull requests are small, response times are agreed and the repeatable checks are automated in the pipeline. I describe the details in why pull request reviews are a must in enterprise projects.
Partner governance works best together with a solid release process, which is why it usually goes hand in hand with DevOps and release management. If your programme has several partners on one org and you want a second opinion, send me a message or read more about me.
Frequently asked questions
What is Salesforce partner governance?
It is the set of rules, roles and reviews that makes several implementation partners work on one Salesforce org in the same way: shared standards, clear ownership of objects and metadata, one release process and a technical review of every delivery.
How long does it take to establish standards across several partners?
In my largest programme it took about three months. The first version covered around 80 percent of the cases; the remaining edge cases were added step by step until new topics were raised early in Center of Excellence calls.
Why should the client, not a partner, own governance?
If one partner sets the rules, it decides how all others build, including its competitors. When the client owns standards, repository and approvals, partners stay comparable and replaceable.
What is an object ownership matrix?
A simple table that defines which stream or team is responsible for each Salesforce object and its metadata. It prevents two teams from changing the same object without coordination.