As a facilitator, your role is not to rule, but to observe and guide. The fewer rules you will set and enforce, the better your workshop is going to be. After the ice-breaking, some people will start putting stuff on the wall, and other people will start asking questions. At this stage, there are a few things to keep in mind:

• People tend to ask questions to the facilitator as they see him/her as the meeting organizer and therefore as a person who has more information and authority. As a facilitator, direct them and their questions to other people in the room, in particular to those people with answers, whom you have invited.
• There will be some confusion about domain events, especially if your audience is not native English-speakers and the term domain event can be seen as technical (it isn't). As a result, there might be some who keep putting stickies with features they desire to have (like payment processing or shopping cart), or imperative actions (like process payment or register customer). This is the facilitator's job to prevent this and explain once again that at this stage the goal is to describe the flow of domain events, which are the facts of life and cannot be undone, removed, or changed.
• Apart from what is mentioned above, there are no real mistakes or errors that people can make, at least at the level of notation. Do not try to de-duplicate events or generalize, do not discourage people from doing stuff by saying they are doing something incorrectly.

Usually, these three tips help to drive the workshop from the organizational point of view. But, since we are dealing with people, there are always some behavioral and personal aspects. Several things usually happen and which are essential for the facilitator to observe and sometimes interfere.

First, be prepared for complex discussions. If there will be no discussions, then either the domain is too simple, or you got the wrong people, or there is something else that prevents people from speaking up. Disputes are inevitable since every person in the room has their point of view on the domain. Even developers already form their opinion after they got the initial idea or maybe also read the specification. The critical part here is that a developer needs to ask questions. There should be no assumptions left about what happens and how it happens. It is the facilitator's job to encourage developers to participate since some of them are introverts and don't really like being in an open discussion. But since our goal is to give developers a better understanding of the domain, they need to participate.

Try to pay attention to edge cases. People always prefer to model the happy path, when no exceptions and errors occur. We ever need to keep in mind that one event is a consequence of some other event under certain conditions. Yes, there could be some straight flows, but they aren't commonplace, especially if we are talking about business. For example, payment processed can logically lead to order paid, then order shipped and then order delivered. But, what if the payment has failed? What is the payment amount does not cover the full order total (partial payment)? What if goods aren't available in stock although we count that they are? What if the parcel is lost in transit? All these things can happen and will happen. For developers, they might seem complicated, and usually, they don't know how to deal with these situations other than throwing an exception. But the business often has procedures in place to fix most of these situations, and these fixes can and should be modeled.

Second, discussions about edge cases almost certainly will create some ambiguity and uncertainty because not all exceptions are covered by business processes or people that you have available for the workshop aren't dealing with such situations. If there are several domain experts in the room, you might face them disagreeing and arguing with each other. For your short workshop, such circumstances are counterproductive. Therefore, if you observe that some heated discussion takes place or at some point, there are too many puzzled faces, and no one can bring clarity to something—you can identify a hotspot. At this point, you need to introduce one more element to the notation. Hotspots are usually marked by bright sticky notes, for example, Alberto proposes bright pink. So, you might have something like this on the wall:

Identifying and characterizing hotspots allow to postpone decisions and cut off arguing, effectively letting the group to move forward and not to get stuck. You might find your wall full of hotspots by the end of the workshop, and this is entirely normal. This indicates that people that you have invited either need to come to some agreement about handling some situations, or you need to speak to someone else and collect missing information. Hotspots deserve close attention, but it should be done after the workshop has finished. Try to cut off unproductive discussions and going in circles by putting a pink sticky and asking people to move on.

The third thing to keep in mind is that when you have a few domain experts who specialize in different parts of a larger domain, you will observe them grouping together by functional specialization area, forming islands, or cloud of events that barely connect to other islands, produced by other groups. This is very interesting to observe and essential to catch since you might be witnessing the first draft of your context map. We will discuss context maps later in the book. Do not discourage people from doing this and go with the flow. Pay attention to how these islands will interconnect. Usually, a minimal number of events belong to more than one group of domain events.

Then finally, there is a chance that your business works with organizations and systems that are out of your control. Such entities can be called external systems and need to be put on the model. There are domain events that can go to such systems and also you might receive some events from external systems too. This introduces the new element in your notation and in Alberto's color scheme external systems are visualized using large pastel pink sticky notes:

Remember about the unlimited modeling space and ensure that people do not try to save space because there is not too much space left. Reorganize events to make more space or, most comfortable, put more paper to the wall. Remember that paper is cheap and knowledge is precious. You don't want to lose understanding because someone is saving space on paper.

When people get out of ideas, and there will be some awkward moments of silence, you might need to ignite the fire again by offering to look at the model from a different perspective. There are at least two relatively easy ways to enrich the model by something that went missing. First, ask people to traverse the timeline backward. Very often something that was considered not significant was not put on the wall, but this thing is essential for the next thing to happen. For example, someone might have forgotten that a packing list needs to produce before the order is shipped. Another technique is to identify where the business creates value. Trivially, try following the money. Very often developers get into discussing fancy nice-to-haves and forget that the business needs to earn something to pay their salary.

Finally, as mentioned before, keep in the time in mind and have at least one break per hour. Keep your promise and don't get overboard, maintaining people for longer than they have planned to stay. Considering you followed by advice and bought some fruits and drinks, some might even desire to continue but this is up to them to decide about your workshop will take longer than expected.