Object List

With the help of the object list one or more objects can be assigned to a process. The objects assigned to a process can be distributed within the process to perform object-specific tasks. At the level of the process, a global definition of all objects supported by the process takes place, while in the sub-objects the set of objects can be reduced to a precise subset of the objects.

The object list has no integrative character. The inclusion of an object in an object list neither leads to a configurable behavior of the respective object in the SAP standard, nor does it enable the direct execution of actions by ProProcess. The latter, however, is achieved by implementing concrete tasks, which can either be delivered by ProNovia or implemented by the customer.

The Process Designer basically defines which objects can be added to the object list of the process. The objects can be selected from a range of supported object types. Furthermore a restriction by means of formulas and the object data is possible (e.g. only documents of a certain document type).

Open

Basically, it should already be clear when defining the object list how the respective objects are to be used within the process. From this point of view, it makes sense to define several entries for the same object type, which may differ from each other in terms of name and conditions. This allows a much easier (and fully automatic) distribution of the objects in the further course of the process. For example: If two sub-processes are available in the process, in which only certain objects are relevant, then it makes sense to separate these relevancies into two definitions already at the process level.

The distribution of the objects to process sub-objects is basically carried out via these object list definitions, but can be additionally limited by filters. This results in completely different possibilities, which are less object data- but more process data-oriented. It is conceivable, for example, that the distribution is mapped completely with the help of additional data by defining and maintaining special data for the process flow in the additional data.

For each definition it can be basically determined whether the number of objects should be limited, which can be particularly useful if only exactly one object of a certain object is to be managed in the object list. The initial status determines whether and how the object list can be edited when the process starts.

The order of the entries plays a central role in the automatic assignment of objects. If a new object is added at runtime, the system checks for the object in the sequence shown whether and to which definition the object can be assigned. Accordingly, it should also be ensured that the restrictions are "relaxed" with decreasing priority and not vice versa. For example: If two entries exist for an object type, one with and one without formula and the one without formula has the higher priority, then an object is always assigned to this definition and the other, restricted definition remains empty forever.

Object Distribution

In order for the various objects in the process to be processed by corresponding tasks, they must be distributed. This distribution can basically be done completely manually. Especially with large object lists, however, it makes sense to automate the distribution as far as possible. This is possible by restricting the object list for each process sub-object already during process design. By default, the object list is inherited downwards within the hierarchy.
The automatic distribution is always based on the object list definitions of the process. For each process object the inherited definitions are displayed and can be selected explicitly. The selection of at least one entry deactivates the complete inheritance, so that only the explicitly selected definitions are inherited.

Open

As soon as a definition is explicitly selected, additional filters can be defined based on the additional data to further restrict the objects using the additional data. If the object list is not needed for activities, tasks or sub-processes, the object list should be deactivated for these objects or their parent object to reduce complexity.

Additional Functions

While the object list distribution is used to determine at design time which objects are processed by which process objects, there are some process objects that require additional settings in connection with the object list. For this purpose, the respective process objects extend the object list with additional columns. For example, tasks for creating objects do not require object distribution; instead, these tasks must be able to specify where the new objects are to be added.