ORACLE PRIMAVERA UNIFIER
DOWNLOAD THE PDF HERE
In Unifier, routing for each step provides for Single, Majority or Consensus options to progress a document. Options to pre-assign or select users at time of routing also provide some opportunity for simple routing requirements but have some limitations in real-world experience. This tip outlines a couple of these scenarios and their solutions.
Consider Scenario 1—different reviewers for each record
For Change Orders, there are two or three steps where multiple users are required to approve, but this list changes for each change order. In this scenario, the only option above is to manually route (pick) the users at each of these steps. A better solution would be to define these users in the upper form and use those values to filter the pre-assignment list. This way, the same list can be used and re-used for that record, but a different set of reviewers could apply to the next change order.
Consider Scenario 2—different reviewers and routing in order
Change Order final approval requires multiple recommendations followed by multiple approvers and these must all be routed in order. In this scenario, routing in order would require a separate step for each recommend/approve action because as one step all would receive simultaneously. Second, routing as separate steps might require routing back to a document control person to enter who the next recommend/approver would be. For this, the better solution would be again to define the list in the upper form and use the values to filter the pre-assignment at each step. This would eliminate the interim document control step between each and would better automate the routing.
Solutions
Different Reviewers by Record
- Create data elements to record the user name and login name.
- You can also add data elements to determine if routing is required (yes/no) and then use this in a dynamic dataset to require entry.
- In the step for routing, select the GROUP where all reviewers are included then uses the “Additional Conditions” to filter the routing by the data element(s) (login name) from the upper form.
- Repeat this for each step where this group gets routed—for example at initial review and final approval.
- Prior to routing, the data elements in #1 would be set to required (based on dynamic data set) so that routing would automatically flow to those parties.
- This eliminates the manual picking of names at each step (prone to error—“I missed one of the approvers”
Routing Reviewers in Order
- Create data elements to record the user name and login name.
- You can also add data elements to determine if routing is required (yes/no) and then use this in a dynamic dataset to require entry.
- Set up separate step for each reviewer and route them serially—in order.
- Select the GROUP where the reviewer is included then use the “Additional Conditions” to filter the routing by the data element(s) (login name) from the upper form.
- Repeat this for each step.
- If the routing is static—always to 5 people in order—this is sufficient.
- Note: You’ll want to make the data elements required at the appropriate step to make sure that they are filled in.
- If the routing varies—sometime to 3 people, sometimes to 5, you’ll need to build in conditional branching that bypasses the steps that are not required.
- That way if the first three are filled in, it will skip the last two steps automatically.
- Doing this will route them in the order you defined in the upper form and will do this automatically without any intervention after sending.
