Keys to a Healthy Salesforce Org are Governance and Documentation

You already know that Salesforce is a powerful platform. It is easy to customize, and there are many third-party integrations available that tie into other systems without custom code. That’s why it’s important to take steps early on to ensure it can scale with you.

As roles shift and change within your growing organization, so will your team’s Salesforce roles. As time goes by, you'll look back and wonder "Why did we build Salesforce this way?" or "What is Salesforce actually doing when I close an Opportunity" or "Who asked for this to be this way?"  Read on to learn about establishing Salesforce Governance why investing in documentation is the key to a healthy Salesforce instance.

Of course, should you need help or have questions, you can always contact us.

Salesforce Governance

Governance is a combination of:

• How to request changes.

• The review and approval process.

• Establishing a request prioritization method.

• A request implementation process.

How do your users request Salesforce changes and report bugs? Do they walk over to your admin’s desk, send a text, Slack message or email, make a phone call, or submit a case? Most likely, it is a combination of several of these methods.

Next, who reviews a request and decides if it is the right thing for an organization? Is this the admin’s responsibility? Are there criteria used to prioritize requests, or is it based on who is yelling loudest?

Once they’ve asked for a change, how can someone see where a request stands? Does it get done in a sandbox first? Does the requestor confirm it is right before going to production? What training or communication is required?

Finally, after they've walked over to your desk, do you just implement their request in Production without testing and informing the users? Do your users discover new features as they stumble upon them while using the system? How did you share that something new is available for use?

A Documented Salesforce Governance practice establishes answers to those questions. It is important for all organizations and does not have to be complex. Putting this in place early on allows you to add a new person to the existing process, which keeps things moving forward with little interruption.

Benefits of Salesforce Governance include:

• Clear expectations of all stakeholders and requestors.

• The ability to track Salesforce issues and progress against requests and calculate ROI.

• An agreed-upon method to determine next priority (eliminating pet projects).

• Increased throughput due to reduced context switching.

• A self-building repository of change requests and solutions.

Some of our recommendations for Salesforce Governance are as follows:

• How to Request Changes

  • Log a case! This is built into SFDC and keeps a backlog for you. If you already have cases used for supporting your customers, you can extend cases with an "Internal" Record Type or build your own custom object to keep track of requests.

  • Let users know they can go into Salesforce and make a request by logging the case.

  • You'll know who made the request, when it was made, and can communicate back and forth to get more details and requirements.

• Request Review and Approval Process

  • Define one Salesforce product owner and build in an approval process that routes new requests to them to approve and prioritize.

  • Document on the case with comments and fielded information, what's happening to the request, such as an "In Review" status.

• Request Prioritization Method

  • Decide how you will prioritize the work. Will it be First in, First out? Value-based calculations like Relative Weighting take a lot of the emotion and guesswork out of what should get worked on first. Check out this article by Karl Weigers, "First Things First: Prioritizing Requirements" where you can read much more about prioritization.

  • Consistently using a prioritization framework and governance process, that clearly documents how decisions will be made for what will get worked on and when, will help users feel like they've been heard when something doesn't get worked on, they will understand why.

• Request Implementation Process

  • Keep the requestor informed with automated updates throughout the process.

  • Confirm requirements and include any newly found details in the case.

  • Build the solution in the sandbox. Building in a sandbox allows you to create solutions without impacting your production functionality and users. 

  • Test using a repeatable process. Ideally, the person who built the solution is not the person who tests if it works.

  • Once the solution has been built and test, have the Requestor conduct User Acceptance Testing (UAT) to ensure the solution is working and no requirements have been missed. It's important to get this sign-off from a user before moving to production. This is the time to make tiny adjustments to the solution. However, if brand new (and large) requests are made that add-on, you may need to work those requests as separate change requests starting at the beginning of the process... Log a Case!

  • Communicate to users that something new is on its way. Typically, more than the requestor is impacted by the change so its best to share widely that a new feature or function is going to be present in the system. Using email, slack, chatter, lunch and learns are all good ways to communicate to users what to expect. If it's a major change, even a training session.

  • Move your changes to production.

  • Update the case status to reflect that the request has been completed.

  • Document details of the solution within or attached to the case.

Documentation? What? You didn't write down what you built? Let's discuss why documentation is so important.

System Documentation

Imagine you are a car enthusiast.  Let’s say you start with a basic model. You have the user manual for this model. On top of that, you work with a body shop to make this your dream car.

• You decide to add a custom engine to get more power. The body shop understands your needs, finds available options, and collaborates with you to determine the features your custom engine needs and what parts to utilize. They build and install the engine, tweaking it to your specifications.

• You choose custom tires and hubcaps with special sensors that tie into your smartphone to let you know about issues.

• You select a smart dash that replaces the analog dials and works with your iPhone and shows you the health of the custom engine and tires in addition to other features. You work with a specialist to customize this to meet your needs.

You are thrilled. This is far from the basic model you started with. Your body shop changes the oil and maintains your car. All is smooth sailing. Then, your body shop closes. The next time you need a tune-up, you find a new shop. They have your original user manual and the original installation guides for the add-ons but tell you they will have to take apart the engine and review the dashboard code to find the problem because your car is so specialized. You realize this is going to be expensive.

Salesforce and its add-ons are just like this custom car. There is robust documentation about how to use Salesforce out of the box and how to install integrations. But without information that ties the pieces and customizations together, a new staff member or admin will have to “take apart the engine” to troubleshoot issues, tweak existing functionality, or build new functionality.

Have your admin start documenting your customizations and processes now. Think of it as a custom manual for your car - with it, any new shop that works on it could find and resolve issues quickly and easily. If you've not been keeping documentation along the way and are now implementing a Governance process, be sure to capture all the right details for new requests going forward. We'll cover how to get caught up with documentation in a future blog post.

Key Documentation to Create

Depending on if a user is asking for a new Field or for Salesforce CPQ, the amount of documentation needed for each request will vary. For each request, the following details should be kept or linked:

Details About the Request

• Why is the request being made?
• What value will this bring you the user?
• Who will be impacted by the request?
• What pain or challenge will this request remove or improve? How?
• When do you need this in place?
• Do you have an alternative way of getting what you need? Do you have a workaround to this problem today?
• What process does this effect?
• Do you have any screenshots or links to the issue or examples of where this would be useful?

Details About What has Been Built

• Describe the solution that was built and its components.
• Describe why you chose the solution you did.  For example, why did you choose a process builder over a workflow rule?
• Update process diagrams to include the new solution.
• Include any test scripts that were created.
• Include links to training that was created.

In a few months, you may need to ask "How and why was this solution built"? With the above details in the request, you'll have a lot of details to reflect upon.

Contact us if you need help implementing a Governance Process or getting caught up on your Salesforce System Documentation.