Today I will illustrate authorization hierarchies for approval flows in Infor M3.
A common requirement in M3 projects is to implement approval flows, for example for purchase orders; where a buyer creates a purchase order of a certain amount; where one or more approvers must review the order, and either approve it, one approver after the other, either reject it for some reason; and where the approvers are selected from a hierarchy of managers and their maximum order amount.
Infor Process Automation
To implement the approval flows we use Infor Process Automation (IPA). We can also use the former Lawson ProcessFlow Integrator (PFI). As for Infor ION, it is the new standard for implementing M3 approval flows, but its usage for M3 is still young, and it does not yet have as many features as IPA does.
M3 Purchase Authority – PPS235
To store the hierarchy of approvers and their maximum order amounts, we use the program M3 Purchase Authority – PPS235. It stores the user (AURE), the maximum order amount this user is authorized to approve (MPOA), and their manager who is the next level for authorization (MNGR). For orders that exceed this amount, authorization is required by a user with authorization rights for a higher amount.
I am not an expert on PPS235, but it looks like it does not enforce integrity, and it is not in normal form, and that can result in logical inconsistencies.
Indeed, the hierarchy of managers and maximum order amount may contradict each other. For instance, PPS235 allowed me to set a user whose maximum order amount was higher than that of its manager, in which case routing the approval to that manager will result in a logical anomaly.
Also, there is a field to set the user’s authorization level (AUTL) which results in an alternate hierarchy of approvers, and PPS235 allowed me to enter illogical values there too.
That results in several possible hierarchies: either based on the managers, either based on the maximum order amounts, either based on the authorization levels, all possibly contradicting each other.
Also, PPS235 erroneously allows cycles in the hierarchy. For instance, it allowed me to set a user to be the manager of its manager. This will cause an infinite loop in the graph traversal.
Also, users can be unreachable if there does not exist a connection to that user in the hierarchy.
There is probably a logical explanation for these design decisions. Meanwhile, you must ensure the integrity of your data before proceeding.
The data of PPS235 is stored in table MPAUTD – Authorization distribution as an adjacency list of users and their managers, for example:
The resulting tree looks something like this (I use Graphviz to visualize the hierarchy and ensure it is correct):
To retrieve the hierarchy of managers for a certain user we traverse the adjacency list recursively using SQL’s common table expressions (CTE), for example for user Marie and for a purchase order in company 100:
WITH CTE AS ( SELECT ATCONO, ATAURE, ATMPOA, ATMNGR FROM MPAUTD WHERE ATCONO=100 AND ATAURE='Marie' UNION SELECT M.ATCONO, M.ATAURE, M.ATMPOA, M.ATMNGR FROM MPAUTD M JOIN CTE C ON M.ATCONO=C.ATCONO AND M.ATAURE=C.ATMNGR ) SELECT ATAURE FROM CTE ORDER BY ATMPOA
You can now create a loop of UserAction activity nodes in IPA to iterate thru that hierarchy. Here is an excerpt (you will need to add the SQL activity node and everything else that may be needed; you can also use the new ForEach activity node instead of my loop with an if-then-else Branch):
That was a quick illustration of authorization hierarchies for approval flows for purchase orders in M3, more specifically how to store the hierarchy of approvers in PPS235, how to recursively query it from MPAUTD, and how to do a loop of UserAction activity nodes.
(I meant to write about this many years ago. I finally got around to doing it after I learned how to do the recursive SQL portion for a customer last week. I hope it helps you.)