Management chains are typically used for serial approvals through multiple users in a management chain hierarchy. Therefore, this list is most likely to be useful with the serial participant type. This is typically the case if you want all users in the hierarchy to act upon the task. Management chains can also be used with the single participant type. In this case, however, all users in the hierarchy get the task assigned at the same time. As soon as one user acts on the task, it is withdrawn from the other users.

You will create a management hierarchy, which will get a level of elevation from the Customer Check Rules' Decision Table.

Remember the Decision Table has Actions in which a value is assigned to a number of Tier3Level, which means at what level you need to assign this task too. You will use this value to decide on the level. The maximum level defined is 2.

The task is assigned to Sales Representative's manager AreaSalesmanager. The other people in the hierarchy who will get notified based on the numberofTier3Level value are regionalmanager and countrymanager.

How to do it...

Let's learn to define management chain participants with the following steps:

1. Go to BPM Navigator | SalesToContractDemo | business catalog | Human Tasks and click the ManagementApproval.task file. This will open the Human Task editor.
2. Go to the Assignment section and you will find two stages created: TerritoryManagerApproval and SalesGroupApproval, as shown in the following screenshot:
   
3. Click on the SalesGroupApproval stage, click the green plus (+) icon, and select Sequential Stage to create a Sequential Stage after the SalesGroupApproval stage.
4. Click on the default stage name Stage 1. In the Edit dialog, enter the name of the stage as SalesManagementChainApproval and check Non-Repeating.
   
5. Click on the Edit Participant Box, and in the Participant Type dialog, select participant type as Serial and Label - SalesManagementChainApproval.
6. Build a list of participants using the management chain.
7. Specify the Participant Type attributes as Value-based.
8. In the Starting Participant, click on the green plus (+) icon and select Add User as Identification Type.
9. In the Data Type, choose By Expression.
10. Click on the Browse button to use the Expression Builder.
11. In the functions section, select the Identity Service function getManager() and click Insert into Expression.
12. As you are going to build a user list based on Embedded LDAP, the getManager() function accepts SalesRepID, and the name of the realm is jazn.com.
13. Expand the payload in the Schema section as QuoteRequest | Summary | SalesRepId and click Insert into Expression.
    
14. Click OK. The list will be dynamically built and level to which it would be elevated will be decided at runtime based on the Number Of Levels entered into the Participant Type dialog.
15. Select XPath from the drop-down list and click on the Expression Builder.
16. Expand Payload in the Schema to Payload | ApprovalFlow | NumberOfTier3Levels.
17. The value is populated into this field at runtime by the Customer Check Rule execution.
    
18. Click OK.
19. The Participant Type will resemble following screenshot. Click OK.
    
20. When finished, Save.

How it works...

Remember you have created a CustomerCheck.rules file. At runtime, when facts match condition cells (Customer Type = New and Quantity as entered, if it falls in the given range), the Rules Engine prepares to run the actions associated with the rule. This action will enter value into the numberOfTier3Levels. For example, if rule R3 executes, action will enter value 2 into numberOfTier3Levels. And the task will be assigned to SalesRepID's manager areasalesmanager and on his/her approval, it will move ahead to regionalmanager.