4 minute read Salesforce UPN for Business Analysts launched Home » Blog » Salesforce UPN for Business Analysts launched Home » Blog » Salesforce UPN for Business Analysts launched 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. In summary 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. Sign up for our newsletter Subscribe to our newsletter to stay up-to-date with cutting-edge industry insights and timely product updates. Back to News Share Ian Gotts Founder & CEO 4 minute read Published: 26th June 2021 Post navigation Drawing Salesforce Diagrams using Elements.cloudPrevious3 things to consider as you start building Salesforce DiagramsNext