Execution of actions/controls

Documents will always be handled over their materials, resp. via Obj. Dep.ID of the corresponding material. All linked materials will be checked and the actions will be performed for all (family / multiple usage).

One action can trigger another action (e.g. Doc A sets status of Doc B, which then sets the material status). This can happen over multiple object and multiple levels (A → B → C → D). Because each level must run in its own context, the levels are restricted. See ProConfiguration basic setting "Obj. rel. levels". Example: 

If an object already has reached a target status, the action will be ignored. In the image above, if for example Object C has already target status set, this object and therefore also object D are not handled.

In general, actions are performed via standard interface. Therefore additional checks and actions are performed on the objects concerned. Setting option "Set directly, no subsequent options possible", the status will be set directly in the data base and no more object relations will be performed for this object.

First all checks will run (incl. a check whether a certain status change may be valid), on error process will be aborted, else the actions will be performed afterwards.

Recursive checks and actions: it's easily to define a loop in customizing, for example a document A sets document B, document B sets document A. In order to prevent those loops, the ProConfiguration will abort checks and actions, if the object is already handled.

For several valid versions of one object type, please see ProConfiguration document „Tips and Tricks".

In general object dependencies within a triggering action will be performed while processing the object. If a processing scenario is started with an activity, having set option "dependent actions, late" the action on the triggering object (e.g. status change or new creation) will first be closed and checked-in, before the dependent actions will be performed. See also Activities Processing Scenarios.