Once you have initially depicted the stakeholders of your Bizagi project, as described at Stakeholders, the second step is moving deeper into their definition so that you consider the different contexts each stakeholder has.
Using contexts is as powerful as it sounds: not only will each stakeholder be able to interact differently in the system, but the same stakeholder will be able to perform different actions according to a given situation or current state.
What do contexts imply?
Contexts imply that any stakeholder will have use for different set of options available at the Work portal in general, according to their underlying data.
Underlying data of that stakeholder will typically reflect that such stakeholder is under a given state or with a specific skill (e.g, a VIP customer), or found in a given moment in time (e.g, working in a night shift). A Boolean condition defines each state, thus, each context will have a condition that defines when it is active or inactive.
In order to leverage an optimal experience design, it is expected for a stakeholder to rely on multiple contexts, so that Bizagi Work portal presents the applicable options that such stakeholder may carry out while in each specific and well-defined context.
Going back to the example on how a Hospital's Emergency Room operates, the following context is applicable to the Doctor stakeholder:
Whenever the doctor's medical license is expired, they may update his information to include the renewed license, while they may not operate a surgery.
In order to define contexts for a stakeholder, click on that particular stakeholder.
For a stakeholder, you will see that in its experience design definition, you will be able to define Actions, My stuff and Searches.
You may create contexts in any of these three tabs, since the created contexts will apply to them all.
Note that each stakeholder already has a default context, named Always available, which comprehends everything that the stakeholder may use at anytime (represents no specific context at all).
Create a new context by clicking the icon and name the context with a meaningful title:
Click the icon to define its Context condition.
Notice that an orange icon indicates that such context doesn't have a condition configured. A context will not work unless its configuration is completed.
The condition that defines the context is a Boolean expression, just as the ones which evaluate conditions in gateways concluding if a statement is true or false.
Boolean expressions that define contexts are not reusable for any other purpose or element.
Similarly and whenever a context is deleted, its defining Boolean expression will be deleted as well.
Back in the available contexts, notice how a context with a condition configured shows a green check mark icon.
You may create additional contexts while ensuring their Boolean conditions define them uniquely, though not necessarily exclusively (a stakeholder can have two or more different active contexts at the same time).
At any time you may also delete unused contexts by using the Delete context option (not available for the default Always available context):
At this point, you will have created contexts in order to classify the options available for a stakeholder.
Though in order to move forward in the Experience design definition, you will need to continue specifying further detail in the different contexts so that each has the following features well-defined:
•Actions: useful to determine exactly what a stakeholder can do or launch when found in each context.
•My stuff: useful to present those "data sets" that belong to (or are bound to), that particular stakeholder, while applicable to a context.
•Data search: useful to provide search options in data commonly worked on by a stakeholder, while applicable to a context.
•Relevant to me: useful to define which actions you want to be suggested to stakeholders through a one-click option in the Work portal.
Doctor icon taken from http://dapinographics.com/projects/medical-icon-set/.