Transitivity of operation dependencies

If each operation present in a specific batch request happens successfully, dependencies are guaranteed to be maintained and are transitive (CRTG->ACUA and ACUA->GRUA will mean that all ACUAs happen after a CRTG and all GRUAs happen after all ACUAs. If a request contains CRTG, ACUA, and GRUA, they will happen in 3 separate steps.

Adding dependencies does not ensure the creation of the dependent operations; that is up to the solution scripting. This means that if an ACUA does not exist in the request (or was somehow removed), the transitivity is not enforced anymore. In order to cover that situation, a direct dependency has to be added between the outermost operations (CRTG->GRUA).

Dependencies are calculated when operations are sent to the Transaction Monitor Service (idtm).

By default, that's only done when everything in the request is decided (approved/rejected).

The order in which the request is processed (manually or automatically) before being submitted and approved does not matter.

Once the request is "finalized" (after approval), its operations are reordered according to dependencies and sent to idtm .

Bravura Security Fabric has the ability to modify an existing request... at any stage; this means that if a GRUA was present in a request marked as finalized and then approved and then the request was edited (by a user or automation) to add an ACUA, it is theoretically possible to have the GRUA go first.