My client doesn't have a ProcessFlow Admin yet so they needed a way for Purchasing to update the Approver setup without going into the ProcessFlow Admin Tool.
We modified the WFWK.2 form to make it easier to submit one of two flows to either replace an Approver or to add vacation coverage for an Approver.
In one the user can enter the Id of an Approver who is gone and the Id of the person replacing them. The flow will look up all of the Tasks of the old approver and the category filtering for each task and delete these from them and add them to the new approver. The flow also updates Lawson Security (Resource Update node) with the email of the new approver and sets the WFUser flag to "1" so the Inbasket will display.
The 2nd option is for vacation coverage. The user will enter the Id of the person going on vacation and the person covering for them. The flow will build the Task/Category Filter as needed for the coverage approver with the start and stop dates of the vacationer.
If, however, the coverage approver is already an approver then you know that you can't add the same Task a 2nd time (if the Approver is "Level1" you can't add a 2nd "Level1" with start and stop dates). To account for this we built the flow so that it would add the category filter items to the existing ones and create a new "Vacation" Inbasket Task.
Once the vacationing approver is back the coverage approver will go into this Vacation Inbasket and select "End Coverage". The flow will then remove the category filter items from their existing ones and remove the Vacation Task from their Inbasket.
Requisition Approval - Skip Levels
One of my clients wanted 6 approval levels but didn't have 6 approvers in each approval path. That wasn't too difficult to design in ProcessFlow; we simply looked up whether or not an approver was assigned at each level and skipped it when no one was assigned to it.
We had a further challenge when we realized that several approvers were also requesters. We didn't want the requester/approver's requisition to have to be approved at a level below (or by) the requester so we checked first whether a requester was an approver and at what level. We then skipped past that level to the next level up.
We then had to account for those levels we skipped and the authority limits of the approvers.
For example, if a requisition was approved at the first level but there wasn't a 2nd level we had to track the "approved at" level to determine whether or not the requisition needed to go to the 3rd level. If the requisition's value exceeds the level 1 approver but not the level 2 approver it would still go to the level 3 approver since no one was assigned to level 2. If however the requisition fell within the level 1 approver's authority limit then no other approval would be required.
We had a further challenge when we realized that several approvers were also requesters. We didn't want the requester/approver's requisition to have to be approved at a level below (or by) the requester so we checked first whether a requester was an approver and at what level. We then skipped past that level to the next level up.
We then had to account for those levels we skipped and the authority limits of the approvers.
For example, if a requisition was approved at the first level but there wasn't a 2nd level we had to track the "approved at" level to determine whether or not the requisition needed to go to the 3rd level. If the requisition's value exceeds the level 1 approver but not the level 2 approver it would still go to the level 3 approver since no one was assigned to level 2. If however the requisition fell within the level 1 approver's authority limit then no other approval would be required.
Subscribe to:
Posts (Atom)