Developing a Salesforce governance framework

Governance—it’s the important thing your company talks about after experiencing a self-inflicted disruption in day-to-day operations. Whether it was your technical team causing a production error when someone loaded the wrong data file or the reactivation of a defunct record, when accidents happen, they can expose open vulnerabilities in your release management process.

What is governance?

At its core, governance puts a structure in place for organizations to effectively  to everything that controls how your software solutions work. Governance applies to both changes driven from within the business and changes delivered by the software vendor.

For example, Salesforce updates its platform three times a year and a governance strategy would inform how a company evaluates and integrates new functionality to enhance existing processes. Seems simple, right? It can be, but it does takes a work upfront and buy-in across different areas in your organization to do it effectively.

Organizations commonly base their governance processes around online transaction processing systems like Salesforce since these control all of the sales, marketing, support, and finance related activities that help make your company run.

Why is governance important?

In today’s fast-paced business climate, organizations need to quickly adapt to stay competitive. Keeping up with new ways of doing business requires consistent tweaks to how you manage changes in your organization, whether it’s a new system to adopt, a new process to adjust, or a set of data to track. If you want to see some semblance of structure for users to adhere to, you need a governance framework.

A governance framework establishes the overarching vision for a software platform, the overall release management strategy, the stakeholders who are responsible for approving the changes, and the release schedule for how changes will be performed and delivered to users. The governance framework also determines how new change requests will be prioritized to ensure new change requests align with the vision for the software platform, will not conflict with or break existing processes across the organization, and that the work delivered meets the needs of the original request. Finally, the governance framework establishes a process for communication to inform the right people about changes at the right time.

Think of your organization like a ship. Without a skipper at the helm and a line of command, a member of the crew won’t know what to do if they see trouble ahead, if they see a piece of the ship starting to fail, or if they try a risky maneuver without first asking for approval. The same set of structure can be applied to your internal processes and how your organization manages change. Without a solid governance strategy, your systems can erode over time without consistent oversight and refinement.

The benefits of governance

The guardrails established by a governance framework help ensure that changes are delivered consistently, reliably, and without disrupting end users. Having a predictable way for requesting, prioritizing, and delivering changes to business systems promotes greater efficiency, security, and transparency.

Efficiency

IT and business support teams are consistently challenged to do more with less, with leaders keeping a consistent eye on their time to value metrics. Good governance strategies are designed not to slow down the organization, but to help alleviate these pressures on IT delivery teams and enable them to respond faster to business needs. A governance framework focuses limited resources on the most strategic priorities for the business and minimizes wasted time and project fits and starts.

Security

Just like when captains say, “batten down the hatches” when ensuring the security of a ship, organizations need to keep their internal process and data governance structure in place to combat risky situations. A good governance strategy includes the security team to ensure compliance with industry and local needs for all processes and forms of data. The protection of data, a key asset in any organization, is more prevalent than ever before. Regulation requirements like Europe’s General Data Protection Regulation (GDPR) and California’s Consumer Privacy Act (CCPA) have forced organizations to closely examine their data management practices and security methods.

Transparency

Governance fosters a culture of collaboration and transparency in which every team can help fine-tune the processes and applications that support business transactions. Especially with new implementations or large projects, transparency is key to verify that key team members are effectively using the new tool. After all, your company paid a lot of money for rolling out a new way to work, and all stakeholders need to be open and honest about what works and what doesn’t.

Without a method for verifying and flagging change requests across the organization, bad data or ineffective processes can bubble up to the surface and impact your customers. A good governance process includes consistent review and tools to provide transparency to the health of your business systems.

Key components of a good governance framework

Governance strategies vary based on a company’s objectives, resources, and risk tolerance. What constitutes good governance for a small startup might not be sufficient for a Fortune 500 company. However, all good governance strategies address the following components:

Vision

Your organization has made a sizable investment to develop and nurture your digital landscape, and establishing a clear overarching vision for how changes will be governed across initiatives is paramount to the success of any effort. Whether it's a shiny new implementation or an exploration to refine existing capabilities, each scope of work should clearly define the criteria for success along with the guardrails for securely executing work to achieve an established goal.

And to get to the next checkpoint on your vision, you need to plan where to go, how to get there, and what to do along the way. Prioritization and refinement of the work efforts on your roadmap should not be done in a vacuum. Involving stakeholders from across the organization is necessary to ensure engagement, support for the vision, and transparency to how any change is weighted as it relates to the broader business backlog of requests. Open dialogue across stakeholders is necessary to effectively execute elements of the vision for each step along the way.

People

Any scope of work needs a range of perspectives and skills to accomplish a particular goal. That's where governance comes in to organize the people, processes, and technology behind the project. A best practice when establishing a governance framework is to enlist a Center of Excellence (CoE). The CoE will typically include key stakeholders from sales and operations roles, along with an executive sponsor who is responsible for establishing the vision, roles, and responsibilities. Any significant change that will transform a business system should be vetted and prioritized within the CoE.

Centers of Excellence encompass different roles in an organization. The CoE is responsible for managing software changes to enable your company to do new things faster and refine existing things that may need to change with the times. The CoE acts as a governing body to coordinate stakeholders, prioritize initiatives, and make sure changes are developed and migrated efficiently and securely to prevent unwanted disruptions that can put the company at risk. This in turn helps keep the team responsible for executing changes focused so they can move quickly to keep up with the demands of your business. The range of perspectives within the CoE can normally be found within the following groups:

IT

These are the people who do the work to change your Salesforce org, and they are responsible for managing these changes across your broader integrated system landscape. Since they're the ones who make the system changes happen, they need to be engaged with new tools features available from Salesforce via Trailhead, Success Communities, and other resources. Members of this group will be able to understand business requirements and determine an appropriate technical solution for users.

Business units

These are the people who are responsible for determining what needs to be done within your Salesforce org. They collaborate with the delivery team within IT and the broader end user community to understand new things that can be created or changed within a Salesforce org and translate ideas for improvement into business requirements. Large organizations can have multiple business units too, and it is imperative that business units partner with all other stakeholders to effectively identify change requests that can benefit the broader business.

End users

These are the people who are using Salesforce on a day-to-day basis. Whether it’s an internal user in salessupport or another function, or an external user who is a customer or vendor, the end user perspective needs to be considered whenever a new change is introduced. IT and business unit stakeholders depend on the perspective of end users to verify the usability of a change. End users have a unique perspective as well, and a CoE should consider this “voice of the customer” as it relates to any new change request.

Process

To effectively manage any scope of work, organizations need to establish the lanes and processes for how new things will be implemented. While the brunt of this work relies on the solution delivery team (i.e. IT, Salesforce admins, or a similar group), all stakeholders need to be involved in order to ensure that any change matches the original business need and doesn’t introduce an unwanted bug once it’s rolled out.

Whether the change is a new implementation or a small tweak in your existing landscape, consider your strategy for how that change is built, tested, and deployed. If your organization has multiple Salesforce environments, it is important to consider changes across the broader organization when understanding specific environment needs. When organizations rollout transformative changes, they need to focus on the following factors: what model will be followed for managing change (governance model), how the change will be implemented across the organization (development lifecycle), and when can teams in the organization start using the change (rollout strategy).

Governance models

Governance model options may vastly differ based on unique needs, size, and communication strategy. The following options are common governance models:

• Centralized model: For single ships where one set of processes and a sole development stack is being managed, the centralized model will ensure changes are governed with a single CoE at the helm. This model works best for smaller, single-org companies.
• Decentralized model: If your ship is part of a broader fleet with different sizes and nuances in your landscape where a “one size fits all” approach isn’t applicable, consider a decentralized governance model. This model is used for organizations that have multiple Salesforce environments with disparate requirements across business units or geographies.
• Hybrid model: If the ships in your fleet look the same but can choose how to manage their individual crews, the hybrid governance model may work for you. This model sets a baseline for standardizing general best practices under a common framework with leeway for allowing individual business units or geographies to manage unique localizations based on their needs.

Development lifecycle

The way you create, test, and deploy changes can be adjusted based on the size, scope, and need. However, if you manage a small change with the structure and checkpoints of a large change, your processes may be bloated and unnecessary. Consider these options when determining the development lifecycle for managing software changes:

• Waterfall methodology: If your organization has traditionally managed changes in an “all or nothing” model, you have followed a waterfall methodology. When a waterfall approach is used, all changes are built in a lower level environment, packaged together, then moved into a larger environment where end users can be trained on the change and test it to ensure it doesn’t break anything in their existing system. Once everything is tested and approved, all changes are again packaged and deployed into production where end users leverage the work, the delivery team fixes bugs, and preps for the next big change.
• Agile methodology: If your organization rolls out small changes and quickly iterates to fit a desired “end state,” you are following an agile methodology. An agile approach works best when there are rapidly changing user needs, constantly evolving business objectives, and a fail fast mentality that applies lessons learned from prior work efforts. In this model, foundational changes are first built, deployed, and tested to ensure the most viable functions can be leveraged by users. Once deployed into production, end users provide feedback on what works and what doesn’t, which then influences the next iteration of the change.

Rollout strategy

While your organization is determining how changes will be governed as well as the methodology for building changes, the rollout strategy should also be considered. For example, you may opt for an agile methodology for managing changes, but determine that only a subset of your users should be exposed to the change before other groups. Maybe you want to rollout a new process first to internal users, then to external users.

Whether your model is “big bang” to deploy to all users at once or phased to focus on a subset of users before others, consider the needs and dependencies of your user base when determining the rollout strategy for a particular change.

Technology

After you build your ship, find your crew, and establish your line of command to steer the ship, you need to manage the technology to make it all happen. When implementing a custom solution or rolling out a new managed package on the Salesforce platform, there will be ongoing challenges for developing and deploying changes across the landscape where tactical processes need to be followed for technical teams. To get started with strategies to manage changes across orgs within your governance framework, consider the following:

Development models (programmatic + declarative)

To code or not to code is becoming less of an ambivalent question. Low code platforms such as Salesforce make it easier than ever to do cool things in your organization without the technical wizardry to write complex code that only developers can understand. When dissecting business requirements to create a comprehensive solution, consider declarative (i.e. point and click development without code) solutions available via Salesforce managed packages and the AppExchange instead of creating a programmatic (i.e. with code) solution.

Technical governance

Any change that allows a particular function to work needs some type of checkpoints to ensure things won’t break the business when introduced into the production org. Regardless of the size of your delivery team, some common best practices should be followed for the governance of technical changes in your landscape. These can include:

• Integration testing: Some data changes may have hooks into other platforms within your technology stack. Identify integrated data touch points and perform testing to ensure that new changes in your Salesforce environment do not indirectly affect other platforms.
• User Acceptance Testing (UAT): Business stakeholders should be involved before any significant changes are introduced into production to ensure that the delivered change meets the original intent of the business requirement.
• Change reviews: Change may happen rapidly, and it’s important for all functional and technical team members to follow communication protocols for new things being introduced into production. Schedule a change review in conjunction with your release cycle.

Landscape / org strategy

Low code platforms like Salesforce allow IT teams to manage changes across multiple orgs within their environment. While it may seem daunting to figure out how to choose the right Salesforce org for the job, the best practice is to manage any change in a lower level org such as a developer sandbox and move up the landscape. This allows for all stakeholders associated with a change request to approve changes before they make their way into Production.

New tools in the marketplace, such as Salesforce DX and the creation of scratch orgs, provide more options for technical team members to solution new things to enable new business functions. Here's one example of a Salesforce landscape and the release management process.