BPMN Best Practices - Pool naming, choreography artifact dependencies, and alikes


I have a question that has been bogging me for a while.

Since most of the time I model business processes that pertain to the same system, I have the habit of naming the pools the name of the business processes.

I’ve started to model choreographies and I’m running into some issues to reconcile my strategy with VP data model.

Here’s a few questions:

  1. does VP recommend naming pools with the process name? If not, what do you recommend the naming strategy to be? Other suggestions?
  2. (while we are on pools) what are the benefits of associating a participant with the pool properties? Do the “roles” and “participants” get suggested when building processes? Other?
  3. on the “Choreography Task Specification” I don’t see any message flows, even though I have a message flow in my processes. What do I need to do to list a message flow?

Also, I’ve been trying to get some help online, and most of the choreography “how tos” and Youtube seem to be from previous versions of the tool.

Any help will be most welcome!

Thank you

1 Like

PS: I am not an expert at BPMN

about question 1 & 2:
As I know, a pool is a view of a participant.
But on VP’s Business Process Diagram, we allow user to create a ‘pool’ without creating a participant.

about question 3:
Choreography Task can associate to 0…N participants (means VP’s Pools).
Reference to the following image, you can select the message flows from the associated pools.

Hey Peter.

Thank you for your reply.

Is there a way to show the “message icon” (envelopes) on the diagram?bpmn

Thank you.

I know I’m late to the discussion, but still hope I can add something useful. I’m also not a BPMN expert but I do know my way around the concepts.

Generally speaking VP follows the official specification first. This applies to basically every modelling language such as BPMN, UML, etc. So: the specification as laid out by the OMG (Object Management Group). However, as @peter.wong also mentioned, VP also extends on those specifications. So if you want to you can overrule certain aspects. Of course that could result in your diagram being not fully compliant with the official specification, but quite frankly I think that’s not always a bad thing.

So… pools (also called swim lanes) are mainly used to organize and categorize your activities. You probably know that already, but I just want to provide the complete description. A pool usually represents a participant whereas a lane is used to further structure the activities. However, the whole “participant” can be used very broadly, for example by using the so called “black box” function.

This also implies that it is important to use a descriptive name for the pool. But what that is heavily depends on your diagram and the situation. Personally I’d keep focussed on what the pool should represent: a participant. So name it accordingly, there isn’t really a set standard. My suggestion is to always ensure that it’s descriptive.

And this is also where it gets interesting because the lanes within a pool are a total free for all. There is nothing about a lane naming scheme in the official specification.

That’s why I think a good strategy is to use a broad but descriptive name for your pool and if you need more details then simply add a lane which name can then provide that extra detail (also: the lane itself can be used to group your tasks as such).

I know this is a bit vague but I still hope it can give you some ideas.

Well, to be honest I seldomly use this approach myself because I consider the pool to be the actual participant. However, not a physical one. Also keep in mind that this is just my own personal take on all this.

A pool is usually a large entity. For example: “Customer” which could have several lanes to further detail its different aspects. I could imagine “Administration”, “Management”, “Procurement”.

So what if you have a contact person at this customer? Then it makes sense to add a participant, and then use that to store information specific for your contact person. So if you need to address them in another diagram you don’t have to pull the full customer company into it, but can limit that to just the participant: your contact person.

While working on your diagram open the view tab, select panes and open the Model Explorer. There you’ll find the model element for the participant, ready to be used in other areas of your project.

That’s usually what I use (but as said: I use this seldomly).

You mean a send task?

Those are provided within the specific task types. Either add the specific type or right click and find the “type” section in the menu where you can change types.

Ignore this last section please and instead check out Antony’s post below mine.

I also learned something new there :wink:

Hope the other parts can still help!


To show the message envelope on the diagram, let’s take the “Provide solutions” choreography task as an example:

  1. You should have first drawn something like this to model the participants (visualized as Pools here) and the message flow between them.
    pools and messages

  2. Open specification of the message flow to create a message for it, this message would be the model element of the envelope shape, so name it “Solution” as in this example:

create message

message specification

message created

  1. Now this step is not related to your question, but I guess you would wonder why the message icon is not shown in the message flow after we defined it. If you would like to show it, select the presentation option like this:

message icon shown in bpd

  1. Then we can back to the choreography task, I assume you know how to draw the choreography task and select the participants already, so you should already have something like this:

choreography task

  1. Mouse over the choreography task until you see the resource catalog icon, drag it over the empty diagram area, you should see the message envelope icon:

resource catalog message

Note: if you are still using the classic resource centric interface instead of resource catalog, you should instead drag the resource named “Association -> Message”.

  1. You should be able to select the owner message flow of the message you created above, or you may select the top two options to create a new message flow instead:

select message