In my recent post on Salesforce Org Health reviews, I talked about the conversations I’ve been having with our customers about keeping their Salesforce orgs running not only smoothly, but optimally. Another topic that’s come up a lot lately is Salesforce governance. That term might sound scary, so I’ll try to boil down a few concepts in this post that can be easy to implement, cheap, and immensely helpful.
First, what do I mean by Salesforce governance? I’m simply referring to having a centralized plan for how Salesforce is configured and how changes are managed. There are a few key components to a Salesforce governance strategy. To set context, I’m focusing on the “We have nothing and need something” thought process in this post. Sure, there are more elegant and structured ways to manage things, but this could be a great start for you.
Identifying your Stakeholders
It sounds so corporate, but every Salesforce has a set of stakeholders to whom it’s catering. It might be the support manager, sales manager, you (the admin), the developer team lead, 3 power users, and the CEO. Identifying who has crossover with Salesforce is important as it can help you manage communications and identify who should be part of the next step in the process…
Creating a Task Force
Or whatever you want to call it. “Task force” has a nice ring to it, or you could call yourselves the “CRM Governance Committee.” Heck, you can pretend you’re the A-team if you want to. Select this team by looking at your group of stakeholders and identifying those who should be involved with the decision-making process when making enhancements to the platform.
Setting the Meeting Schedule
Meet regularly with the Salesforce governance task force. Involving people from multiple departments and with varying “levels” of usage is important so that feature changes can be discussed with all affected parties. For instance, putting a validation rule on Contact to assure fields are populated for the sales team might break some Support processes when email cases are submitted without the required fields.
Here’s a typical meeting agenda you can follow:
- Review identified research findings from the last meeting
- Accept or dismiss user requests–following a thorough review, and determine what features should be in the next release
- Have conversation about release planning and schedule
- Discuss new business and review any backlog of newly requested features
But Wait, What’s a Feature?
I consider just about any user request to be a feature. It could be a new field, report, entire application, or project. Throughout the day-to-day operations of Salesforce, an admin is asked for many features. Any feature request should be managed with a system. Ideally, it will be handled with some form of product lifecycle management system (we love Jira), or Salesforce cases, or even just a spreadsheet. Train users to submit feature requests into the system so they can all be treated and evaluated the same. Keep an eye out for non-user submitted features as well. An example would be finding out about a new compliance requirement that will require additional security or hearing about the new business line at the water cooler. Think big and think ahead. Features aren’t just reactions to user requests, but can also be prompted by you, trying to get ahead of future need.
When a feature request comes in, as a first line of defense, determine how the feature should be routed. Here’s a simple flow chart that can help:
How to Research a Feature
Going to the task force meeting with your research squared away is a must. You’re the admin, and it’s your job to bring all your knowledge to the table and to help the task force make good decisions. Any feature that comes in can be run through a few simple questions so that when it’s brought to the task force, you’ve got a good primer for them. Here are a few things to consider when evaluating features:
- Is it really a feature or just a training issue?
- Will this feature require custom development?
- Will this feature require any modifications to the system?
- Can you determine if there are any cross-departmental impacts?
- Can this feature be managed via an AppExchange application?
- Is this a trivial delivery that should just be executed (e.g., a report tweak)?
What’s a Release?
Users and Salesforce itself both do better when changes to the system are planned and grouped together. Salesforce does 3 releases per year for this exact purpose. Everyone knows the schedule and can expect to see a raft of enhancements and documentation during release time and then have a stable system in between releases.
You should be doing the same thing. Get releases on a schedule so they can be planned, tested, documented, and delivered together. This way everyone knows it’s coming, and things aren’t changing all the time.
Communicating Back to the User
Having these processes in place gives users the ability to be heard. Whether their request makes it to production or not, a set communication chain ensures that each user feels as though they’ve been heard. Even if their “great” idea did not make the cut, they get an answer and know their input was considered. If it makes sense for your organization, you can use this communication as an opportunity to explain why the task force decided against the idea. Having this feedback loop goes a long way in encouraging users to contribute to the process, since they’re the ones in the trenches every day using the application.
In Summary:
Think releases. Every non-trivial feature needs to be in a release.
Plan and execute each release in a predictable and repeatable format.
Know your stakeholders and communicate with them regularly.
Keep a schedule with your task force to keep the energy high.
Follow up with users so they know how long their feature may take and can check in on the status.
As far as resources go, I really like this Trailhead module. They use some different terminology, but many of the themes are the same. If a Salesforce governance strategy hasn’t been clearly outlined and put into place at your place of business, I highly suggest you take the tips I’ve provided here and the information provided in the module to get things moving in the right direction.
