Adding elements to gateway branches

You add elements to a branch by drawing routes from an operation, event, or activity to the gateway or existing branch elements. Use the tools and methods you use for other parts of the process diagram to add, remove, and change the sequence of branch elements as required. (See Drawing routes to link operations .) You can add any number of elements to a branch.

You can drag one end of the gateway element to increase the distance between the two ends. Increasing the distance creates space for multiple branches and elements.

You can modify the routes connected to the start and end of the gateway using the methods used for regular routes. For example, you can change which operation is executed first by dragging the anchor for the first route in the branch to a different operation. However, when you connect an element to the end of the gateway, if no route connects the branch elements to the start of the gateway, one is added automatically.

If you do not provide a final route to connect the branch to the end of the gateway, one is added automatically the next time you open the process.

To change which operation is executed first:

In the branch, right-click the operation to execute first and select Set Start Activity.

Validating routes used by gateway branches

When you add routes to gateway branches, an error icon appears when you attempt to draw invalid routes. For example, you cannot create a route that connects a branch activity to an element outside its branch. Routes that connect elements in different branches are also invalid.

Additional route validation information appears in the Validation Report view. For example, a message appears in the Validation Report view if a branch within a gateway is incomplete. (See Validation reports ).

Operation and branch compatibility

Not all operations are compatible with all branch types. Operation and branch compatibility may help you to decide the type of branch that you should use in your process.

Note: You use gateways to add additional branches to a process.

Branch type

Compatible operations


All operations


All operations


Set Value, Stall, and Execute Script service operations

Note: The operations of the User, Wait Point, and Execute Script services, as well as gateway elements, cause synchronous branches to behave as asynchronous branches.


A transaction is a context in which one or more operations are executed. Generally, the operations that are executed within a transaction are not committed until all of the operations are executed successfully. If one operation in a transaction fails to execute successfully, the transaction is rolled back and the effects of any operations that were already executed in that transaction are reversed.

In Transactional branches, the operations in a branch are executed in a single transaction. In an Asynchronous or Synchronous branch, each operation is executed in separate transactions.

Transactions and branches

Transactional branches are useful when a common goal is dependent on the successful execution of a series of operations. If an operation in a transactional branch executes with errors, the branch is stalled. When the branch is retried, the transaction for the branch is rolled back and the first operation in the branch is executed again.

For information about the behavior of actions in Transactional branches, see Transactions and operations .

Asynchronous and synchronous branches are useful when the failure of one operation in the branch does not devalue the successful execution of previous actions in the branch. If an operation in an Asynchronous or Synchronous branch executes with errors, the branch is stalled. When the branch is retried, only the failed operation is rolled back and the operation is executed again.

Branch behavior when errors occur

The behavior of a branch when a stalled branch or a stalled operation is retried is a factor to consider when deciding which type of branch to use in your process.

For all branch types, when a branch exception occurs, the branch is stalled and, when an operation exception occurs, the operation for which the exception occurred is stalled.

The following table describes how the different branch types continue execution after the forms workflow administrator retries the stalled branch or operation.

Branch type

Behavior when a stalled branch or operation is retried


The process continues from the point in the process where the exception occurred.


The process continues from the point in the process where the exception occurred.


The branch is rolled back, and the process continues from the first operation in the branch.

Transactions and operations

Operations are handled differently in transactions, depending on whether the operations are transaction-aware and long-lived.

Transaction-aware operations

Operations that are transaction-aware will participate in a transaction. When a Transactional branch is rolled back, the operations in the branch that are transaction-aware are returned to their original state before that branch was executed.

If an operation is not transaction-aware and it is used in a Transactional branch that stalls, the effects of the operation are not rolled back when the branch is retried. The operations are executed a second time. For example, if you use the Email operation in a Transactional branch, each time the branch stalls and is retried, another email is generated.

The only transaction-aware operation that Foundation provides is the execute operation of the Set Value service. However, your development team may create transaction-aware operations using the AEM forms SDK.

Long-lived operations

Long-lived operations execute independently of the branch to which they belong:

  • When a Transactional branch is stalled and is retried, any long-lived operations in the branch continue to run and are not rolled back.

  • If a computational error occurs during the execution of a long-lived operation, the operation is stalled, but the branch is not stalled even if the operation belongs to a Transactional branch.

None of the operations that Foundation provides are long-lived. However, your development team may create long-lived operations using the AEM forms.

// Ethnio survey code removed