In many cases processes follow complex rules. So the graphical structure of a process may me simple. But to decide who should take over a task can be very different. I will show this behavior on the basis of a typical invoice approval process and how to model it in BPMN.
BPMN allows to use swimlanes to define in which department a task should be processed. So for the invoice approval the process will start in the accounting to register the invoice data in the ERP system. Depending on the amount of money, the cost center and the class of the supplier there may be one, two or in some cases three approval steps (the third approval is not shown in the following diagram to simplify):
To model in a simple way you should not paint one lane for each department in your company and do not use a XOR-gateway to split the flow to an approver task in each of the lanes. Better use a general lane for the first approver and another one for the second approver. The rules should be maintained in a decision table of e.g. a Rules Engine and processed by a business rule activity. The results of this business rule activity are stored and used if needed.
In case of SAPERION a business rule performer as a background job takes over. He retrieves al the necessary data and gives these together with the name of the rule set to the Rule Engine. Afterwards the flag whether a second approval is needed and if so the name of this approver. Afterwards the business rule performer sends the flow to the first approval activity and addresses the concrete first approver as well.
The first approver checks all the invoice data and can decide whether these data are correct (OK), or not (NOK), which means that accouting should clear the incorrectness. While forwarding the flow the conditions after the XOR-gateway are aveluated by the process engine. If OK and the flag for second approval is set, the flow is given to this second approval task. The process engine is than evaluating the performer and addresses this task to him.
SAPERION uses the role OWNER of an instance. After starting the process beginning with the registration task the process engine addresses this task to the organisation unit accounting. The members of accounting can take tasks out of the group inbox and process them. The one who processed becomes the OWNER (missed in BPMN yet). The user tasks clear invoice and book invoice can be addressed to the OWNER. This means one face to the process instance ;-)
Such a dynamic behavior can be used for other requirements. For example in insurence companies where a general process is used for several lines of business. Depending on the business, the customer and other parameters the user with the fitting skill has to be evaluated for processing the task.