All Collections
How to...?
Process mapping with Elements: Methodology, shapes and hierarchy
Process mapping with Elements: Methodology, shapes and hierarchy

UPN; Universal Process Notation; How to map out processes; Where are other shapes?; Where are decision boxes?; BPMN; Flowchart shapes

Ksawery Lisinski avatar
Written by Ksawery Lisinski
Updated over a week ago

The Elements application supports the UPN process mapping methodology. It is a hierarchical, simple-notation approach to process mapping that allows for better communication, shared understanding and better insights. 

This article outlines the principles of UPN mapping. For a practical guide on how to map out processes using our software check out this article

Article outline:

  1. UPN shapes: why use just one shape?

  2. UPN hierarchy

  3. UPN value summarized 

UPN shapes: why use just one shape?

Because the Elements Catalyst app is a UPN process mapping tool we do not support multiple different shapes (or BPMN shapes). This section explains why. 

Most people envisage multiple different shapes when they think of process mapping:

The multi-shape methodology is called a BPMN, or Business Process Model and Notation, and the latest official manual on how to map processes using this technique (version 2.0, 2011) has 538 pages... BPMN is essentially a structured graphical programming language, often employed in various softwares to design workflows and automations without using any code. It is extremely useful but because of the complexity and sheer number of shapes and variants it is understood by very few people.


In contrast, the principles behind UPN were first published back in 2004 in a book called Common Approach UnCommon Results. Nimbus released this as an open standard in 2008 called UPN (Universal Process Notation). This has been updated by TIBCO after the acquisition of Nimbus and the latest copy of UPN is available here. This manual, in contrast, has only 5 pages...

The UPN process notation can be summarized using the picture below:

  • Every action, no matter the context of type, is represented by a rectangular shape (activity). In it, we write WHAT happens. 

  • The flowlines (arrows) coming into the activity represent the triggers, or events that cause the activity to happen. In other words, these flowlines represent WHEN the activity happens. 

  • The flowlines (arrows) coming out of the activity represent the desired outcome (or outcomes), so the WHY the activity happens in the first place. 

  • You can add multiple resources to any activity, i.e. WHO is involved in performing any activity (you can also add RASCI tags to differentiate specific roles played by different resources).

  • To capture any additional details about how the activity is performed you can either create a drilldown process or attach documentation - the HOW

Using this notation, process diagrams are much simpler to understand by people, even the ones who are not very familiar with process mapping. It does not require people to learn a new, often complex, new language and helps avoid any misunderstandings between people with various levels of proficiency in BPMN. 

UPN hierarchy 

The other fundamental principle of UPN process mapping is hierarchy. Process diagrams are not meant to be stand-alone documents, nor to be huge and complex. In the first case we lose context of how a particular process fits in with other operations, in the latter we make them too big to understand.

Ideally, a single process diagram should have less than 10 activities in it (though there are exceptions). The more activities you have the more difficult it is to understand the process at a glance. 

These activities should all describe events at the same level of abstraction, e.g. when mapping out the business process at the highest level of abstraction the sales, finance, product development, HR and similar activities would need to have a single activity each. Then, to show more details you would need to create sub-processes for each business unit. 

Ideally, you would have a single map outlining all of your organization's processes. There is no limit to the number of sub-processes your map can have. Each process can have multiple sub-processes, which in turn can have multiple sub-processes. 

UPN value summarized 

The power of UPN is its simplicity because:

  • Any end-user, no matter what level of seniority, background, or discipline can understand it. It is lingua-franca for process.

  • Diagrams are tighter* so that they fit onto a single screen (laptop/tablet) which means they can be accessed at the point of need.

  • All operations can be captured in a single map - the hierarchical process approach allows for each process to be easily consumable while making sure the context is not lost.

*take any process drawn using flowcharting, swimlanes or BPMN notation and a UPN diagram will be smaller. Fact. Jim Boots in his book “Boots on the ground”, which chronicles his experiences of running the BPM program at Chevron, wrote a chapter with a worked example to demonstrate the point.

And finally, if you haven't already watched this short introductory video...

It's 9 mins long and will save you a LOT of time...

Did this answer your question?