Workflows are ways in which you can manage processes. Workflows can be used to automate actions based on other actions and are frequently used for approvals. For example, a workflow can be created to prevent a Purchase Order from posting until someone with the required authority sanctions the action. You can set Workflows up to be approvable by either User Groups or individuals. In this post, we are going to run through several examples as to how you can run workflows in Business Central.
Setting up Workflows
In the Workflows page, you can see what workflows have been set up against different entities. It’s advisable that users should utilise the predefined Workflow Templates within Business Central instead of starting from scratch as they can be challenging to set up. To do this, go to ‘Workflow Templates’, ‘Actions’ and ‘New Workflow from Template’. From here, select the relevant Template. Here, we have selected an Item Approval Workflow. See below:
Inside, you should get this page:
Workflow event
This relates to an event or action that occurs within the system that will trigger a response. For example, adjusting a customer’s credit limit or posting an order.
Workflow condition
This refers to the condition that moderates the workflow event that you specified in the ‘When Event’ field. When you select the field, the ‘Event Conditions’ window opens in which you can specify condition values for predefined lists of relevant fields.
Workflow responses
This relates to the actions that will be performed by the system when an event occurs that meets the predefined condition. If you click into the blue text, you will be able to open a subpage to edit the Workflow. If I click into the blue text in the ‘Then Response’ column, I can establish several key fields. See below:
Within the set response you have created, there are options depending on what the workflow is. Make sure you are on the correct Line at the time for the options to appear. If the top Line on the above image was highlighted, it would say ‘You cannot set options for this workflow response’.
The ‘Due Date Formula’ field determines after what point does the workflow become overdue. The ‘Delegate After’ field allows you to determine when authority to authorise the Workflow request is passed on to someone else. You can have the ‘Delegate After’ field set to a lower value than the Workflow ‘Due Date’ meaning authority is passed on prior to the Workflow becoming overdue.
The ‘Approver Type’ field allows you to specify what type of person(s) has authority over that particular event. There’s ‘Approver’, ‘Salesperson/Purchaser’ and ‘Workflow User Group’.
Approval Limit Type
The Approval Limit Type allows you to determine the way in which the Workflow approval request is sent and to whom. Depending on what values you enter, new fields will appear. For example, if our Workflow had an Approval Limit Type of ‘Specific Approver’, an Approver ID entry field would appear to you to select who the Specific Approver is.
The other options in the Approval Limit Type are:
- Approver Chain
- Approval chains work on the basis that there’s a hierarchy of approval and the request won’t be accepted until it has been approved by the person with the authority to approve, and those below.
- Specific Approver
- All goes to one particular individual. For example, all Sales Credit Memos go to Craig
- Direct Approver
- Goes to the next person in the chain, regardless of their limits
- First Qualified Approver
- If it was a monetary value that exceeded the approver of the user who requested it, it would simply send the request to the first person it gets to in the chain with sufficient authority to approve
Workflow Responses
The Workflow Responses themselves vary on how you create the Workflow. In the above situations we have been using a Template which is very much advised. In instances where they are made from scratch, the responses may not be limited to simply ‘approve’ or ‘reject’. Below is an example of where you make a Workflow from scratch, there are more options to be flexible:
An example
Using an Approval Type of ‘Salesperson/Purchaser’, the specific Salesperson/Purchaser will be the first one with the power to authorise. But if the salesperson’s approver has a Value limit and the amount in question exceeds that, it will be passed onto the approver of the approver (i.e. up the chain).
Let’s create an example. If Janet makes an order with ‘IT’ as the salesperson/purchaser code, then Brian is in charge of approving that. Brian would not be in charge where the amount in question is over what he is authorised for. Where it is over that value £5000, then David will be the approver who, as we can see, has an unlimited authority to approve payments.
If it’s set up to be for ‘Approver’, then the request would merely go against the Approver of the User who created the approval request.
If it was for a Workflow User Group, it would go to the Users assigned to the User Group. Where you click to make the request go to a Workflow User Group, then a new field will appear underneath allowing you to choose which one.
Approval User Setup
Both the requesters and the approvers of Workflows should be set up on the Approval User Setup page. The system needs to recognise what action is requested/required for every individual or group in the system. You can also set how approvals are communicated to the people involved, i.e. entering their email addresses. And then going into ‘Notification Setup’ and making sure E-mail is the default communication method.
Workflow User Group
Within a Workflow User Group record, you will find something that looks like this:
If you have the Sequence No. set to the same number, then both users will receive the approval request at the same time. If one is 1 and the other is 2, then 1 will get theirs and then it will go to 2 to accept. Both have to accept in order for it to be approved.
To access ‘Approval Request Entries’, type it into the search bar. For those who don’t have permission to authorise the workflow permission request or didn’t send the request originally, it might not show in there. When you initially create a Workflow, you can set an individual approver there.
Delegation
Approval requests can be delegated. This is typically used where the person normally responsible is out of office. To do this, go to the Requests to Approve page, click the relevant Line and then Delegate.
Item Approval Workflow: using the ‘Blocked’ field
Items can be setup regardless of Item Approval Workflows. The system cannot stop people from making them, except in one particular case. This one exception is when you remove all conditions entirely. The problem is that this creates approval requests for everything which is extremely counterproductive. We believe using a template where ‘blocked’ is turned on by default is the best approach as then no transactions can be made with the field on, but if it is turned off then an approval request is sent.
How does this work?
This makes an approval request as soon as the person who has changed the field leaves the Card. When they come back to the Card prior to it being approved, it’s still blocked. So if you did accidentally turn off ‘blocked’, you can turn it back on before leaving the card and it won’t send an approval request.
When you create a Workflow from an Item Approval Workflow template, amend the ‘When Event’ top line. The template’s default value is ‘approval of an item is requested’. This caught me off guard a few times. I expected it to work on the basis (with its name) that an approval would be sent for the creation of a new Item. However, this isn’t the case. So, as you can’t stop someone making an Item, the best way around this is to have it set that the Workflow Event top line is ‘An item record is changed’ which is why the ‘blocked’ functionality is so useful, as that needs to be off to allow transactions.
Below is how we set up the Workflow to work effectively:
Other Workflow experiments
As a side note, I experimented with Workflows with the type set to ‘Item Approval Workflow’ and an ‘Event’ top Line as ‘Approval of Item requested’. This didn’t work as I hoped. The reason this caused issues is that users can bypass conditions by simply not clicking the ‘Request Approval’ button on the Item Card. If they clicked it, then they would not be able to transact it. I can change the record but can’t transact it. However, if I am using an Item which (on the Card) I haven’t clicked ‘Request Approval’, then I can transact freely. With something like this, it would be unlikely people would remember to press this each time.
It’s worth noting that for entities with multiple conditions attached, as soon as one is triggered, regardless of if the second is satisfied, it will be blocked. Once an item has had an approval request made, it will need approving prior to further action. For example, imagine a sales orders which has two approval workflows tied to it. The first condition may be that anything above the value of £1000 triggers an approval request. The second condition states that sales orders for Item ‘7500ABC’ require approving. If approval’s required for the Item, then it’s irrelevant if the order Unit Price is £900, it error regardless. As the first condition is pending approval, the system won’t let you proceed further.
Over-Receipt Codes and Workflows
A short demonstration of Over-Receipt Codes
You can set Workflows for Over-Receipt Codes. In the example above, we have a Purchase Order Line with an Over-Receipt Code on the Item Card set to a maximum of 10%. This means, anything over the Quantity value but within 10% of it in the Qty. to Receive will be acceptable. So, if the Qty. to Receive was 111, it would error. Below it lays out the error message: ‘you cannot enter more than 10 in the Over-Receipt Quantity field’.
Whilst it’s normal to put a reasonable cap on the Over-Receipt Code, the highest value you could set the Over-Receipt Code value to is 100%. If you set this to the default limit, where you order one item, you can receive two.
Setting up Over-Receipt Codes is simple. On the Item Card, within the ‘Inventory’ tab, establish the Code and the maximum percentage over the Quantity you’d be willing to receive. This field allows your incoming amounts to be over the ordered amount, allowing you to be flexible where necessary, if approved.
The Over-Receipt Workflow itself
Let’s look at the format of the Workflow:
The first Line says that an approval request is created when the Document (Purchase Order) has a Status of either ‘Open’ or ‘Released’ but only where there’s a Purchase Line with the Over-Receipt Code set to ‘OVERRCPT10’. The ‘OVERRCPT10’ filter isn’t showing on the outside but by clicking into the ‘On Condition’ first Line, it would be visible.
Notice how there are two lines for approving the approval request. The first, is if there are no pending approvals, remove the record restriction. The second says that where there’s more than zero pending approvals, send an approval request.
In the first ‘Then Response’ Line, this is what we have:
In the second Line of the ‘Then Response’ Column, we have a setup like this:
This dictates the order of events when removing a restriction. Here, we remove the prohibition to post the document. Step one is removing the limitations laid out in the ‘Then Response’ section. Step two releases the document and finally the Over-Receipt is approved.
Over-receipt example purchase order
When we create a Purchase Order with an over-receipt, I will input my quantity. We then release the order and either change the Qty to Receive or the Over-Receipt Quantity, assuming they fall within the Over-Receipt Code Quantity that’s applicable to the workflow. We will then be notified at the top of the order to say there’s an over-receipt quantity:
At this stage, I can’t post the order:
To resolve this, I must click ‘Request Approval’ and ‘Send Approval Request’. This will send an approval request to the specified user and create a record in the Approval Request Entries page.
Finally, make sure the workflow is ‘Enabled’ before using it or else the rules configured won’t take effect.
Closing remarks
Workflows can seem daunting to implement but once you’re past the initial setup, it’s plain sailing. If you have any feedback or questions, please don’t hesitate to get in contact with us. We’d love to hear your thoughts and ideas as to how we can improve!