Once you have initially depicted the different contexts for your stakeholders, as described at Contexts, you will now be able to sort out the things that apply to a stakeholder while specifically found under a given context. Actions are among these things you classify per context.
What are actions?
Actions determine the options at the Work portal which can be launched and executed by a stakeholder whenever these make sense (Bizagi is context-aware).
A configured action results represented as a button that enables stakeholders to create one new record or multiple ones, update them or to start new processes (classified as actions that target a process, a form or a business rule).
While referring to the example on how a Hospital's Emergency Room operates, and parting from having a Doctor stakeholder with 2 contexts (Expired license and Unexpired license), then we may configure:
•If the doctor is in the expired license context, then an action will be available as a button, for him/her to update the information regarding a renewed license.
•On the other hand and if the doctor is in the unexpired license context, then multiple actions are available to send a patient to surgery or request an blood test or other exams.
Though actions can be launched from inside processes (their activity forms), in the Experience design you configure strictly those actions that are visible in the Me menu (e.g while browsing data, following up My stuff, or through Searches).
To configure Actions to be shown within process activities you need to include in the form an Action Launcher.
In order to define actions applicable for each context, hover on the context desired and use the icon to create a new one, while in the Actions tab.
Make sure you give it a meaningful Action name (as this name will be useful for you to identify in Bizagi Studio all your configured actions) and click the icon when finished:
Remember that the actions will only apply (be shown in the Work Portal) when the context that holds it is enabled (i.e. when the Context condition is met).
Once you have defined the action's name, proceed to configure it by specifying what it should do when the user clicks on it:
•Specify in which entity will this action show up.
•Define a label for the button representing that action.
Notice that the icon preceding action indicates that such action has not been fully configured yet (it will not work unless its configuration is completed).
Select an entity from the drop-down list showing all available entities of your data model..
Notice that if the entity in which the action executes already exists, you will see it highlighted for selection (Bizagi performs a search and auto-complete according to the first letters you type in).
Otherwise, inputting the name of the entity will have Bizagi automatically create that entity.
When creating a new entity, you will get a confirmation message so that you are fully aware that you are affecting your data model:
To determine in which entity an action is executed, consider that it refers to that entity where it will be displayed or stored: (i.e. shown the action when I search for vehicles, thus the entity is vehicles. Or shown the action when I browse through my doctors in My Stuff, thus the entity is Doctor).
In the example above, the Doctor will be updating his/her own information, specifically its license renewal information. This means that the action is to be presented while viewing the record of that doctor (information stored at the Doctor entity).
Therefore, the best way to determine the entity where an action is executed is to ask yourself: In records of which entity would you have this action's button show up?
Once you define these 2 settings, click the icon.
Next, define what the action does by selecting if it should either:
1. Start a process: Use this option if you want your action to start a new case of a given process. This option allows you to approach highly sophisticated scenarios, as you may use everything that a Bizagi process uses (e.g, complex BPMN elements, regular forms or start forms, and business rules as well).
Actions that start a process are identified by the icon.
For this type of configuration, you will need basic know-how about Modeling a process in Bizagi.
Refer to the section below on Actions that start a process for further information.
Important: A new process will launch ONLY if the Stakeholder executing it has permissions to create such process, from the Bizagi Studio - Security - New case definition. If the Stakeholder is not enabled to create such process the Action will not display.
2. Open a form: Use this option if you wish to simply display information, or allow the update of such information. This option does not allow you to process business rules in that form, though you may include visual actions and validations for data input.
Actions that open a form are identified by the icon.
For this type of configuration, you will need basic know-how about Defining forms in Bizagi.
Refer to the section below on Actions that open a form for further information.
3. Execute a rule: Use this option when needing to execute a rule (as any Bizagi business rule, in which you can include scripting), and when there's no need to create a process for this action.
Actions that execute a rule are identified by the icon.
For this type of configuration, you will need basic know-how about Modeling data in Bizagi.
Refer to the section below on Actions that execute a rule for further information.
At anytime during this configuration, you may switch to the advanced configuration mode by clicking on Advanced:
For detailed information about this possibility, refer to Advanced configuration.
Click on the Start a process icon and select from the drop-down list the process you want to launch:
Notice you may use the icon to define a new process from this point.
When doing so, define the Process name, select from the drop-down the Application it will belong to and select its process entity from the list of existing entities. or creating a new one.
If you need to define a process entity that has not been created yet, then type in the name of that new entity and make sure you acknowledge that this new entity will be created directly in your data model.
Click Save when done.
Back in the action's main configuration window, note you may use the icon to define the process model for that new process definition (or modify it).
This will automatically open up Bizagi process modeler:
Save the model when done editing and close the Modeler.
Finally, and while viewing the process name and process entity configured, click Save:
Click on the Open a form icon and select from the drop-down list the form you want to launch:
Notice you may use the icon to define a new form from this point.
When doing so, you will be able to include attributes in the Forms designer, starting from the XPath context of the entity you selected on which the action executes:
Once you design the form, make sure you give it a display name in its properties, click Save and close the form.
Finally, and while viewing the name of your form configured, click Save:
Actions related to the Stakeholders' experience design, seen from the Me menu (process action, form action, rule action) are contextualized over a rule. If you require to execute on a form action a connector or an interface that requires mapping inputs or outputs you need a process context, thus it must be associated to a case (Workitem) consequently an application. The form action does not have that context, therefore it cannot be executed.
Click on the Execute a rule icon and select from the drop-down list the rule you want to launch:
Notice you may use the icon to define a new rule from this point.
When doing so and through the Expression manager, you will be able to define a new scripting expression and rely on Bizagi rules API to handle what the action will do/launch:
The XPath context of the rule is the entity you selected on which the action executes.
Once you define the rule and click OK, make sure you click Save back in the action configuration:
Action rules are executed over the entity they are created in, and can only affect the data that is navigable through XPath.
Thus, if an Action rule is created over a Process Entity, even if the Action is shown in My Pendings, it cannot affect the case’s info (Me is not available in those expressions).
A major and powerful feature when using actions, is the smart mapping of data which is automatically handled by Bizagi.
This means that by relying on context-awareness capabilities, Bizagi will load relevant data from where that action is launched (e.g, data from the stakeholder or a particular record), and inject it into the action's target (a process, form or expression).
This happens as long as there is an XPath relation (foreign key using a related attribute) in that target's entity that connects to the stakeholder or particular record.
Assuming that an action is executed from the Customer entity, where a Send promotion code process is started, then for the following model Bizagi would automatically map the Customer information to the Send promotion code entity, because there is a direct XPath to Customer in the action's target entity.
Even though data mapping is done automatically by Bizagi, in sophisticated scenarios where there are no direct relationships in the data model, but a remote XPath access more than 1 entity away instead, you may also choose to influence the mapping logic by explicitly including Hints.
Hints will suggest Bizagi how to locate certain information whose access path (or optimal access path) may not be as evident as in simpler data model scenarios.
You may also select which information gets to be automatically mapped into the launched action (be it targeted to a process, form or expression).
For more information about configuring hints, refer to Hints.
Hints are designed to help out with data mapping when starting new processes.
This means that you may only use hints for entities which are process entities.
At anytime you may move actions from one context to another by dragging and dropping that action:
You may also delete unused actions by clicking on the 3-dotted option and selecting Delete action:
When deleting an action which uses an entity that is not used anywhere else in the project (has no dependencies with other Bizagi objects), the target entity by itself will also be deleted.
Managing entities and diagrams
Additionally and in order to manage the underlying entities of actions, you may rely on a different view which presents actions grouped by entities:
For more information about this view, refer to Manage entities while viewing their actions.