Reinforcement: making standards stick with partners

Reinforcement is the last stage in the ADKAR model: making sure a change stays. With Salesforce partners it is the hardest stage, because standards erode after a few months when new developers join and deadline pressure rises. They are anchored in three places: in the pipeline for everything that can be checked automatically, in the pull request review for the rest, and in a regular Center of Excellence call where new edge cases are discussed. They only hold for good once an internal owner runs them.

Why do standards erode at partners?

The first introduction of new standards usually goes well. Teams pay attention, the rules are new, and someone looks closely. After a few months three things change:

• New developers arrive. Partners rotate people, and whoever joins the team knows the standards only from a document, if at all.
• Deadline pressure rises. Before an important release an exception is made, “just this once”. If nobody checks, the exception becomes the rule.
• Attention fades. Whoever checked every pull request at the start now has other tasks.

In the ADKAR model what is missing then is not knowledge but reinforcement. An example: if a partner’s developers know the naming conventions but nobody checks them in the pipeline, reinforcement is missing. Another training session changes nothing. Then an automatic check belongs in the release process.

Each lever anchors a different part of the standards

Together the levers leave little room for quiet erosion:

Lever	What it anchors	Who
Automatic check in the pipeline	names, forbidden patterns, test coverage, validation against the target org	runs on every pull request
Pull request review	design, ownership of objects, fit with the architecture	reviewer on the client side
Center of Excellence call	new edge cases, upcoming changes with lead time	technical leads of the streams
Onboarding of new developers	knowledge of the current version	partner, checked by the client
Contract	standards as an acceptance criterion	procurement, programme management
Handover to an internal owner	continuity after the project	client

The pipeline is the cheapest lever, because it never gets tired. Whatever it checks, no reviewer has to comment on any more. Which rules belong in the standards and which of them can be automated is described in Salesforce development standards for several partners.

The Center of Excellence call settles new edge cases

Standards are never finished. New cases come up, such as a stream that needs a field on another stream’s object. Without a fixed place these cases are decided between two developers, and every partner decides differently. A regular call with the technical leads of all streams gives them a place. Every decision there is added to the standards.

The call has a second effect that is almost more important for reinforcement: the technical leads carry the decisions into their teams. A new developer then learns a rule from their own lead, not from a client document. Format and cadence are described in Salesforce Center of Excellence: format and cadence.

How do you onboard a partner’s new developers?

Every change of people at a partner is a small restart. I recommend a short, fixed onboarding that the partner owns and the client checks: the current standards, the object ownership matrix, the path of a pull request through the pipeline and the most important entries in the decision log. A new developer’s first pull request gets a more thorough review than usual, so misunderstandings show up early. That costs half a day and saves weeks of corrections. The more often a partner rotates people, the more it pays off, which is why onboarding belongs in the agreement with the partner as a duty.

Exceptions under deadline pressure need a reason and a ticket

There will be exceptions. What matters is that they are visible. An exception to the standards needs a reason in the pull request and a ticket that plans the correction in the next release. That way the exception stays an exception. If exceptions pile up for one rule, the rule belongs in the next Center of Excellence call: either it does not fit, or the plan leaves too little time.

What belongs in the contract?

A contract does not replace a review, but it makes clear what applies. I recommend referring in every partner contract to the current version of the standards held by the client, not to a copy in an annex. Then every change from the Center of Excellence call applies without new negotiation. And a delivery that breaks the standards is not accepted. The same applies to AI-generated code, see partners using AI coding: what belongs in the contract.

How do you know standards are anchored?

Three signs show it. Reviewers comment on the same points less often, because the pipeline finds them first. New edge cases come to the Center of Excellence call before they are built, instead of afterwards as a conflict. And a partner’s new developers follow the rules without anyone explaining them one by one. In my programme the edge cases eventually disappeared, because topics were discussed before they turned into conflicts.

Count the review comments that repeat

Look at the review comments of the last two months and count which remarks repeat. Every remark that can be checked automatically goes into the pipeline, with a clear error message that names the standard. Typical candidates are naming conventions, hard-coded IDs and fields without a description; Salesforce Code Analyzer or a custom rule in the pipeline finds them before a reviewer does. For the rest, set up a fixed call with the technical leads. And plan from the start who on the client side takes over the standards when the project ends. How I set this up with several partners is described under partner governance.