---

An automatic transfer is a transfer which is triggered when its dependency conditions are met. The transfer is performed automatically by the Deltanji system, rather than manually by a user using one of the transfer functions. Each time Deltanji transfers an object version, either as a result of user action or because of another automatic transfer, it checks through its list of automatic transfers and performs any whose conditions are met.

AUTOF and AUTOT

---

Automatic transfers are defined by the use of the reserved function codes beginning AUTOF and AUTOT.

AUTOF

A transfer route with a function code beginning with the character sequence 'AUTOF' is designed to automatically push objects further around the workflow once they have been transferred to a location. After the transfer of an object takes place, Deltanji looks for AUTOF transfer routes whose 'from' location matches the location to which the object version was just transferred, or matches another location where that transfer activated it. Deltanji then initiates each such AUTOF transfer provided its dependencies are met and its access rights are satisfied.

Each time Deltanji initiates an AUTOF transfer from a location, it goes back and re-checks the dependencies of the AUTOF transfer routes that did not have their dependencies met. This is because each transfer changes the Deltanji environment, and a transfer that was not valid on the first check may become valid after any of the other AUTOF transfers take place. This behavior can be subverted by chaining and ordering the transfers (see below).

Note: AUTOFs are typically defined with a '%TO dependency and a +%TO activations. Failing to do this results in a message about a looping transfer.

Note: AUTOFs are processed before AUTOTs.

AUTOT

A transfer route with a function code beginning with the character sequence 'AUTOT is designed to automatically advance particular areas of the workflow. After an object has been transferred between two locations and any AUTOF transfers have taken place, Deltanji checks all AUTOT transfer routes. If an AUTOT transfer route's dependencies are met, the object will be transferred along that route.

The major difference between AUTOT and AUTOF transfer routes is that all AUTOT transfers routes are checked - and initiated if valid - after every transfer, not just those transfer routes whose 'from' location matches the 'to' location of the original transfer or another activation location of that transfer.

Note: AUTOTs need a combination of dependencies and activations that will prevent them firing indefinitely. Failing to do this results in a message about a looping transfer.

Example

In a development workflow where a developer wants to transfer their work to the testing area, it may be necessary for the object to be transferred to multiple locations, for example, when an application needs to be tested on different Operating Systems. The workflow might be set up like this:

1. The developer checks the object in by transferring it from the DEV location to the ForTesting location.
2. After this transfer takes place, Deltanji looks for AUTOF transfer routes that start from the ForTesting location.
3. Deltanji finds a transfer route from ForTesting to QAWin, its dependencies are met and the transfer takes place.
4. Deltanji then finds another transfer route, this time from ForTesting to QALinux. Its dependencies are met and the transfer takes place.
5. Finally, Deltanji checks all of the AUTOT transfer routes that are defined. It finds the route which transfers the object from ForTesting to InTest. Its dependencies ensure that the transfer cannot take place unless the object version exists at the two working locations, QAWin and QALinux. This is true so the transfer is initialized.

Batch Automatic Transfers

---

Standard AUTOF or AUTOT transfers operate on each object immediately after it has undergone the user-initiated transfer. When a user-initiated transfer is for multiple objects (e.g. a by-CR transfer) batch auto-transfers occur after all the user-initiated transfers have happened. This brings the following benefits:

• Inter-object custom dependencies can be constructed. For example, auto-forward an object only if every other member of the object's change requests is either at %FROM (i.e. is ready to be forwarded) or at %TO (i.e. has already been forwarded).
• Batch auto-transfers to F-format and FX-format storage generate a single file. In contrast, non-batch ones produce one file per object.

Batch routes are denoted by function codes beginning AUTOF* or AUTOT*.

Chaining and Ordering Automatic Transfers

---

In the case that multiple AUTOF or AUTOT transfers are required to be triggered, custom transfer route function codes can be defined. All transfer routes that have a function code which begins with AUTOF or AUTOT will have their dependency conditions checked whenever a transfer is initiated. This means that you can chain automatic transfer routes in a particular by adding a custom suffix to the function code.

For example, an environment could be configured to contain a transfer route with the function code AUTOT1 and another with the function code AUTOT2. Deltanji will check and intiate these routes in order.

---

See Also: Transfers, Transfer Routes, Managing Transfer Routes, Reserved Transfer Route Function Codes