At TrailheaDX, business process mapping notation for Business Analysis (Salesforce UPN) training. It also launched a systems diagramming notation for Architects (Salesforce Diagrams). This article explains UPN and when to use Diagrams vs UPN.
“As Architects we know that diagrams are an important tool in our toolset. When we surveyed you, we heard loud and clear that you want more diagramming tools and more standardised diagrams.”
Susannah St-Germain – Architect Evangelist
SALESFORCE UPN (UNIVERSAL PROCESS NOTATION) FOR BUSINESS ANALYSTS
Salesforce UPN (Universal Process Notation) is a business process mapping notation for Business Analysts. UPN has been proven over the last 20 years in Salesforce customers of all sizes. It is designed to be easily understood by all the stakeholders involved in any implementation; analysts, end users, architects, developers, management and auditors. This means it needs to be a simple notation, but with the power to capture the nuances of any business process because “the devil is in the detail”. And the diagrams need to be read on-line embedded in applications. Again, you can use any number of tools to draw the process maps to comply with the notation.
The Trailhead team launched the Business Process Mapping for Analysts, How to draw Business Process Maps and updated Business Analysis Best Practices Trailhead badges. There is also an in depth Business Process Mapping for Architects course which is accessed from the Partner Learning Camp.
Here are the 5 principles of UPN
- No more than 8-10 activity boxes on a screen
- Drill down from an activity box to a lower level to describe the detail
- Attach supporting information to an activity box
- View and edit controlled by access rights
- Version control and history of changes at a diagram level
Here is the building block of the notation.
Below is the notation applied to an end to end sales process. The process map would have been developed by business analysts engaging with end users. But it is also used with architects and developers to validate requirements and for user acceptance testing. And the map is end user training, embedded in Salesforce. This is particularly important for regulated industries.
Whilst this image shows the process map going down 3 levels, there is no limit to the number of levels that you can drill down. The diagramming style is the same at every level.
SALESFORCE DIAGRAMS FOR ARCHITECTS
Salesforce Diagrams is a set of diagramming design standards for Architects. It is designed for system diagrams and ERDs and a great deal of design thinking has gone into the readability and useability of the diagrams. You can use any number of tools to draw the diagrams to match the standards.
Salesforce Diagrams follows the C4 Model approach, which means that there are 4 different level diagrams. Salesforce has created some design style guides. The levels are
- Level 1: The big picture. The systems landscape
- Level 2: A piece of the whole. A subset of the landscape
- Level 3: Process or interaction view. A limited view of the technologies in a solution
- Level 4: Double click. The data model showing just the objects involved
Which type of diagram do I use, and when?
The immediate question is, “Are these competing or complementary standards”. The answer is that they are complementary and there may be a requirement for relationships between diagrams to connect the systems and business process views.
The table below shows which standard to use for each phase of an implementation. Importantly, both types of diagrams are needed if the implementation is going to be successful. And remember, this is critically important documentation which captures the configuration knowledge of the application. So they need to be linked back to the metadata that is changed because it is used for future releases.
It is fantastic that Salesforce is investing in driving great documentation standards. Whilst not everyone enjoys documenting what we are about to build or what we have built, we all understand the value of walking into a well documented Org.