Creating Rule Based Change Triggers

Rule-based change triggers run whenever an item is changed by a user in a manner matching a defined rule. Any modifications appear as if made by the original user who modified or created the item that caused the trigger to run.

When using a trigger to prevent a user action, ensure the trigger displays an error message to the user and the user has a course of action available.

The general steps required to create a rule-based change trigger are as follows:

1. Select the rule-based change trigger type.

4. Select a script file from the library for the trigger to run. Then, if required, fill out the parameters for it.

Backlashes (\) in parameters are truncated after you save and run the trigger, for example, in a directory path. To avoid this, use forward slashes (/).

5. Assign values to the fields the trigger modifies when it runs (if the trigger is one that modifies field values in the database).

• Ensure each field the user is required to update is legally updateable by that user.

• If the state of an item is being changed, ensure the state transition is valid.

• If the state of an item is being changed and the new state is one that does not allow open change packages, ensure all of the change packages are closed before the state change is made.

• Ensure all fields that are mandatory for the final state in the workflow contain values.

• The Document model is enforced for change triggers in the following ways:

◦ A branch of the backing shared item will be caused if a change trigger makes a significant edit to either the Author or Reuse node of any shared item that is one of the following:

▪ Referenced either by an Author node and at least one Reuse node

▪ Referenced by two or more Reuse nodes (no Author node is required in this second case)

◦ Change triggers cannot perform a significant edit on a node in Share mode. If such attempt is made, the edit will be aborted with an error.

• Validations are performed before any trigger code runs. The pre-event trigger only runs if all validations are successful. Be aware that the trigger has administrator privileges and may override the user permissions.

• If your rule contains only one condition, you do not need to use And and Or nodes.

• If no rule is defined for a rule-based change trigger, the trigger runs every time any user performs an action on any item in Integrity Lifecycle Manager.

• Pre- and post-options are not available for scheduled triggers.

• Scripts listed under the samples directory (for example, samples/breakLockNotification.js) are for configuration management and are not applicable to workflow and document management.