Key Concepts¶
Note
An OU (organization unit) refers to a collection of users, resources, applications, and services, and is the top-level account management unit in Application Portal.
Process Models¶
A process model is a graphical representation of the flow of a business process and defines the specific activities (tasks), events, decisions, and participants involved in the process. In other words, it is a blueprint for processes to be executed. Process owners use process models to standardize common business processes, or to automate and facilitate its execution.
Note
A process model is unique to the OU where it is created. You can however share the process models with other OUs by using the export and import function.
Processes¶
A process is a running instance of a process model. In other words, it is a snapshot of the process model and provides guiding steps for execution. Once started, a process generates tasks and triggers events during its execution based on the flow defined in the process model. Different processes based on the same process model can have different outcomes depending on the steps that were taken during process execution.
Activities (Tasks)¶
An activity is a piece of work that needs to be executed as part of a business process. It is defined in a process model and is generated automatically when a process is executed. It can be a task that requires user interaction, such as filling in a form, or an automated service task, such as the execution of a predefined script or sending of a HTTP request.
If a task requires user interaction, it must be assigned to the process starter, a specific user, candidate users, or candidate user groups. Candidate users and candidate user groups are a list of users or user groups assigned with the rights to execute a user task. One of the specified candidate users, or a user of the specified candidate user groups must claim the task before executing it. The user becomes the assignee of the task only after claiming it.
On the other hand, if a task is assigned to the process starter or a specific user, the user automatically becomes the assignee of the task and is the only person who can execute the task.
Events¶
An event is something that happens during a process. Except for the None Start Event, events generally do not require user interaction. All processes must start with a start event and end with at least one end event.
Forms¶
A form is used to capture user inputs as part of the None Start Event or the User Task. Process owners can design custom forms to be displayed during process execution.
Runtime Statuses¶
Runtime statuses show the execution progress of a process or a task. The runtime statuses for processes and tasks are as follows:
Process: In Progress, Completed, Terminated
Task: In Progress, Unclaimed, Completed
Custom Statuses¶
Custom statuses are defined by process owners to precisely communicate the different stages of a business process based on their business needs or organization standards. Process owners can configure a process to show different custom statuses at different stages of the process.
Variables¶
A variable is a data storage unit used to capture business data that is used by process elements in a running process. A process variable is identified by a unique name, which enables the variable to be referenced in UEL expressions or APIs. The name is defined by process owners when building process models, and it must be unique within the process model.
For example, the following figure shows a firmware upload process, where the review result of the firmware upload request is stored in a variable named “Result”. Subsequently, the downstream connectors contain conditions that read the “Result” variable to determine which path the process should take. If the result is “Rejected”, the process moves through the “Rejected” path and reaches the “Review approval outcome” task, where the value in the “Result” variable is read and displayed.
Keys¶
A key is a unique name for identifying system objects that are created in BPM, so that these objects can be referenced in UEL expressions, scripts, or APIs.
Views¶
A view is a way to organize and display the properties of running processes in a list. BPM provides a default view that displays a list of running processes for all process models. Process users can also create custom views to display a specific set of process properties that is important to them. Each custom view can display only the processes of a specific model.
Sandbox Environment¶
A sandbox environment is the environment where process owners can validate the functionalities and correctness of a process model without impacting the production environment. Process owners can impersonate different users in the sandbox environment to ensure the process functions correctly for all users.
Production Environment¶
A production environment is the actual environment where processes and tasks are made available to process users for execution.