<< Click to Display Table of Contents >>

Navigation:  Bizagi Studio > Experience design >



Defining stakeholders is the first step to make the most of Experience design in Bizagi.

Through Experience design and stakeholders, you will be able to empower knowledge workers, present a personalized user experience, and use contextualized capabilities, among others.

For general information about these new concepts, refer to Experience design.


What is a stakeholder?

In project management, a stakeholder is an entity (be it an individual or group), that has an interest in the project. For example, an employee, manager, customer, or a sponsor.

For Bizagi, a stakeholder is a knowledge worker who will be logging in to the Work portal to carry out daily work (e.g. complete pending activities), or similarly as in project management, an end user who simply logs in to interact with the system and its information (e.g, view and follow up any case or structured information, or start new cases).


Because overall, end users are bound to having diverse interests in Bizagi, part from a different context, and not necessarily have the same use for certain options in the Work portal, stakeholders are how these end users are classified into groups, precisely according to how they interact with the system.


Taking as an example how a Hospital's Emergency Room operates, in which upon the arrival of a patient, nurses and doctors interact with each patient's case differently, two groups of end users are immediately identifiable as stakeholders:



A doctor is primarily interested in examining and treating a patient, by relying on his/her expertise to make important decisions that change significantly the course of action in a process, such as requesting certain types of exams (i.e the doctor is a knowledge worker).

A relevant process for the doctor is the possibility to send a patient for immediate surgery, based on a specific condition/criteria applicable to that patient.

Data which is useful for the doctor to browse and follow up, include the lists of all patients currently under his/her care.

Possible easy-access searches that a doctor uses best, include the ability to locate an available surgery room.





A nurse is primarily interested in registering patient details and performing an initial examination (i.e a triage).

A nurse needs to update information regarding the patient's history anytime (how the patient's condition evolves).

Data which is useful for the nurse to browse and follow up, includes his/her planned working shifts.

Possibly and in a simplified example, a nurse does not need a predefined search option.


Therefore, by defining these 2 above stakeholders and noticing how the doctor and the nurse move in 2 different contexts, you may focus Experience design separately so that the Work portal presents, suggests and validates for, the options each stakeholder need and use best.




Why define stakeholders?

One of the key features in the Experience design, is being able to achieve personalization in the Work portal for your different groups of end users.  Through personalization, the different end users will have a unique experience, by finding a smart portal that is fit for their needs.

Stakeholders act as decision makers that can launch processes, update data records (without being involved in any process) and link processes together to create powerful cases.  They can also view, order, sort and navigate data that belongs to them (i.e. their credit cards, their appointments, their cars, their tickets).


The above options are presented in the Work Portal's Me menu:

The relevant and most common actions that the specific stakeholder needs to execute (i.e. launching a process or updating certain data anytime), while having the system manage contextualized information.

Listed data which is of primary interest to that specific stakeholder; typically the collections belonging to (or bound to) that stakeholder (i.e, "My stuff").

Searches applicable to that stakeholder.


In addition to the above, defining stakeholders allows you to clearly identify knowledge workers in unstructured processes, and grant them the possibility to start other processes, dynamic plans and in general, to best address scenarios where there's the need to make important decisions on the fly (based on data).


The following diagram illustrates how through stakeholders you make the most of knowledge workers, a personalized experience and contextualized in Bizagi:





Defining stakeholders is entirely optional.

When no stakeholders are defined, all end users are simply not classified into groups, nor routed separately for a unique experience.

End users would all use the classic Bizagi Inbox, without the Me menu being presented to them.


Furthermore, you can classify as stakeholders only those end users which are considered knowledge workers and require that degree of personalized and contextualized experience, while having other end users remain unclassified.


Stakeholders quick facts

These concepts apply to stakeholders:

A Bizagi end user can be grouped into one or more stakeholder definitions, or none at all.

The Me menu (with further options in it), is presented differently for each stakeholder. Other Work portal options and menus such as the Inbox, are always available and not differentiated by stakeholder.

Stakeholders end up being embodied as entities in Bizagi's data model. This means that each stakeholder has its separate/specific attributes or collections that other stakeholders may not have.


Defining stakeholders

In order to define stakeholders, first make sure you have moved into the Experience design view by clicking on the Experience option at the ribbon.

Note that the first time you go into the stakeholders definition, you will see a help box displaying a brief description on what a stakeholder is.




Create new stakeholders by clicking the Stakeholders_00 icon.

Since stakeholders are embodied as entities, define the Display name, Name and Description, similarly as you would do for any other entity in Bizagi:





Note that same advanced definitions as in entities apply, such as Source and Key, for which you may leave the default values.


Click Next when done.

Define attributes for the stakeholder by using the Add button and entering their Display Name, Name and Type:





Currently, relationships to virtualized entities are not supported, it is necessary to previously related the entity before being virtualized. For more information, please refer to Data Virtualization.


When the Stakeholder is created Bizagi automatically creates an attribute called associateduser as a foreign key to the WFUser entity. This attribute is used to link an instance of Stakeholders to an actual user of your project.

You DO NOT need to create the WFUser attribute, Bizagi will do that for you. The WFUser relation will include default attributes such as full name, email address, among others that are not needed in the stakeholder entity.



Note that at this point, you do not need to define attributes that are collections if these are intended to be used for the My stuff section (e.g, no need for a collection to list all patients currently under the doctor's care).


You may also click Next in order to define the Display attribute for the stakeholder, though it is entirely optional and you may leave defaults at this point.


Click Finish when done.

The new stakeholder definition will appear and you will be able to edit its details (its entity definition or its representative icon).




To edit its representative icon, or define a new one for the first time, click the Update work portal icon and choose a predefined icon for its default representation:




Click OK after selecting one icon.

Notice you may define additional stakeholders as needed, which will be also listed in that screen:




At this point, you will have initially depicted the stakeholders of your Bizagi project.

Use the Search stakeholder field to look up for any created stakeholder by typing any of letters contained in its name.


Though for a complete definition of the Experience design, you will need to continue specifying further detail of these stakeholders so that each have the following features well-defined:

Contexts: useful to establish conditions or states in data, in order to define when can a stakeholder perform certain actions.

My stuff: useful to present those "data sets" that belong to (or are bound to), that particular stakeholder.

Actions: options represented as buttons that can be launched by a stakeholder whenever these make sense, to create one new record or multiple ones, update them or to start new processes.

Relevant to me: shortcuts to the most commonly used processes that launch new case instances through a one-click option in the Work portal.

Data search: data queries that display filtering information by a given criteria, and afterward potentially launching actions for the matching records.




Nurse and Doctor icons taken from