At each level of abstraction, activities should be similar in scope and importance. For instance, avoid having an activity called “plan the party” that exists at the same level of abstraction as “open the door.” It might make technical sense, but it does not make business sense, and the process diagrams are meant to be readable by business users.

Leading indicators of mismatched activity granularity are the string of pearls and constellation patterns.

Remember that an activity in the process definition is a step in a process that can be implemented as a subprocess or a task. The definition or title of any task in a process definition should stop at task granularity. A task activity is a unit of work that a single participant (human or system) begins with the intent to complete.

An activity is a unit of granularity (step) in a process that has a goal that can be expressed as a singular outcome or output. It can be implemented as a task (human or system) or a subprocess. If it can contain multiple steps (screens in a workflow). These steps are not process steps. Lastly, a task can be a subprocess that is implemented as another BPD (one level lower) and follows the same guidelines as a parent BPD.

An activity should not be named after the context-less action being performed, like “look over application” or “add details.” Rather, it should be named to reflect the goal or output or result of the activity, such as “approve contract” or “adjudicate claim.”
Here is an easy formula to remember for naming your activities:

Activity name = action + entity
Or
[action verb] + [business object]

Avoid vague action verbs such as “process and perform [step].” Instead use action verbs that indicate a result or output. Use specific terms that business users recognize (even if they might be vague to others), and explain the terms in the activity description if necessary.

Inputs and outputs at the BlueWorks live level should be restricted to collections of business objects, such as candidate or claim, rather than individual fields that make up these collections.

Business entities should be defined from the business object model. When defining these entities, avoid specifying state for the entity (for example, signed contract) and specifying other qualifiers that are properties of the entity.

The system lane is meant to represent the BPMS and all of the external systems with which the BPMS interact. It can include activities performed by external systems but orchestrated by the BPMS.

The system lane should never include human activities or any activity that contains human interaction (screens). Always strive to avoid the string of pearls pattern in the system lane.

If there is much activity between the system lane and a participant lane, it could be because there is a low-level granularity (workflow and screen flow) being captured, where a few sentences in the description might suffice.