A guest post by Melissa VanDyke.

We all know those three little words that every #AwesomeAdmin loves to hear: “Is it possible…?”

This moment is always exciting for us (we want to help!), but it is always a little scary too.

When anything and everything is possible (and as #AwesomeAdmins we know this to be true), the fear we might experience in this moment is around worrying we will not choose the RIGHT thing. Implementing a methodology for your process documentation will help you make the RIGHT decisions every time, because it provides a solid foundation you can rely on time and time again. Let’s get started!

The 5-Step Methodology for Documenting Process (and Crushing the Fear!)

Whether you have inherited a salesforce org and need to figure out how people are using it today so you can enhance it (or just document it), or if you have been asked if “it is possible” to move an external process into salesforce, steps #1-3 are always the same (and steps #4 and #5 will most likely not be used if you are just documenting a current state without any goals of enhancement or new implementation).

Step #1: Identify Personas (Team Charter):

Identify the key players that represent and use the current process and assign each of them an official role; such as Business Owner, Executive Sponsor, Subject Matter Expert (SME) and or Super User. These are people you will need to provide you with a full picture of the current state and the future state requirements. Below is a team charter template to get you started!

Team Charter (**NOTE: You can have more than one super user and subject matter expert, and it is best to have at least one for each team/part of the process)

[Enter your name]

Project Manager: Responsible for development of requirements, management of project scope, schedule and budget (as applicable); and securing project resources, both internally and externally, to complete project. Reports progress and escalates issues as necessary to Business Owner.

Salesforce.com Administrator: Responsible for system design, quality assurance and user acceptance testing, conducting initial training sessions for all users and continual support and administration of the technology.

[Enter Executive Name]

Executive Sponsor: Articulate the vision of the project and provide support for resource requirements. Aid the team in driving the process modifications required for adoption of the resulting changes.

[Enter Business Owner Name]

Business Owner: Provide project oversight. Aid the team in driving the process modification required for adoption of the resulting changes. Secure the resources and funding needed for the development, implementation integration and rollout. Remove organizational roadblocks.

[Enter Name]

Super User: participate in all project activities, work with team to define and document business and functional requirements and continual enhancements. Participate in systems and training documentation development and rollout as needed, including user acceptance testing.

[Enter Name]

Subject Matter Expert: participate in all project activities, work with team to define and document business and functional requirements and continual enhancements by providing subject matter expertise regarding business needs.

Step #2: Plan the Kickoff Meeting (Set Expectations)

Schedule a kickoff meeting with the people identified on your team charter. Be sure to include a summary of the project and why you are scheduling this meeting, and set clear expectations for them so they know how they can start providing value to the project and taking ownership of their processes by coming to the meeting prepared.

Below you will find an example kickoff meeting invite/overview to get you started. Please edit it to make it fit your specific project and situation:

Good afternoon –

You have each been identified as a key contributor to the ____ process. The purpose of this kickoff meeting is to review the current state as a team. With all of you in the same room we will be able to productively discuss the pain points of the current process and the ideal future state. The success of this project is dependent on full cooperation and engagement from each of you as key stakeholders!

I look forward to getting to know more about your process and brainstorming ways to solution any painful parts of the process, as well as streamlining/automating where possible to bring efficiencies to the department and your teams.

Below is a team charter which identifies the role that each of you will own for this project along with an agenda overview so you can prepare for the meeting in advance.

Team Charter:  [Paste the team charter from step #1 here]

Agenda overview: 

a. Review team charter and role assignments
b. Review high level project information (dependencies, risks, assumptions, etc.)
c. Review current state, analyze existing processes and identify business pains (bombs vs jams)
d. Business and Functional Requirements brainstorming for future state
e. Agree on Action Items for next steps

Please let me know if you have any questions or concerns in advance of this meeting (and or if you have identified other key people that are not represented below and should be added!).

Thank you for your participation!



Step #3: Understanding the Current State (Bombs vs. Jams)

Now that you have everyone in the same room and they are walking you through the current state process, make it clear that you need to know where the pain points are.

The best way to improve a process is to ease the major pain points for the people in the room; not to mention how excited they are when you listen to their pain and tell them you are going to do your best to make these pain points disappear! This process enables the team to trust you (you are on their side after all!) and makes them feel a sense of ownership in the project at the same time. This process will ensure you understand the process well enough to design the correct process if the project is approved to move forward.

Bombs represent the major user pain to be solved:

  • Lots of work-around processes
  • Lots of pain and spinning of wheels
  • Represents the bigger process issue that need to be solved (typically only two or three of them in the current state, the rest are typically jams)

Jams are force.com platform features:

  • Workflow Rules with Email Alerts/Field Updates
  • Formula fields (to display “action items” on a report!)
  • Any automation or functionality you can do easily with force.com platform while solving for the bombs

Below is a sample documentation of bombs vs. jams from a pretend kick-off meeting to help get you started:

BOMB: The sales team has 3 email addresses they send support issues to (they have to decide which email to send each type of request to in order to get help from the internal client technical support department about existing clients). A summary of the major pain points is below:

  • Pain #1: they lose track of pending request status (they don’t know when an email request has been actioned and any action to remember to follow up is manual)
  • Pain #2: There is no visibility/ summary history of requests for clients
  • Pain #3: There is a lot of email churn because they often email the wrong email address and don’t remember to include important information (there are so many different request types to keep track of they get confused)

BOMB (same bomb as above but from the point of view of the technical support team): The client technical support department manages these 3 email addresses by actioning requests from the sales team as they come in. A summary of the major pain points is below:

  • Pain #1: they lose track of which items are being worked by which agent because the inbox is hard to manage as an email
  • Pain #2: The Excel file tracking is unreliable (agents are supposed to log their cases into the file before they work them but often agents work on the same issue or miss issues)
  • Pain #3: There is no visibility/ history of requests for clients
  • Pain #4: There is a lot of email churn because the sales team often emails the wrong email address and or they don’t remember to include important information

NOTE: A possible solution / future state that might be going through your mind during the kickoff meeting when you identify these bombs: We could create a custom object with a record type to represent each of the three email addresses (each with different field requirements and validation rules as appropriate). Each form can be routed to the right team for action using an approval flow (remember, an approval flow can be used for request to action it does not have to be a true “approval”!).

JAMS: All of the below requirements are example jams that you will hear in the kickoff meeting/ current state discussions. You know they are jams because they are standard force.com declarative solutions that you can do automatically while working on the primary solution for the BOMBS (jams are typically workflow rules and formula fields, reports and dashboards, automated reports, and time-based email alerts, etc.):

  • SLA tracking is impossible (you will solve for this just by ensuring reports and dashboards/ list views are being used as queues, and you can schedule reports to the managers/users showing all requests that are past due or close to past due, etc.)
  • Reports and dashboards are needed (easy!)
  • New hire knowledge transfer is complicated and time consuming (all the requests being in salesforce and related to the account will automatically make training and knowledge/history transfer easy)
  • Email the sales team when a request is submitted successfully and when it is closed/actioned (easy, you can do this in the approval flow process!)
  • Show the # of days since submission in a field and send a report of outstanding requests to the manager each afternoon, including an average # of days submitted (easy, you can do this with a formula field on the object and use it in a report formula field as well!)

Step #4: Proposed Future State

In the kickoff meeting be sure to spend some time on brainstorming the ideal future state (if they could do anything with a snap of the fingers what would they want!?). Get them excited to talk about the possibilities and let them know if you are able to understand their ideal state, it will help you plan for the new process accordingly!

NOTE: If any department / team is mentioned during this meeting that is not represented in the room be sure to get the name of a person that would represent the process for that team and reach out to them immediately after the meeting (and make them part of the charter if applicable).

Step #5: Planning and Approvals (Trade-offs and Buy-in)

Document and communicate the current state flow to the project team as soon as possible after the kickoff meeting. Schedule time to complete this within 48 hours! When you send the email to them (with the current state attachment) be sure to ask them for their feedback if they notice any errors and give them a deadline for their approval.

Click here to download a current state PowerPoint template to get you started!

After you send the current state out to the project team for review/approval, start working on the future state proposal and time-line with enhancement list immediately. Clearly define the “core project” milestones and the future enhancement list so that the project team clearly understands which features will be delivered when.

Click here to download future state with milestone chart PowerPoint template to get you started!

Below is an example planning and approval email, please edit it to fit your project and situation:

From: MVD
Sent: Thursday, September 17, 2015 9:30 AM
To: Project Team
Subject: Proposed Future State and Milestones

Dear Project Team:

As discussed, attached is the future state core project proposal with delivery milestones along with a list of future enhancements. I believe the core project design will solve the major problems that were brought to my attention during our recent conversations; and the future enhancements will solve additional problems to create more efficiencies as outlined below.


  • Full end-to-end streamlined process between the technical support (TS) team and sales team to reduce time spent on each task
  • No more email churn (we will have multiple record types/forms with different required fields and validation rules to ensure the forms are accurate at submission)
  • No more searching email inboxes / Excel to find requests and trying to figure out the current status (each team will either be notified via email or check a report/dashboard queue as applicable)
  • Full visibility into queue and the history of a client/ customer on the account page (making all future processes and new hire transitions much easier)
  • Easy reporting in real time (including easy SLA tracking) and instant email notifications to all parties letting them know an action is done!
  • No more Excel tracking! No more manual tracking of any kind!


  • Automatically create an opportunity for the sales team when a specific record type is rejected by the TS team (including comments from the TS team in the opportunity) [this is done manually by the sales team today]
  • Integrate the accounts payable team into the approval flow [the TS team receives approval from AP team separately before they action certain requests]

Project Milestones

Please reply with your approval to move forward, or provide me with your comments/ concerns/ questions so we can finalize the plan by [insert date here].



Now the next time you hear those famous three words, don’t forget you have this methodology in your back pocket! The knowledge alone will allow you to trade the fear for another level of excitement in that moment! I sincerely hope this structure helps you as much as it has helped me in my career.

SPECIAL BONUS: I presented a breakout session on this topic at Dreamforce 2015, which inspired this post! If you can’t get enough talk about process documentation please check out this video recording of the presentation (it includes a live reenactment of a kickoff meeting!). You can also download the presentation deck here.

4 thoughts on “ A Methodology for Documenting Process (and Crushing the Fear!) ”

  1. Love love love this post! Just excellent! Thank you for sharing this. I am a self-learner Salesforce admin, as well as playing role as business analyst, PM, and need to document all developments along the line. I struggled finding some template with the clear guidelines that is not overwhelming – and here it is! THANK YOU!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.