What is the Exceptions Handler's View
The Exceptions Handler's view is a setting available in Duco that allows you to view your process results through the lens of exceptions management. In this view a whole suite of exceptions handling functionality becomes available, including workflow, exceptions assignment/ownership, aging, audit, and more.
Enabling Exceptions workflow requires just a couple of simple steps. Once made, this will switch-out the default Duco user interface with the Exceptions workflow interface used.
In this view the coloured buckets organise the results based-off their match status. This is a useful view when building a process, where you are interested at seeing the overall results.
However, this view does not capture the review status of any results deemed exceptions, ie. unmatched or partially matched items. So in this 'build view' we won't know who owns a particular exception, what stage in a review workflow it is in, or what the age of the exceptions is. However, by moving over to Duco's exceptions workflow view, all these desirable features and more will be enabled.
Exceptions Workflow enabled view
In this view the colour-coded buckets no longer represent the match status of items, but instead reflect their status within a review workflow. At first glance this new view can be a little disconcerting, as in the build view we were used to red being used as the colour-coding to indicate unmatched items. In this new view the red bucket represents Unreviewed items, the first step in Duco's exceptions workflow. Each time a process is run, any items from a run that are either unmatched or partially matched will be placed in this Unreviewed bucket by default. As these exceptions are reviewed, they will begin to pass through the other coloured buckets.
Even with the exceptions workflow enabled, you won't lose visibility to the overall results. The full results, inclusive of auto-matched items are still accessible to the user, and can be found in monochrome buckets that sit underneath the exceptions workflow buckets.
Note: The new interface will appear for all runs made subsequent to enablement (prior runs will still show the default 'builder' interface).
Switching on Exceptions Workflow
When creating a process, Exceptions workflow is listed as an option in the Settings menu.
However, you will most likely want to make this change from the Settings once your process has been fully configured.
To configure Exceptions workflow you will first need to select a Default group. Members of this group will have the ability to action on the exceptions for this process. Members of other Groups that have been granted permission to the process will still be able to see the results.
Once this has been selected the Exceptions workflow enabled checkbox will be available to be checked.
Working the Exceptions
As mentioned above, any items found to be either partially matched or unmatched are regarded as exceptions that will require attention. As such, these will show in the Unreviewed bucket on the left of the screen.
Clicking on the Unreviewed bucket will take you into the individual results. Here the Unmatched and Partially Matched items can be distinguished by their status in the Match status column. For the partially matched items, individual breaking fields will conveniently be brought to your attention with red highlighting.
Using the checkboxes to the left of the ID column, you can either select individual or multiple items that you would like to perform an action on. Once selected, the Workflow menu at the top of the screen then allows you to choose which actions to perform.
Assigning the exceptions
The first step in the review workflow is to assign an Unreviewed item. You can do this by selecting Assign to user. This will present you with a drop-down listing all the users in the Default Group.
An item can only be assigned to one individual, who then assumes responsibility for the exception - although the exception can subsequently be passed to other individuals or Groups, as required.
It is also possible to bulk assign exceptions from the Workflow menu on the run results screen. You can either bulk assign from a single page:
Or you can use filtering to bulk allocate items across multiple results pages:
The exceptions lifecycle
The next step is to select Start review. Once you start a review the status of the item will transition to “Under review”. This will also push the item into the Under review bucket.
This is the stage in the workflow where it is acknowledged that somebody is actively working the exception. See the next section as to how people might choose to capture their investigation against an exception.
Finally, once an item has been fully investigated, it can be taken to the final status of Pending. Again, this can be done by clicking on Actions and then selecting Mark as pending.
This will push the item into the Pending bucket.
This diagram shows the flow in its entirety. You can see that there is always an opportunity to take a step back from any stage of the workflow. So if something needs further investigation, or marked as Unreviewed, this is always possible.
In rare instances where a break cannot be resolved in your source system it may be necessary to manually Close or Force close the exception. Close allows you to close out a single occurrence of a break, whereas Force-close closes out the current occurrence of a break as well as all future occurrences.
The ability to perform these actions is dependent on the user having access to either the Exceptions closer or Exceptions Force-closer global roles (or both).
It is possible to manually Close an exception in Duco which is Under review. This option can be found on the Workflow menu, although, as mentioned above, is only selectable for users with the Exceptions closer global role assigned to their account.
If necessary, an option is available to Reopen items that have been closed.
Close can be regarded as an optional stage within the review lifecycle. Some organisations choose to implement a workflow that does not include Close.
Annotating the exceptions
It's common that users would like to capture elements of their investigation, such as break classification or resolution, against their exceptions. Duco offers to two approaches to this that can be used on their own or in conjunction with each other.
The first is the use of labels. These are fixed classifications that you can append to an exception. Duco does not provide any default labels, so any that you find available to you have been created by a Label Administrator within your organisation. In this example I have clicked on an individual exception's ID, which returns a full-screen view of that one particular break. You can see on the left that I have been provided with a variety of labels to choose from.
Labels are colour-coded, which can be useful when this translates into severity of the classification. Users can apply as many labels as are required to the exception.
The advantage of labels is that they offer a standardised way of classifying exceptions. This can help avoid any confusion within a team about the nature of the exception. It can also provide a powerful way to derive metrics across time and/or processes. Read more in our Data Platform section about some of the metrics that you can report from Duco.
The other way you can annotate an exception is through Comments. This is a more free-form way to capture elements of the investigation. Simply type in your comment and it will not only be saved, but will also be time-stamped and have your name set against it for the purpose of audit.
Note that when you make a comment it will lock after 5 minutes. This is also an audit feature.
Commenting and labelling can be done on individual exceptions, as a bulk action across multiple items, or automated as part of Workflow rules (see end of this page).
In the Workflow column you'll see an icon of a box with an arrow coming out of it.
If you click on this Duco will display the audit trail for that particular exception.
It's also useful to note that the other tab that display, the Overview, will open up the section of the exception where you can add or view comments and labels.
Duco offers an ability to automate exceptions handling using functionality called Workflow rules. Typically configuration of these rules is handler by a Builder, but it often makes sense to have the end-users of the process work alongside the Builder creating the rules so as to enable functionality that is most beneficial to the Exceptions Handler.
When creating a process, Workflow rules is listed as an option in the Settings menu.
Workflow rules are constructed using Natural Rule Language. This language allows you to build statements that drive automated behaviour.
Workflow rules are applied in order. This means that
- If several rules act on an exception (e.g. several rules assign the exception to different users), actions on later rules will overwrite earlier rules.
- You can refer to earlier actions in later rules (e.g. if you labelled an exception in earlier rules, you can write a rule which uses that information: "if the exception is labelled X, assign it to someone).
This screenshot is an example of some of the types of rules that can be created. It's always worth giving some thought when onboarding a process to Duco as to what sort of automation could be applied to the new process.
Tips and Tricks
- Don't forget that we have a Fullscreen view available, that can allow you to see more detail on screen.
- Pinning items is a handy way to keep particular items on screen as you navigate between buckets (useful for identifying roll-up candidates, or unmatched items that could perhaps be a better fit for a partial match).
- When you filter on items that you want to bulk action on and the results run to more than one page, Duco will give you the option to either action on the items on-screen only, or to action across pages.
- Bookmarking can allow you to save particular views on your exceptions. This can significantly streamline your day by saving you from filtering and sorting again and again.