3. Engaging users and understanding their business processes and needs

Learning Objectives

 After completing this unit, you’ll be able to:

  • Capture the true business needs of users
  • Learn how to draw process diagrams

Capturing user requirements and business processes

Users are often very clear what they think they want and how you should configure it it Salesforce. But this can be very different from what they really need, and the best way to deliver it. That is why running sessions with them to capture their business requirements and understand their current and future business processes is so valuable.

The Trailhead User Adoption Strategies unit called Prepare to Build Your Salesforce Journey has a section on  the importance of capturing business processes. It is copied below, in italics:

Document Processes

If you have executive buy-in, now is a great time to start documenting your current processes—and how Salesforce can improve upon them. You can break this project into four steps.

Document your current sales process. Ask yourself—and a sales leader with that on-the-ground expertise—these questions.

  • What happens at each stage of our sales motion?
  • What are we coaching reps to do at various points in the sale?

Get a detailed look at what’s working and what’s not. At this stage, you want to determine:

  • What’s working well for everyone?
  • What works well for some reps but isn’t being replicated well across the board? Is it easy to replicate?
  • What manual processes can be automated?
  • At what points do sales reps have to use multiple systems to get their job done?

Work with the sales leaders to revise the sales process. A change in technology can be an excellent time to update and streamline your sales process. Focus on how Salesforce can help:

  • Automate manual processes.
  • Get rid of steps that aren’t necessary.
  • Make processes faster and easier.
  • Integrate data that sales reps need so it’s in one place.

Document the new-and-improved process that you’ll create using Salesforce.

Using Elements Catalyst to document processes

Elements Catalyst has a process mapping solution.  It has been designed to be used in live workshops which means you can engage with end users and hammer out their requirements.  Whilst the format/notation looks very basic, it is actually deceptively powerful and has been refined over the last 20 years in 1,000s of projects.

We are going to use the Opportunity lifecycle – from being raised to closed won (or lost) – as the process we are going to look at.

Landing pages

But before you start creating a process diagram for the Opportunity object process we need to create a top-level landing page – a graphical folder structure if you like – where you can put ALL the different process diagrams and data models you will be drawing over time as you document more and more of your Org. Elements supports the concept of a process map that is a hierarchy of diagrams. So use the process map like a folder of process diagrams. There are advantages to this rather than having lots of discrete diagrams. You are only managing one map, therefore managing access rights, governance, version control, reporting and branding is far simpler.

We’ve seen different approaches for landing pages:

  • An overall company end-to-end process or value stream. This sometimes takes a while to get agreement on if it doesn’t already exist. But is is very valuable because every process in the company hangs off it somewhere.
  • A series of activity boxes each of which is a mini end-to-end process; “issue to resolution”, “recruit to retire”, “quote to cash”.
  • A simple set of activity boxes for each lower level process diagram, so it is essentially a set of menus or shortcuts.

Below are examples of each type of landing page:

Option 1. Top Level operational diagram. This is the flow of high-level activities showing the core value stream of the operation with individual boxes housing the support processes. If you have this kind of view available – or have the right stakeholders to help you create it – it’s our recommended approach. If you can’t start with this picture, at least keep it in mind as it’s where you would hope to end up if you use this approach in the longer term.

Option 2. Catalog of “End-to-End” processes. This is a common way of describing processes in an “IT project” context. “issue to resolution”, “recruit to retire”, “quote to cash” …etc. This is really useful when you do not have the time get agreement around how option 1 should look. The example below shows using “Image mode” for the activity box theme. This makes it more visual and when you hover over the image – the text underneath becomes visible. But you could just as easily write “Develop and Close Sales” or “Develop new product” as the text in the activity box. The inputs/outputs in this context are optional. Whatever works for you. It’s about communication, context and getting everyone on the same page.

Option 3. Using an existing folder structure. You may have existing documentation and process content in a set of folders. We get asked “how can I save my Elements maps in folders?” We would recommend moving to a process-focused structure (like Option 1 or 2). If that’s not an option, simply create a top-level diagram that replicates your file folder structure for content. While it re-enforces functional silos and misses out on delivering the value of cross-functional visibility, if you absolutely have to stick with it – it’s no worse than where you are today.

Mapping processes & notation

Mapping processes can feel daunting, especially when you start talking to IT teams who often use a complex modeling notation.

Diagrams can be drawn in any format or style but this approach really works:

  • Draw the diagrams in a simple left to right process flow aiming to have no more than 8-10 process steps per diagram, called activity boxes
  • The activity box is a single, simple building block to show what is done and by whom. It is all you need. You don’t need lots of different shapes. Trust us.
  • Any activity box can have lower level “child diagrams”. This makes it easy to keep each diagram simple and easy to read with the detail in the lower levels.
  • The audience for these diagrams are:
  • end users – get agreement on optimized processes and use them as training embedded inside Salesforce objects
  • admin/developers – clear view about what operational processes need to be supported by the customizations
  • compliance/auditors – in regulated industries the process diagrams support regulatory compliance
  • management – the processes highlight departmental handoffs and also the key metrics that should be measured

Walter is here to explain some of the principles and show you to map processes.

if you didn’t watch the video, read from here…

Process mapping notation

The cool thing is that there is only ONE shape to worry about. With just this notation you can describe any process, no matter how complex, in a way that everyone understands – without any training.  

The way of thinking about the process diagram is this: “What happens in terms of actions (verb and noun) which together produce the desired outcome. Why do we start it and why do we complete it (input/output)? Who carries these steps out (role/resource – can be human or system)? How is each step carried out in detail (blue corner drill down to child diagram – or paperclip link to supporting documentation)?

Here are some hints on using the notation when designing process diagrams:

Input/output. The lines between activity boxes show the triggers and outcomes.  Every activity box must have lines connecting them. And every line must have line text. If the activity is “Process Invoice” then try to avoid calling the output “processed invoice” but instead try to be more specific. Is it “approved invoice” or “validated invoice”?

What happens. It starts with a verb: Create email, Raise opportunity, Triage and route case, Assign task, Win order, Onboard team member.  Try to avoid the words “manage” or “process”. Get more specific.

Resource. One or more resources can be attached to an activity box. They describe who is responsible for an activity i.e. Salesforce Admin, Customer Success Manager, but can also be a system i.e. Salesforce, Pardot. They are an alternative to swim lanes and keep the diagrams tighter.

Drill down corner. The corner shows that this activity has a lower level diagram.

Links: The paperclip shows that there are links to attachments – notes, images, URL links etc. These are displayed in the right panel.

If you watched the video – pick up again here…

To make this training easier, we have provided you with process map that you can copy.  There are a number of maps you can copy for your own use in the Example Maps Space.

Below is the top level diagram. If you click on the drill down corner which is the top left of any activity box you will “drill down” to access a lower level diagram.

The Opportunity process diagram

Here is the process diagram that describes the lifecycle of an opportunity. This is the drill down from the top level diagram. You can see that each step also has drill downs to lower level diagrams. There is no limit to the number of levels that you can drill down.

Now you can understand the opportunity process that we have developed for you. Your process is probably very different, so you can edit the copy. It is simple drag and drop.

The process diagram you see above describes “a process”. It may not be the process that everyone follows. It may not be the process that everyone believes happens. The power of process mapping is getting shared agreement and then communicating the process to everyone. As you go through the mapping you will probably identify some quick wins. This always happens when people start seeing the process and the handoffs between each other.

Don’t be scared if the diagram becomes large with 20+ activities. Later you can simplify by taking a group of activity boxes and “sending them to child” which means taking them and creating a lower level diagram.

Sometimes, where the process is well understood but not documented, this is really quick to do. In other cases, documenting the process highlights the fact that there is some disagreement how the process works (or should work) – and it takes a slightly longer.

But don’t underestimate the value of this mapping. We’ve got years of experience process mapping. Getting everyone on the same page – literally – is so empowering.


1.    How many levels down the process diagram hierarchy can you go?

A.  1

B.  5

C.  As many as you want

2.   What diagrams can you draw using the process mapping?

A.  Operational processes

B.  Data models

C.  Screen layouts

3.   The documentation you add to a process diagram:

A.  Can be any format (notes, URL links, images)

B.  Are only documents that are in Salesforce Files

C.  Are only visible to Editors


  1. C   2. A&B  3. A


NEXT – Unit 4 : Training users on processes that are supported by Salesforce