New Features of NAV 2016 - Approvals Using Workflows

Many of our customers were so excited when they heard about the document approval functionality in NAV, especially in Purchasing. However, when it came to the point of explaining the functionality in detail, you could see faces frowning and heads shaking. No, standard functionality did not quite fit their approval process.

In all the approvals I have implemented, none was a standard implementation. Each required additional development.

So it was with some trepidation that I started investigating the new workflows in NAV 2016. And I am happy to say that are some long expected features have been introduced.

In NAV 2016 approval templates have been replaces by workflows. Microsoft provided several workflow templates that can be used to create new workflows. A workflow is comprised of a set of events. For each event a set of response steps can be defined.

Approval limits and types are defined as part of the workflow.

Figure 1. Approval Type and Limit Type set up per workflow.

There are 3 options for the approval limit type:

Approve chain – this is similar to the old Limit Type of Approval Limit. On requesting an approval, entries are created for all the users who are required to approve.
Direct approver – this is similar to the Limit Type of No Limit. One approval entry is created for the user’s approver.
First qualified approver – this is a new option. It is based on a Limit Type of Approval Limit, however, a single approval entry is created for the first qualified approver.
There are three approval types:

Approver and SalesPerson respectively – they work as before, using the approval user setup. The user and user associated with the salesperson respectively trigger the approval
Workflow User Group – this is a new feature, which replaces Additional Approvers. The difference is that the Workflow User Group approval type cannot be used in addition to the other two approval types. With workflow user groups, it is possible to control the sequence of notifications.
In additional to emails, approval alerts can be created as system notifications. Notifications are now processed through job queues. This allows more flexibility in setting up notifications at user level, and defining the frequency for sending the notifications. When using emails, notifications can be cumulated in a single email.

Figure 2. Notifications templates used to set up notifications per user.

Figure 3. Notification frequency set up for each approval user.

There are also a few UI improvements, which we always used to develop as part of approval implementations:

Having a separate page for Requests to Approve.
Approve/reject buttons on document cards
Approval and workflow fact boxes on documents
Delegations are also set up at workflow level, with the option to automatically send them when the approval entry has expired. This is definitely an improvement over the old solution, where the approval admin had to delegate the entries. However, if delegations are to be used when an approver goes on holiday, this is still a cumbersome solution.

A major benefit of workflows is that approvals can be easily extended to other areas of the system. Microsoft provided the approvals for journals for example – in this case approvals are not using approval limits. Customers or vendors can be set up to be approved when created.

With workflows Microsoft have introduced some improvements in approvals, which I think will be very welcome by customers:

Approved by first qualified approver
Journal approval
Separate pages for regular users and approvers
Approve docs directly from the document
fact box for approval details
system notifications used for approval alerts
They have also made it easier for partners to extend approvals or other areas of the system.

There is still room for improvement. I would like to see different approval levels for sales and purchases, a method of ‘peer control’ for purchasers who place orders within their approval limit, a way of setting up a time limit for delegations at user level.