This documentation supports the 20.02 version of Remedy Action Request (AR) System.

To view an earlier version, select the version from the Product version menu.

Distributed transfers

A distributed transfer sends information from a source form on one server to a target form on another server or on the same server. You configure a distributed transfer by defining a distributed mapping (see Distributed mapping) and by creating workflow to perform the transfer (see Creating workflow to perform DSO operations). Then, when a request is created or modified in the source form, that action can trigger the workflow to create a copy of the request and transfer it to the target form. The transfer can include all or some of the data in the request.


If you are trying to migrate password field data from version 9.1 and later servers to version 9.1 and earlier servers via DSO, the data might not migrate because of the larger length of data in password fields in version 9.1. Version 9.1 uses enhanced password security with SHA-256 algorithm.

The following figure shows the basic flow of a distributed transfer. (The request in the darker form has ownership after the operation is completed.) For an example of how to set up a distributed transfer, see Distributed transfer scenario.

Distributed transfer flow

Stages of a distributed transfer

The stages of a distributed transfer are listed in the following table:

Stages of a distributed transfer


DSO server action


Gets a list of pending items to process from the distributed pending queue. The list includes details about each operation. For information about the distributed pending queue, see Managing pending distributed operations.


Identifies the next pending item to process from the list obtained in stage 0.


Gets the definition of the source form associated with the pending item.


Gets detailed information about the request to transfer, which is identified by the request ID in the Source ID field of the pending item.


Gets the definition of the distributed mapping associated with the pending item.


Verifies that it can implement the mapping.


Gets the definition of the target form associated with the pending item.


Transfers the request from the source form to the target form.


After the transfer operation is complete, updates information about the status of the operation in the request identified by the Source ID field of the pending item.

The other types of distributed operations — updates, returns, and deletes — use a subset of these stages.

To track these stages, use the DSO logs (see Configuring BMC Remedy Distributed Server Option logging).

Request ownership chains

To modify a request, users must own it. Typically, ownership is transferred with a request.

When ownership is transferred with a request, an ownership chain is created. The ownership chain begins with the copy of the request that has ownership — also called the — master copy (see the definition for Master Flag in  Distributed fields) — and extends back through all copies of the request from which ownership was transferred.

For example, a request on the sanfrancisco server must be resolved on the chicago server. Therefore, you transfer the request with ownership to chicago so that chicago users can modify the request as necessary. Depending on your workflow configuration, sanfrancisco users might receive notice of changes made to the request on the chicago server through a distributed update operation. But sanfrancisco users cannot modify their copy of the request unless the request is returned with ownership through a distributed return operation.


For information about mapping chains, see Setting up chained distributed transfers.

Types of distributed transfers

DSO can perform the following types of distributed transfers.

Types of distributed transfers

Type of transfer Copy of request in target form Description
Holds ownership? Is in ownership chain? Can be modified?
Data Only No No No Typically used for archiving. Because data-only copies cannot hold ownership, they cannot start ownership chains.
Data + Ownership Yes Yes Yes Considered the master copy. Modifications made to this copy can be automatically made to all other copies of the request in the ownership chain (see Distributed updates).
Independent Copy Yes No Yes Cannot receive updates from the master copy because independent copies are outside the ownership chain. Independent copies can start new ownership chains.
Copy + Delete Yes No Yes Transfers an independent copy of a request to the target server and then deletes the original request.

Dynamic data, such as an entry in a defect-tracking form, is often modified at the site to which it is transferred. Use a Data + Ownership operation to transfer this type of data.

Static data, such as customer biographical information, is typically not modified at the site to which it is transferred. Use a Data Only or Independent Copy operation to transfer this type of data.

Was this page helpful? Yes No Submitting... Thank you