This scenario walks you through the main steps for setting up a business process in BRIX. You will create a process, define its context, model the process diagram, configure tasks, their forms and transitions, check the diagram, and publish the process.
Business processes are used to automate repetitive actions and work stages, such as approving documents, processing requests, checking data, and assigning tasks to employees.
This scenario uses the Purchase Request Approval workflow. This makes it easy to see the sequence of actions and the settings you need.
This scenario explains the overall setup logic and does not replace detailed instructions. At each step, you will find links to help articles with detailed descriptions of the steps and required parameters.
Before you start setting up
Before you start, think through the architecture of the future business process and structure its logic. Define:
- Automation goal: The specific problem or task the process is designed to solve.
- Process start: The specific event or user action that initiates the workflow.
- Route and stages: The sequence of steps an object (such as a request or document) follows and the order of required actions.
- Participants and roles: The team members or user roles responsible for each stage.
- Context: The specific data and information users need to complete their tasks.
- Transition logic: The conditions that determine routing paths and which actions should run automatically.
- Process completion: The final outcome or result once the workflow finishes.
Users included in the Administrators.
Step 1. Choose the setup level
Before creating a business process, choose the level at which it will be set up. This determines which data is available to the process and its scope in the system.
A process can be associated:
- With an app if the process is intended to work with items in a single app. For example, in the Purchase Requests app, you can model an approval route for each request within the app.
- With a workspace if the process connects work across several apps within a single functional workspace. For example, in the Purchasing workspace, the process can use data from the Purchase Requests, Suppliers and Products and Services.
- With the company is the process combines data and tasks from different workspaces in the system.
Начало примечание
Useful articles:
- Business process design describes what a business process is and why you should automate working with it.
- Business process modeling in BRIX describes how to choose a level and create a process.
- Workspace-associated business processes describes how to set up a process that connects several apps within a workspace.
- App-associated business processes describes how to set up a process that processes data from a single app.
- Example: Associate a process with an app describes how to go through all the steps of creating a process using an app-associated business process as an example.
Конец примечание
Step 2. Create a business process
Create a business process at the selected level. In our example, the Purchase request approval process is added at the app level of the Purchasing, because it processes items from this app.
After you create the process, the business process designer opens. Here you can configure the process diagram, including tasks, transition conditions, notifications, automatic actions, and more.
Начало примечание
Useful articles:
- Business process design describes what a business process is and how to create one.
- Business process modeling in BRIX describes how to open the designer and start modeling a process.
- Process designer tabs explains where you configure the diagram, context, forms, scripts, and process parameters.
Конец примечание
Step 3. Define the process context
The process context consists of variables used while the process is running. For example, in the Purchase request approval process, you need the following data: request, initiator, amount, comment, files, manager, and approval result.
You can display this data on task forms, use it in transition conditions, and save it in the process instance record.
Начало примечание
Useful articles:
- Context tab describes how to configure process variables.
- System data types explains which data types you can use in settings.
- App data type describes how to use app items in a process.
Конец примечание
Step 4. Build the process diagram
The diagram defines the sequence of actions in the process. Add the main process stages and connect them with transitions.
For example, the Purchase request approval process can include the following stages: send the request to the manager, approve or reject it, send it to the purchasing department, complete the purchase, and close the request.
Process modeling usually requires the following elements:
- Swimlanes represent process participants who are assigned tasks.
- Tasks represent actions performed by employees.
- Transitions and connectors connect process stages.
- Gateways represent conditions that determine which branch the process follows.
- Events represent points where the process starts, ends, or waits for a specific action.
Начало примечание
Useful articles:
- Swimlanes: how to assign user roles in a process.
- Task: how to configure an action that an employee must perform.
- Connectors: how to define the order in which actions are performed.
- Gateways: how to configure route selection logic.
- Events: how to add start, end, or wait events.
Конец примечание
Step 5. Configure tasks and forms
For each task, define the assignee and due date. Then configure the task form: the data users will see and the available action buttons.
For example, in the Approve Request task for the manager, you can display the purchase description, amount, and contract, and add the Approve and Reject actions. In the Process Request task, a purchasing specialist can enter supplier details and the result.
Начало примечание
Useful articles:
- Task: how to configure the task name, assignee, due date, and form.
- Forms tab: how to create and reuse task and start event forms.
- Connectors: how to configure buttons and transition conditions for a task.
- Access permissions in swimlanes: how to give process participants access to its data.
Конец примечание
Step 6. Configure conditions, automatic actions, and statuses
After configuring the main diagram, add branching logic, automatic actions, and statuses if they are needed for the process.
Conditions and branching
Use conditions when the route depends on input data. For example, the manager approves requests up to a certain amount, while the manager and CFO approve requests above that amount.
Начало примечание
Useful articles:
- Gateways: how to route a process through different branches.
- Connectors: how to configure connections between process elements.
- Connector use cases: how to use connector conditions.
Конец примечание
Automatic actions
In addition to user tasks, you can configure automatic actions to perform technical steps without employee involvement.
For example, after a request is approved, you can configure a notification to the initiator, create a related item, change the request data, or start the next process.
Начало примечание
Useful articles:
- Create App Item: how to create an app item during a process.
- Edit App Item: how to change the data of an app item.
- Notification: how to send notifications to process participants.
- Start Process: how to start another process from the current process.
Конец примечание
App item statuses
If a business process is linked to an app, you can configure automatic status changes for its items. This lets users track the processing stage of a request, document, or other item.
For example, a purchase request can have the following statuses: New, Pending Approval, In progress, Completed, Rejected.
Начало примечание
Useful articles:
- Statuses tab: how to configure statuses in the business process designer.
- Status field: how statuses are used in an app.
- Manage Status: how to change an app item's status in a process.
- Example: Set up statuses and process monitoring: how to define stages and track them using a specific business process as an example.
Конец примечание
Step 7. Check and debug the process
Before publishing, check the process diagram for logical errors, such as a missing end event, an incorrectly closed gateway, incorrect transition conditions, or undefined assignees.
Then run the process in debug mode. Go through all the steps and make sure the route works correctly: tasks are assigned to the right employees, forms are clear, conditions and automatic actions work as expected, and statuses change.
Начало примечание
Useful articles:
- Validate process logic: how to analyze the process diagram and identify errors.
- Process execution errors: what errors can occur during process execution.
- Debug a process: how to check a process before making it available to users.
Конец примечание
Step 8. Publish the process and monitor it
To make a process executable, you need to publish it. After publication, users can start the process; all the tasks, notifications, and automatic actions will run according to the configured diagram.
Any subsequent changes to the diagram must be published again. This creates a new version of the process.
To monitor execution, use the process instance summary page and monitoring tools. You can track current tasks and their assignees, completed stages and instances, as well as any errors that occur.
Начало примечание
Useful articles:
- Settings tab: how to configure process launch, the name template, the instance record, and other parameters.
- Publish a business process: how to publish a process and apply changes.
- Process monitor: how to monitor process status.
- Error monitor: how to find process execution errors.
- Instance summary page: where to view process instance data and progress.
- Business process performance indicators: how to configure and use process metrics.
Конец примечание