An operation that launches a Business Rule is called a triggering operation. The operation triggers a Business Rule only when performed on objects of the specified type included in the Business Rule activity scope.

For example, if an operation that triggers a Business Rule is Creating a Group, and this Business Rule is effective for container My Groups, the Business Rule is triggered when a new group is created in the container My Groups.

An operation that triggers a Business Rule cannot be changed after a Business Rule is created. If you need a similar Business Rule for another operation, you should create a new Rule for this operation.

Additional actions can be executed Before or After the triggering operation is performed. Some actions cannot be executed after the main operation. For example, Send for Approval action cannot be executed After the triggering operation because the operation that would be sent for approval is performed prior to the action that would request to approve its execution.

When a triggering operation is performed on objects included in a Business Rule activity scope, this Business Rule executes additional actions. These actions are executed only if the corresponding conditions are met.

One Business Rule can have several sets of actions and conditions. These sets and actions in them are executed sequentially in the order of their arrangement. To change the order of action execution, you need to change their sequence.

Actions generated by a Business Rule can be executed synchronously or asynchronously. Synchronous execution means that the main operation is not performed until the actions generated by a Business Rule are executed. Asynchronous execution means that the triggering operation does not wait for additional actions to be performed.

The access control is not carried out for actions generated by a Business Rule. Additional actions are assumed to be executed by an Adaxes service and are not restricted by permissions of the user who performed the triggering operation.

Actions executed by a Business Rule can trigger other Business Rules. If Business Rules execution causes a cycle, Adaxes service prevents repetitive execution of these Business Rules.

For example, the Business Rule triggering operation is Updating a User and one of actions executed by the Business Rule is Disable the User Account. In this case, a cycle emerges as disabling an account is also a user update. To avoid such situation, you can add a condition like If Description changed to the Disable the User Account action. After that, this Business Rule action will be executed only if Description is updated and cycling will not arise.

A Business Rule is only launched when the operation that triggers it is performed on the objects included in the activity scope of this Rule. Activity scope can include or exclude whole domains, members of groups and Business Units, children of containers and organizational units, or specific objects.

Business Rules can be used to request approval for an operation. In this way, critical operations can be controlled by users specified as approvers.

Approval requests can be set both for operations that trigger Business Rules and for actions executed by Business Rules. Send for Approval action is available for an operation that triggers a Business Rule only if a Business Rule is executed Before the triggering operation. For more information on approval requests, see Approvals and Requests

Actions executed by Business Rules are displayed in the Execution Log of the triggering operation. The Execution Log also displays errors, warnings and information messages on additional actions.

The result of asynchronous operations is not displayed in the Execution Log. However, you can see it in the Service Event Log.

If you do not want a Business Rule to be effective for a certain period of time, you can disable it. The icon indicates disabled Business Rules.

To deprovision user accounts for terminated employees, a system administrator or responsible person needs to perform several actions. Using Business Rules, all these actions can be done with one operation only.

For example, you can create a Business Rule with the triggering operation After Moving a User and set the following actions and conditions for this operation:

If located under 'Deprovisioned Accounts'

Disable the User Account

Move the Home Directory to \\Server\Deprovisioned User Directories\%username%

Update the User: set Description to 'Terminated'

So, to deprovision a user, you just need to move it to the 'Deprovisioned Accounts' container. After that, this user account is automatically disabled, its home directory is moved to 'Deprovisioned User Directory' and its description is set to 'Terminated'.