Action trees are the entry points for processing data in ELOxc. They possess an order number, which means that the ELOxc service follows a predefined processing sequence when running in default mode. They also have configuration attributes that determine which element set is selected for processing. The XML name of action trees must always correspond to the SORD name.

Action trees are listed in the Action trees area of the instance overview page. Click the Add button to add an action tree.

The Add action tree dialog box opens.

Name: Select a name for the action tree.

Order: Define the order of the action tree. You can usually use the default order number for this field. Each order number (ID) must be an integer unique within the instance.

Status: Select Active, Inactive, or Subtree from the drop-down menu. Only active trees run automatically with an instance, but all action trees must pass a validation check in order for the instance to run. It can help to temporarily deactivate an action tree (set to inactive) if you want to change a configuration and keep the previous status, for example. If you select Subtree, a special form of tree is created, which is mainly used to preserve the actions it contains and their logical hierarchy, whereas all parameters used for element selection are automatically disabled. You can call these type of trees as encapsulated templates of active trees using the "CallDef" action specially provided for this purpose. These trees can also call other action trees of this type. You cannot, however, call them directly, nor can you call active trees. You must therefore ensure that you do not create cycles when calling these template trees. ELOxc does not automatically check for cycles, which is why configurations like this cause several problems during execution.

Import example: If you have stored sample action trees stored in the repository under //ELOxc Base//EXAMPLES, they are listed here. You can select one of these examples for testing purposes, or to use them as templates to construct custom action trees.

Click the Add button to create a new action tree.

Once you have created the new action tree, the Options page opens.

The settings above show an example of a simple initial functional configuration once ELOxc is running. They illustrate the most important settings used for element selection:

• The data sources are entered under Mailbox ("xc21" in this case). This list of data sources only applies for the selected action tree. In the next section, we show you how to configure lists that you can use in any number of action trees.
• We only include elements that have not been archived yet (Archived e-mails = No).
• The Minimum e-mail age of the elements to be archived is seven hours. The accepted input format is "days:hours:minutes:seconds".
• Only one entry point was selected within the valid data sources ("\Inbox"in the example above). You can make multiple entries here. If you enable recursive processing for an entry point, all elements in child containers are processed instead of just the elements in the "Inbox" container.
• The element classes specified under Classes allow you to select the type. In the example above, only Exchange e-mails are taken into account, while entries for contacts or appointments are ignored.

Click the Advanced button to configure additional parameters to refine the key aspects used for element selection.

The element property "Archiving state", which is described via the InstanceDef.Restriction.Archived parameter (see XML) or in the ELOxc Console with "Archived e-mails", is particularly important. What makes this property unique is the implicit definition of an element state, which plays a central role in element selection and is an integral characteristic of ELOxc. The integrated states are as follows:

• Not archived: an element has never been archived (no entries to a field).
• Archived: An element has been archived at least once (EloXcArchivedBase, EloXcArchivedExt).
• Finished: An element cannot be selected again (EloXcFinishedBase, EloXcFinishedExt).

The states are usually attached to the processed elements as attributes ("Properties" in Exchange). The field names in parentheses are the identifiers of the integrated element states reserved in ELOxc. The field with the attachment "Base" always contains a timestamp that refers to a processing time, while "Ext" is defined depending on the status. EloXcArchivedExt contains the GUID of the corresponding SORD to determine the archived state. These three integrated states are required for some actions, which better illustrates the characteristics of the term "element state".

The concept of the element state is derived from the definition of these states so that ELOxc generalizes and consequently applies its meaning. In addition to the integrated states, it is possible to configure application-specific states, which can also be stored as element attributes. This enables classification of processed or selectable elements and therefore allows the identification of elements which, due to their native element properties, would otherwise have to be classified as a heterogeneous set without significant similarities.

As a general rule, element states are hidden. Accordingly, the states are not depicted by changed element symbols (e.g. in Outlook), but by adjusting the field contents of elements. For example, by creating a dedicated item state, the subject line can be modified so that the mailbox owner can see the state. However, no additional message icons are created for Outlook, which in this case would require you to change the element class. This is therefore not an ideal option for ensuring stable processing and long-term portability of the data source elements.