Last week I posted about multi-approvals (i.e. how to send different types of approval from within one workflow entry Multi-Approvals inside 1 Workflow).
This post is looking at some other tips for workflows based on this recent requirement I dealt with.
The history on this approval was a lesson in capturing the requirements. The team had spend a fair bit of time setting this up as a large Power Automate approval flow. But testing and debugging was a challenge. In the end we moved back to BC Approvals and the whole job was a lot easier and the system more stable.
I do believe the future will be down the Power Automate route - but right now I personally find it easier to meet complex approval requirements using the built in approval workflows.
Business Requirements
 |
| Approval flow specification |
This business is an inventory re-seller and services company. The approvals are split into main sides: Inventory, where there are a lot of very high value purchases to replenish stock for re-sale, and Services, that has lower value operational expense (OpEx) for purchases of consumables used to carry out the service work and high value capital expense (CapEx) for machines used to do the service.
From a business point of view - naturally the limits are much higher when buying stock to re-sell. On the services side most purchases were OpEx with some CapEx and again the requirement to treat stock and consumables differently.
As a decision point for routing the approval we can see there are 4 paths and I managed the approval logic using REASON CODE on the header. A handy field to help direct flows! N.B. You can make a flow that filters for a missing reason code to close the loop if you want to ensure all docs go for some kind of approval.
 |
| Reason codes are a useful header field to help route approvals |
To catch documents with a missing reason code you can create a workflow for that with a simple message - this wont send and approval but also prevent the document from being released.
 |
| On Condition |
 |
| Then Response |
Lets look at one of the routes that for stock, the other routes use the same kind of logic to achieve all the limits and levels required, it was a mix of who is sending the thing for approval, and how many people need to approve, some were any 1 person from a group. The higher values we need all the members of a group to approve.
Stock Approvals - Reason Code = STOCK
- Level 1 (..10k)
- If the approval requestor is an Inventory Manager - auto approve
- If the approval requestor is anyone else - sent to Inventory Managers - 1 must approve
- Level 2 (10k..150k)
- If the approval requestor is an Area Manager - auto approve
- If the approval requestor is anyone else - sent to Area Manager - 1 must approve
- Level 3 (150k..500k) - send to Practice Directors - all must approve
- Level 4 (500k..) - send to SLT - all must approve
Workflow Solution
- Level 1 - Here we take advantage of a natural feature of BC workflows - if the sender is also one of the approvers - the system marks that persons approval entry as approved in the same moment that they send the item for approval.
- So very simply we setup a Workflow User Group for the Inventory Managers
- Practically it was the Inventory Managers and the admin staff that were creating the POs so this met the requirement easily
- Level 2 - Same as above with the auto approval , as it happened some members of the Inventory Manager group were also members of the Area Managers - these were the ones who may occasionally create and send PO for approval
To achieve the logic of "anyone can approve" just ensure the Sequence of your users in the Workflows User Group are all set to 1 and the workflow is modified so that the When Event 'An approval request is approved' there are no filters:
 |
| Allowing any 1 person from the group to approve |
- Level 3 - A very normal templated Order approval filtered for STOCK reason code
- Optionally here you can set the workflow users in an order or set them all to 1
 |
| A more traditional 'all must approve' setup |
 |
| By default when adding users to a group it will increment the sequence |
The impact of setting the sequence all to 1 is that all the approvals will be open at the same same, allowing the team can approve in any order. This is also necessary for the any '1 person from the team can approve' logic. If you don't do this it will always be the person in sequence 1 who has to approve in those workflows.
One more level of complexity you say?
The rest of the flows worked like that - apart from one area where the requirements was for purchase of type Services OpEx between 1k..20k - the business needed any 1 person from Group A to approve followed by a single named approver
Here is how you can do that - using the sequence number and multi-approvals trick from the my other post
 |
| In the line indicated I have sent the approval out again to the named approver |
Here is a note of the Then Responses
 |
| If you cant pick all these on the Then Response of an approval request is approved - then you need to re-read my other post! |
(Thinking about this today as I write this, we could have also possibly met the requirement using a single single workflow user group with the last named person set as Sequence 2 in the group and avoided the re-firing of the approval... maybe! Always needs testing.)
General tips
I cant stress the importance of getting clear documentation from the client. The best way to display this I have found is the viso type decision diagram. You can then annotate this with the names of the flows and key header terms (reason codes or header dimensions etc) for the different routes; this makes a very useful resource when testing / debugging issues.