Actions in ELOxc are the set of available processing rules or patterns. They are designed to allow you to create modular and hierarchical actions with as few interdependencies as possible. Whereas the configurations for an instance and its action trees affects which elements are selected, the configuration for actions constitute the rules that define how the selected elements are processed. The hierarchical order of actions within an action tree results from the fact that an action can have a maximum of two results - successful ("TRUE") or not successful ("FALSE"), and from the fact that the action tree evaluates an action result and dynamically determines the follow-up action.

The remaining and unavoidable dependencies between the actions result from the necessity of being able to use processing data in different actions. This is largely dependent on the element fields selected, which determine the scope of selection of an action tree and are determined automatically by ELOxc before an element is selected.

However, the pseudo element fields defined by ELOxc, which contain special data that the data sources normally do not contain, are also essential. An example of this is the ELO GUID, which is generated during archiving ("CheckinDef") and can also be used in other actions such as deletion ("DeleteDef") or in the existence check ("ExistsDef"). This can be illustrated by assuming that a checked, secure deletion is configured and the responsible action tree selects elements that have not yet been archived. In this case, the secure deletion, which requires the existence of an ELO GUID, would automatically fail because non-archived elements cannot have an ELO GUID.

Another type of action dependency is the "intention of an action tree": If you want to archive an element, you need the corresponding action ("CheckinDef"), which performs the archiving. However, this can only work if elements have already been exported, which is also an independent action ("ExportDef") that only reads element data from the data source in document form. In this case, export and archiving actions are inextricably linked. As a rule, however, in addition to this minimum configuration, you will also want to define the keywording and the repository path, which is why the export action is assigned a keywording template and the archiving action also determines the configured filing path. The filing path is also an independent action that can be used as often as required and can use its own keywording templates.

Each element that is processed contains its own working data, which can be collected in the context of an action tree and used for element processing after successful element selection. If actions that generate this internal working data are executed multiple times in a tree, the most recently determined values are applied when the data is used.

However, there is one exception that applies here: Permissions ("ItemSecurityDef") are set or removed cumulatively for each element in order to be able to compile the complete list of ACLs about possible case distinctions in the action tree.

ELOxc provides two additional levels for fields of the data source that are used. These are distinguished as follows: One level defines whether to transfer changes that are made when saving elements ("CommitDef") to the data source, which changes the elements themselves. The other level defines whether changes to data are used as copies or action-only data, meaning that their values are not stored in the data source. ELOxc uses the attribute value "fieldname" in all places that directly use the element data, while the field copies are defined with "cachedname". By default, actions in ELOxc assume that all data changes are to be saved, meaning that the element fields are used and changed.

Before you create the first action, click "+" next to the node of the action tree to see the available actions.

You can select all the available actions in the Add action dialog box.

Before we go on to explain each of the available actions in this section, let us take a look at their roles: