How to Document your Salesforce org
As we’ve mentioned in previous blog posts, Documentation can be google docs, word documents, zoom recordings of strategy sessions, pictures of a whiteboard showing technical design sketches, and even internal chats among the Salesforce team.
Basically, anything that helps illuminate why a certain part of the system was built the way it was, how it interacts with…
As we’ve mentioned in previous blog posts, Documentation can be google docs, word documents, zoom recordings of strategy sessions, pictures of a whiteboard showing technical design sketches, and even internal chats among the Salesforce team.
Basically, anything that helps illuminate why a certain part of the system was built the way it was, how it interacts with other parts of the system, and who to contact in case there are questions is Documentation. It doesn’t need to be fancy or overly complicated.
But, how should we even begin?
I know this can seem like a daunting task, especially if you are working out of a complex mature org. You are probably looking at hundreds of custom objects, thousands of custom fields, automations, and page layouts and thinking to yourself “How am I ever going to document all of this?”
My advice for getting started would be to take it one piece at a time. Are you currently working on a project for Sales to add some new fields? Start by documenting this new process. Document the object the fields are going on, the fields (and what each one is for), and then who in Sales is requesting these changes. Then, as you are doing that, you remember the project you did last year that touched this same object, and you document that process (from what you can remember). Then, the following week you get an email from a user saying they can’t edit a certain field, which jogs your memory about why that field was created, and you document that field. This is how you get the ball rolling, just begin documenting as parts of the system come up naturally through your work, and before long you have a solid base of Documentation to build from.
What form should Documentation take?
There is no definitive answer to this question. Documenting your Salesforce org is not about adhering to a strict process or protocol (in fact, I would argue this is what makes admins avoid documentation), it’s just about getting information down and making it shareable among various stakeholders (at the minimum, your Salesforce team and anyone makes changes in the org).
The first recommendation I’ll make is that it’s in the cloud. Since this information needs to be shared and should be updated regularly, it needs to be in a place where when it’s updated, it’s updated across all users and devices. Google docs is a great option since it’s free, in the cloud, can track changes over time, and has collaboration features.
Whichever cloud option you go with, start with a blank document, and using the example from above, write down a structure like this:
Documentation is a living thing
Lastly, documentation is a LIVING document and is only as good as how often it’s maintained.
As business use cases change, requirements change, and the system is altered to match, the documentation needs to be updated along with it. This ensures it’s always up to date and can be referenced by anyone on the team, knowing it’s accurate to the current state of the org (and the organization use case it supports).
After starting out with the above structure and putting your first piece of Salesforce documentation in, I would recommend calling a meeting with anyone who makes changes to your Salesforce org. If possible, also get buy-in from your manager or whomever ultimately is in charge of the whole Salesforce org, this will ensure accountability from all team members involved and that this process is adopted org wide. Explain the process and how going forward every time a change is made or someone is reminded of a past project and it’s details, to update the living Documentation.
Ultimately, hopefully over the following months and years, you end up with a thorough documentation database for your Salesforce org. If you ever need to onboard a new Salesforce admin, have IT help with some code, or just remind yourself of what is currently built and why it was built, you just have to pull up your Documentation!
Get Documentation Template sent to your email:
Ps. Our app oAtlas was designed to make Documentation easy and accessible right in your Salesforce org. Based on the ‘map’ we build of your org, you can tie documentation into projects and across different parts of your org, communicate with your Salesforce team right in Chatter, upload documents, and even send email alerts to key stakeholders when new Documentation is created.
Check out the oAtlas tab to learn more and get in touch.
Top 5 reasons why you should document your Salesforce org
1) To make your job easier.
With good documentation to reference, you’ll be able to make changes to your org faster and with more confidence (and make the right changes).
Let’s say for example a user from Marketing is asking for a new field to “score” a prospect. You know from past projects that some other groups are also using scoring, but you aren’t sure if they are the same…
To make your job easier
With good documentation to reference, you’ll be able to make changes to your org faster and with more confidence (and make the right changes).
Let’s say for example a user from Marketing is asking for a new field to “score” a prospect. You know from past projects that some other groups are also using scoring, but you aren’t sure if they are the same. If you have good documentation, you can search for the other scoring fields and read about what the business use case was for these fields, the conversations that went on, and possibly even who requested these fields to be created.
In this example, let’s say through reading the documentation for these fields, you realize that what the Marketing user has asked for is actually already built. Without documentation, a meeting would have been called with the Marketing user, emails / meetings would have been required with other Marketing groups to understand their usage of the current scoring fields, and potentially in a worse case scenario, parallel duplicative functionality would have been built. With documentation, all that is required is granting field access to the appropriate profile and perhaps some training.
To ensure seamless scaling
If you have good documentation, it will be much easier for your org to scale, now or in the future.
Many times when an org is first being built, it’s for a particular business unit, and for a particular business use case. But the power of Salesforce (and the significant investment a business must make), means that the tool is likely to grow quickly in an organization and can begin to encompass other teams and other processes. If you are managing an existing org that’s more than a few years old, you are probably already at this place.
When an org begins to scale like this, and new teams and processes come aboard, the org faces new challenges. Example questions that begin to emerge look like: are there any fields on the Contract object we can remove (to make room for a large project coming in)? Should we use an existing Profile or create a new one? (for the new team coming into the system) Which record types on the Case object should support reps be able to see? (users are complaining they see unnecessary options when creating a new Case).
If you have good documentation across the org, the types of questions I laid out above should be answered pretty easily. You will know why every field on the Contract object was created (and with some research, which ones might be able to be removed), you’ll know which Record Types were created for which business use cases over time, and you’ll have notes on who to talk to regarding Profile permissions (and who is the decision maker on what a particular team is / is not able to do in the system).
To easily onboard new Salesforce team members
Salesforce orgs can get very complex over time, and as they grow, the team managing the system usually does as well. This can be additional admins, additional developers (perhaps from IT or other non-Salesforce specific domains), or even outside consultants who help manage your org. What they all have in common is that when they walk into a new org, they need a ‘guide’ as to how the system is built and how it’s being used.
You can try to answer each question about the org as it comes up, but this is incredibly time consuming. On top of this, an outside consultant or project based developer is usually only concerned with the one particular area they have been tasked with and not how that part of the system might affect other areas of the org.
If you have good documentation, you can simply share it with them. A new team member can quickly come aboard and understand which objects are used most and how each team is using the tool. A project based developer or consultant can understand a particular object / record type combination they will be writing custom code for, for example. And all of this will happen much faster than if you had to sit down with each respective party and try to recall each important piece of information about a respective part of the org.
To help with user adoption
Like it or not, user adoption is a reflection of the team that is managing Salesforce. Whether it was the team’s fault or not, if a new business unit spends time and money to develop a part of the system, and user adoption is very poor, it looks bad for the Salesforce team members. Good documentation can help guard against this.
Good documentation forces you to put in words what a team wants and why they want it that way. In addition to simply objects, fields, and other pieces a team might need, you should document what they need to do permission wise so you can be sure to have their Profiles set up properly. Before you go live with a new team or process, you can refer to the documentation to ensure everything is working as you discussed in the various meetings, all the page layouts have the proper fields, and the right permissions have been granted so their experience is flawless on Day 1.
As a bonus, if there are issues during an initial roll-out, the Documentation gives you and the team a common place to reference and have a discussion. You can put notes, chats, and other discussions right on the Profile or Object in question in order to resolve the issue quickly and get the roll-out back on track.
To make your boss happy
Whether your boss is a Salesforce architect, a Project Manager, the CTO, or even the CEO, they will be happy to see that there is some kind of source information explaining how the “magic box” of Salesforce works. In a very short amount of time, your Salesforce org can become mission critical, and your boss will want to know that these mission critical processes are well documented.
From a practical standpoint, depending on what level your boss is at, the documentation may serve to: justify a certain budget for new projects, allow them to explain at a high level to their boss what the business is using Salesforce for, speak with authority in a meeting on whether Salesforce might be suitable for an extension into a new business unit, or maybe just give them peace of mind.
In addition to all of the above, having good documentation makes you look like a true Salesforce professional with all of your i’s dotted and t’s crossed. Whatever the specific reason, your org being well documented will go over well with your boss and you’ll be better off for it.
Ps. Our app oAtlas was designed to make Documentation easy and accessible right in your Salesforce org. Based on the ‘map’ we build of your org, you can tie documentation into projects and across different parts of your org, communicate with your Salesforce team right in Chatter, upload documents, and even send email alerts to key stakeholders when new Documentation is created.
Check out the oAtlas tab to learn more and get in touch.
What is Salesforce Documentation?
Documentation in its simplest form is anything that helps explain why a technical system was built a certain way, how it interacts with other parts of the system, and possibly who to talk to in the event there is a question.
What we are really trying to get at is: what is the underlying business need that led to this build, what was actually built, and what information should a future admin / project manager / developer (or a future you) know?
Let’s start with the simple question of “what exactly is Documentation?”
Documentation in its simplest form is anything that helps explain why a technical system was built a certain way, how it interacts with other parts of the system, and possibly who to talk to in the event there is a question.
What we are really trying to get at is: what is the underlying business need that led to this build, what was actually built, and what information should a future admin / project manager / developer (or a future you) know?
In practical day-to-day Salesforce administration, this could come in the form of google docs, word documents, zoom recordings of strategy sessions, pictures of a whiteboard showing technical design sketches, and even internal chats among the Salesforce team.
For example, let’s say you have an existing Salesforce org that is being used for Sales (Sales Cloud) and Service (Service Cloud). A new sales manager who’s team is not currently using Salesforce comes to you and wants to begin using Salesforce to capture their accounts, contacts, and opportunities. They have seen how other teams are using Salesforce, and want something similar but with some advanced features (like specialized sharing, custom code for when an Opportunity is closed, etc…).
In your head, you are probably already listing out the things you might need to build this:
New Opportunity Record Type
New Field(s) on Account, Contact, and Opportunity objects
New Page Layout(s)
New Role(s)
New Public Group (for specialized sharing)
New Sharing Rule (for specialized sharing)
New Profile(s) (if necessary)
New Permission Set (for specialized perms for managers for example)
New Custom Code (to handle after Opportunity close functionality)
New Workflow(s) (to send emails to a managers for highly prized Opportunities)
New Email Alert(s) (for new workflows above)
The list you have just created in your head, is in fact, Documentation.
Some might call it a requirements document, a spec document, a technical design document, or a build blueprint. All are acceptable and all are a form of documentation.
When viewed in this light, documentation does not feel like a foreign concept at all. It’s probably something you are already doing when building in your org, it’s just about putting it down in an organized, accessible, and shareable format!
Ps. Our app oAtlas was designed to make Documentation easy and accessible right in your Salesforce org. Based on the ‘map’ we build of your org, you can tie documentation into projects and across different parts of your org, communicate with your Salesforce team right in Chatter, upload documents, and even send email alerts to key stakeholders when new Documentation is created.
Check out the oAtlas tab to learn more and get in touch.
What is Salesforce?
The best known product of Salesforce (and where its namesake came from) is its Sales Cloud platform.
It’s a website you sign into and you can store all of your company’s sales deals, notes, and contacts. It allows a company with very little effort to completely move off of Excel spreadsheets and allow them to track their open sales deals in a centralized place. As a user, you login and begin entering details…
You know when you go to a doctor’s office and they ask you questions and the nurse enters your health details into some mysterious computer screen? Salesforce could be powering that system.
Or, when you sign up for Spotify and then get automated emails when your favorite artist releases a new album? Salesforce could be powering that.
Or, how about when you have a problem with an online order and you fill out their support form and immediately receive an email response saying “we are on it”? Salesforce might have sent that email.
Ok got it? That’s what Salesforce is.
Not quite? Alright let’s back up a little. I’ll start with a comparison.
Larry Ellison, founder of Oracle.
Even as a little kid, I was always fascinated by the Forbes 500 list. I can remember as young as 11 or 12, grabbing the Forbes magazine off the rack at a grocery store and reading through how these people made their fortunes. An incredibly diverse set of businesses are represented in the list, from technology, banking, mining, textiles, to retail, just about any industry you can think of.
What I always found so interesting about the list though was how many of the people and businesses I had never even heard of. Larry Ellison (founder of technology powerhouse Oracle, Forbes #10 with $56B), what’s Oracle? Like the Oracle from ‘The Matrix?’ It’s not a software or website I’d ever heard of. Michael Bloomberg (founder of Bloomberg LP, Forbes #11 with $50B), OK I’ve seen the Bloomberg TV channel, but what’s Bloomberg LP and how does it make so much money?
Granted, I was 12 and living in small town in upstate New York, but still, if you are reading this today and not deeply involved in the business or technology world, I bet you still don’t know how these two made their billions, and that’s just a sampling from the Forbes top 20!
So, what does this have to do with Salesforce?
Mark Benioff, founder of Salesforce.
Well, Salesforce (and it’s billionaire founder, Mark Benioff) is like the two companies I just mentioned. It’s a tool used by businesses, a lot of businesses, it makes billions of dollars every year, and it’s not generally understood by the public.
Hopefully I can help clear that up.
The first problem in trying to understand what Salesforce is, is that it’s a lot of things. It’s actually a suite of products with various use cases, so it can be hard to pin down. But alas, we will try.
The best known product of Salesforce (and where it’s namesake came from) is it’s Sales Cloud platform. It’s a website you sign into and you can store all of your company’s sales deals, notes, and contacts. It allows a company with very little effort to completely move off of Excel spreadsheets and allow them to track their open sales deals in a centralized place. As a user, you login and begin entering details: “OK, I talked with Bob from XYZ Company yesterday and we talked about him buying $10,000 in Product A, and we expect the deal to be finalized by the end of the month.” Very useful for salespeople to keep track of who they talked to, when, and about what deal. It also allows them to see what they have in their pipeline, in total, and how close they are to hitting their sales goals for the quarter.
High Five! (note: someone's hand missed)
Combine this over multiple deals, and all salespeople using the system, a company begins to get a complete picture of their revenue pipeline. Let’s bring Finance into the system, now they can begin budgeting based off of these sales numbers and not chase down spreadsheets or hold countless meetings. Let’s bring Production into the system, now we can start to estimate how many of a given product we’ll need to produce and they won’t be caught off guard when a big order comes through.
Sales pipeline view within Salesforce Sales Cloud.
Now, let’s take it a step further using the power of Salesforce Sales Cloud.
Let’s automatically send an email (with a summary of the sales deal) to the CEO everytime a deal is over $100K. Also, any deal that involves a quantity over 100 of Product A, needs to be approved by a production manager. Lastly, let’s go ahead and take the full pipeline (all sales deals), combine it into a Powerpoint presentation, and email it to all the Sales Managers of the company an hour before their monthly sales meetings, without anyone lifting a finger. That was a lot of time saved!
As you can see from this example, Salesforce can get very powerful (and very complex) in a hurry. It consolidates information in one place and saves a ton of time.
Let’s take a look at another Salesforce product, Service Cloud.
Imagine you are running a business selling fresh oranges, grapefruits, and limes (a delicious citrus drink if I do say so myself). Your customers put their order in on your website and you deliver the fruits the next day. But, sometimes you are in a rush and get the order wrong. Better put a “Support” page up on your website with a little form that users fill out to tell you what went wrong with their order. You set it up and begin getting emails explaining the orders that went wrong, just a few come in each week to begin with.
The business begins to really grow though and now you have 1000s of customers, 25 employees, and are getting 100 ‘problem with my order’ emails a day. Yikes, I can’t keep up with all of these! Salesforce Service Cloud to the rescue.
Let’s have that form, instead of sending an email, create a “Case” in Salesforce. Now, when you login to the system you see all of the Cases that have come in, they are all organized by ‘type of problem’, and you can respond back to the customer right from inside Salesforce (it keeps an organized log of the complete conversation).
Case management view within Salesforce Service Cloud.
Now, let’s take it a step further using the power of Salesforce Service Cloud.
Let’s automatically route any cases that have to do with grapefruits to the ‘grapefruit’ support team, since the ‘orange’ support team doesn’t need to see them. Also, when the Case gets created, let’s check to see if it’s one of our most valuable customers, based on their order volume (we are using Sales Cloud in this scenario as well). If it is, let’s automatically send out an email telling them we appreciate their loyalty and we have escalated their Case to a manager since they are a super duper special customer.
Lastly, it seems like a lot of these order issues are actually just people saying they didn’t get the juice recipe card in the box, which is probably there, but it’s at the very bottom under everything. Let’s make a rule for that. Now, whenever a Case comes into Salesforce with this being the problem, let’s automatically send them an article that has pictures of where the recipe cards are at the bottom of the box. That should take care of a lot of these without anyone lifting a finger!
This is the power of Salesforce, and the two examples above really just begin to scratch the surface of what the platform is capable of.
Phew, that was so much business process thinking my brain is steaming! Our business is running like a fine tune machine though! Let’s have a coffee and put our feet up.
As the late Billy Mays would say though...
If you’re still with me, let’s go a little deeper.
Imagine you are the CEO of a company and your employees keep asking if they can use the corporate credit card to pay for various things around the office. You think it makes sense to set some kind of limit, under which they don’t need your approval to use the card for, say $100. And, really, their immediate manager should be able to approve up to $1,000. Your approval is only needed when it’s more than $1,000.
It would be great if you had some kind of “Purchase Order” system that could handle amount thresholds, approvals, and keeping track of who spent money this month. You have Salesforce but that’s a Sales & Service tool. Or is it?
The real power of Salesforce is that it can be customized to handle nearly any business process. And it’s not a misuse to adapt it to a specific business process your company has, this is what it was designed for!
Let’s go ahead and build this Purchase Order system into Salesforce.
Now, let’s send managers an email every time a manager needs to approve a purchase, they can just reply to the email with the words “approved” and it will update in the system. Cool! Let’s also go ahead and send an email automatically to the employee and let them know their purchase is approved. They are free to swipe that corporate card for the limo and champagne! Lastly, let’s summarize all of this information each month and send it to all the managers of the company showing where the money was spent. Let’s again include Finance who can put the budget numbers in, and we can get an automatic look each month into budget vs. actual spending by team.
The above example is the main reason why Salesforce is such an incredible business tool, it can be bent and configured to handle almost any scenario.
The above example is also the reason it’s so difficult to explain exactly what Salesforce is. Salesforce means different things to different people based on what that particular company chose to use Salesforce for. For many, Salesforce is a Sales & Service tool. For others, Salesforce is a system for tracking purchases. For still others, it’s a marketing tool where they store and manage email blasts out to their customers. For some, they are using Salesforce (setup as a piece of a company website, perhaps to log in and out of work) and are not even aware that Salesforce is the underlying tool making it work.
Before we close, it should be noted that we are still just scratching the surface of all things Salesforce is capable of. A short list includes: automated marketing, external facing pieces of the system (similar to a patient portal at a doctors office) where customers can login, a complete App Store (like the Apple App Store but for business apps), quoting and e-signature, and industry specific products (like Health or Financial Services Cloud).
OK, ready? One last time, what is Salesforce?
Salesforce can be whatever you want it to be! But, most simply, Salesforce is a tool for running a business. Exactly what pieces of a business a company decides to run on Salesforce is up to them.
So, the next time you hear about Salesforce stock (ticker: CRM) soaring or see their new enormous skyscraper in San Francisco, hopefully you’ll have a slight idea of what it is and why it’s used by so many businesses.
Ps. If you wanted to use Salesforce for your company, the cost is per seat (ie. per user), per month for each user that has their own login to the system. There is usually a one-time upfront cost for building the system out to your company’s specifications, which a Salesforce Partner, like Cloud Studio helps you with.