# Start Process

> [HTML Version](360012266792.html)

**(start-process-1.png)**

The **Start Process** activity is used to decompose a process diagram and increase its readability. It allows you to call a nested process within the parent process.

A nested or child process (also called a subprocess) is an independent business process described separately. All the conditions for execution are set within the process: participants, tasks, events, etc., so you can edit it without having to modify the main process.

When a nested process starts, its name appears of the [instance summary page](360012498891.md#history_tab) of the parent process, on the History tab. Click on the name to open the page of the nested process and track its progress.

By adding the **Start Process** activity to your process, you are basically adding a link to a complex task that will be executed as a subprocess. You can add several of such subprocesses to the main process.

Also, you can set it up to launch separate process instances for each app item sent to the main process from the nested one.

There are also [other ways to start a subprocess from a parent process](start-subprocesses.md).

## How to use the activity

For illustration, let’s use the the **Job requisition** process as the main process. During its execution, as soon as a candidate is approved, the **Onboarding** subprocess starts. 

**(main_process_1.PNG)**

The **Onboarding** process is modeled separately. All the conditions are set within the process: participants, tasks, events, etc. The process diagram looks like this:

**(360020170691-mceclip0.png)**

If candidates go through multiple interviews and recruit tests during the selection process, you can remove these steps from the Requisition process and create another nested process instead. This will make the diagram of the parent process easy to read, and candidates will be interviewed and reviewed within a separate process.

## Set up the activity

To add and set up the activity:

1. Open the diagram of the parent process.

2. Drag the **Start Process** activity to the diagram and place it where the nested process should be started.

3. Double-click on the shape to open the settings.

4. Fill out the fields on the **General**, **Inputs and Outputs**, and** Description **tabs. 

### General tab

## (nested_settings.PNG)

- **Name**.** **Enter the name of the subprocess activity that will be displayed on the diagram.

- **Process**.** **Select the process that will be called as part of the parent process.

If the selected process is not a system process and is not included in a [locked solution](block_solution.md), it can be opened for editing in a new browser tab. To do this, click the **(link-button.png)** button. Please note that the process will only open in view mode if the \[OBJECT\] feature flag is enabled. For the SaaS edition, please contact your sales rep. For the On-Premises edition, read more about this in [Modify BRIX parameters](change-settings-enterprise.md#enable-feature-flag-enterpeise).

- **Perform on behalf of**. Select who will be specified as the process initiator on the [instance page](360012498891.md#history_tab).

	- **Current user**.** **The person who started the child process instance.

	- **Context variable**.** **Select a variable of the [Users (one)](360009707032.md#users) type from the context process. The employee stored in this variable will be specified as the child process initiator. For example, you can select a user who belongs to the swimlane where the child process is located.

	- **System**.** **The child process will be performed on behalf of the user selected as the [system supervisor](360006871932.md#supervisor).

- **Asynchronous start**.** **Select this option if you want the parent process to continue after the start of the child process. If the option is disabled, the execution of the parent process is suspended until the child one is completed.

- **Link to field**.** **You can bind the subprocess launch to an **App** type variable of the parent process. In this case, events occurring within the subprocess (for example, errors, task reassignment, etc.) will be displayed in the [associated activity stream](360014352191.md) of the bound app. If you select a variable with the **Many** option enabled, you will be able to launch process instances for several selected app items. To learn more, see [Multiple subprocess start](#multiple-start).

- **Subprocess field**. Select a variable from the child process that will store the app item of the parent process. This option becomes available only if you have selected a variable with the **Many** option enabled in the **Link to field** field.

- **Process termination**. Configure rules for interrupting process instances. These rules will only apply to the current process and will not affect the parent process where the block is located. Enable one or both options:  

	- **Terminate the current process when a subprocess is terminated**. Stops the execution of the current process instance if at least one of its child process instances is interrupted.  

	- **Terminate subprocesses when the current process is terminated**. Stops all child process instances when the current process instance is interrupted.

If you later configure termination rules for the parent process, the rules set in the block for the current process will remain in effect.

### Inputs and Outputs tab

You can map context variables in the parent and child processes. Please note that only variables of the same type can be mapped.** (onboarding_settings.PNG)**

- **Input variables**.** **Variables that go from the parent process to the child process when the latter is started.

- **Output variables**.** **Variables that go to the parent process from a child process when the latter is ended. Please note that you cannot set up output variables if you have enabled **Asynchronous start** or have set up [multiple start](#multiple-start) for the subprocess.

In output variables, the **Output code** field is available. It allows sending the name of the end event of the child process of the parent process, once the child process is completed.

Let’s say there is subprocess for signing an agreement within the main **Procurement** process. It has two end events: **Original copy received** and **Original copy not received**. In order for the parent process to have the information about the event that the child process ended with, set up the **Output** **code** field.

To do that, add a String field to the context of the main process and give it a name, for example, **Result**. In the output column, specify the **Output code** variable of the subprocess, and in the **Subprocess** column specify the **Result** variable.

## Description tab

The tab is available in system versions 2025.10 and higher.

Add service information about the block's operation, such as a brief description of the subprocess being launched and its execution result. System administrators and employees modeling the process will be able to open this tab and review this information.

## Multiple subprocess start

If necessary, you can start several separate subprocess instances for different app items. This is called multiple start. To set it up, you need to select a variable with the **Many** option enabled in the **Start Process** activity.

For illustration, let’s change our **Requisition** process. The HR specialist will look for candidates and then create an app item for each candidate in the **Candidates** app. Then the HR specialist prepares a list of candidates to be sent for approval to the requisition initiator: they add the **Candidates** app items to the form of the **Submit candidates for review** task. When they click **Submit**, the list is sent to the initiator. For each of the app items added to the list, a separate instance of the **Review candidates** process is started.

During the **Review candidate** subprocess, the candidates are interviewed and tested. For the person who is accepted for the job, an employee profile is created. Then the parent process continues.

**(nested_22.PNG)**

To set this logic up, do the following:

1. On the **Context **tab, create a new variable of the App type. Select the **Candidates** app and enable the **Many** option.

2. Add the **Submit candidates for review** task for the HR specialist. Place it after the steps where candidates are found and added to the **Candidates** app. Open the task settings and add the **Candidates** variable to the task form.

This task is required so that the HR specialist can select several of app items created on the previous step and add them to the variable. This way the list of candidates for review is created.

Another way to send several app items to the process context is by using the [Script](360027203731.md) activity. To learn more about scripts, see [BRIX TS SDK](https://tssdk.brix365.com/en/latest/index.html).

3. After the **Submit candidates for review** task, place the **Start Process** activity. In its settings, select the **Review candidate** subprocess and enable the **Asynchronous start** option so that the parent process is paused until the child process is completed.

4. In the **Link to field** field, select the **Candidates** variable that you added in step 1. Also, select the property of the subprocess where the app items from the parent process will be sent to. In our case, these app items are the candidates. Save the settings.

**(candidates_settings.PNG)**

Now, during the parent process, for each process item of the Candidates app listed in the **Submit candidates for review** task, the **Review candidate** subprocess will be started. After it is completed, the parent process will continue according to the diagram.

Please note that you can launch maximum 100 instances of a subprocess. It helps prevent endless execution of one step. To bypass this limitation, you can configure an exclusive gateway and a timer to launch instances gradually. Read more about it in the [Possible process execution errors](360020599512.md#interrupt-looped-process) article.