Going from a DCR Graph to a Business Process in WorkZone

This article is the 5th in a series of 6, where the aim is to show a complete example of how to digitize and to a large extend automate a business process in KMD WorkZone. This time around we will go through the rest of the graph from the previous article and then show how the import into KMD WorkZone is handled.

Check the earlier articles to see how the form is set up in Interact, how form submissions are pulled into WorkZone, how case activity lists can be automatically applied to new cases and how the first part of the graph is setup.

So, after in the previous article having handled the cases where none of the so-called stop words were found in the application, we will now look at how you handle the cases where we do find some of the stop words in one of the received applications.

As you may recall, the aim of this process is to automatically approve most applications without the need for a case worker to be involved at all. However, you want to scan the applications for a few key stop words. If these words are found in the application, you want to take these applications off of the automatic processing and have a case worker assess the application.

The stop words that we are looking for in this example are:

• Boots
• March
• Protest

In the graph we have three different activities nested under the “Check for stop words” activity. For the simple form that we have for this specific example, this probably would not be necessary. But we have added a few extra ones to provide a bit of inspiration for other potential scenarios. Briefly described, the first activity looks for stop words by doing a general search on the case, the second activity scans through all documents on the case to see if they contain any of the stop words and the last one looks specifically in the field “occasion”.

In the form we are working with, the only place an applicant can really put any information about the event, is in the field “Occasion”. Therefore, this time around it should this be enough to just focus on that field. In the previous article we looked at how to set up the activity. Now we will continue by focusing on what happens in the case where we do find some of the stop words.

For all the activities that we add as a part of this article, we need to make them self-excluding, which basically means that once they are executed, they are excluded and cannot be executed again. You do this by selecting the activity, right-clicking and selecting Add exclude.

The first thing you want to do after finding one of the stop words is to change the state of the case to Pending, which has the code AV in our test system.

So, you need to add an activity to the canvas, select the role AUTO (to have it executed automatically), select the Event Type UpdateEntities, remove the check in included and set the parameters like this:

• Entity: Files
• Filter: ID eq '{CurrentFileKey}'
• {"State_Value":"AV"}

You should give the activity a label of Set State (AV).

Now that you have the activity, you can go back and set up the connection from the Check for stop words activity, so that the state will be changed once the stop words are found.

You do this by clicking the Check for stop words activity, then clicking your new Set State activity and selecting the option to add an include-relation. As in the previous article, we also need to add a guard here. So, click the connection and in the guard field in the options panel, write:

StopWordCase=1 or StopWordDoc=1 or StopWordOccasion=1

This basically tells your process that if any of the three activities looking for stop words finds any of the stop words, you want the Set State activity to be included. And as it has the role AUTO, it will be executed automatically.

The new state of the case can be used to make it show up on a dashboard of cases in KMD WorkZone that need attention from a caseworker. Once they pick up the case with one or more stop words in it, they can look through the case and decide what should happen.

So, you should add another activity to the canvas (label: Determine outcome manually). You want it to be clear that this activity should be handled by a caseworker, so you need to add a new role of caseworker and assign this to the activity. You can do this in the options panel for the activity, under resources. As the previous activity, this one should also be an UpdateEntities type, updating a field on the case, but this time you want to update the field Ruling, which has the code AFG in our test system (it is a custom field, so you need to make your own if you follow along). We will leave the value empty as this has to be decided by the caseworker:
Propertiies: {“AFG_Value”:”””}

In WorkZone, once a caseworker wants to execute this activity, a dialogue box will open where the ruling can be specified. In our system the Ruling field is pointing to a custom droplist containing the different possible rulings.

In our test setup the Ruling field is also used in other kinds of cases and there are values on the droplist that should not be used in this kind of case. Therefore, we use another ROBOT activity to check what ruling was chosen and then get the caseworker to reselect, if an invalid option was chosen.

To get this to work, add two more activities to the canvas (both not included to begin with):

Label: Read decision

• Event type: GetValue
• Entity: Files
• Filter: ID eq ‘{CurrentFileKey}’
• Property: AFG_Value
• ID: AFG

Label: The selected Ruling code is invalid!

• Event type: Check

Create an include relation from Determine outcome manually to Read decision. And another one from Read decision to The selected Ruling code is invalid! – this time adding a guard:
AFG != "AFS" && AFG != "BEV"

This basically states that if the ruling code (which you store in the activity Read decision that you gave the ID AFG) is not AFS or BEV, the activity should be included, and the caseworker will be required to select another ruling. This the caseworker will do by checking/executing the activity and be taken back to the Determine outcome manually activity. So, you need to add an include relation from the The selected Ruling code is invalid! back to Determine outcome manually. This will basically be a loop that will continue until the caseworker has chosen a valid ruling.

Once a valid ruling has been chosen, you will want to have another activity updating the case with a date of the ruling and a new state:

Label: Set ruling date and state

• Role: AUTO
• Event type: UpdateEntities
• Entity: Files
• ID eq ‘{CurrentFileKey}’
• Properties: {"AFGDATO_Value":"+0d","State_Value":"FB"}

Set an include relation from Read decision to this new activity and apply a guard:

AFG = "AFS" || AFG = "BEV"

The guard states that if the ruling code is either AFS or BEV, we can continue to Set ruling date and state which will be executed automatically and update the case.

If you look at the properties for the activity, you can see that update the field AFGDATO (Ruling date – another custom field) is set to a value of +0d. This is a WorkZone specific shorthand code for putting in today’s date. You can set the State to FB (or whatever state you wish to use) which in our system is the code for the state Fully processed.

Now, there is just one more step left in our process and that is to inform the applicant. So, we either need to send them a permission denied or a permission granted letter. If we start with the latter, you already have that activity on the canvas, and we used it at the end of the previous article.

Add an include relation between Set ruling date and state and Send permission granted letter and apply a guard: AFG = "BEV". The guard takes the value from Read decision (which has the ID AFG) and check if it is BEV which is the code for Granted in the custom droplist that we use in our test system to store the types of rulings. You can adjust it to something else that fits with your setup.

So, the result will basically be the same as if there had not been any stop words found in the application and the same Smartpost letter will be sent to the applicant. Only, this time around the application has been checked manually by a caseworker.

On the other hand, we want a different letter sent if the application is denied (code: AFS in our test system). To do this you add another activity that should be excluded initially::

Label: Send permission denied letter

• Role: AUTO
• Event type: SendSmartPost
• Letter: /Records?$filter=RecordKey eq '8661'
• Attachments: /Records?$filter=RecordKey eq '5013'
• Recipients: ANS
• ProcessOwner: {DocumentCaseHandler}

The letter and attachments parameters will need to be adjusted to find the right documents in your test system.
And now you just need to add the guard: AFG = "AFS". This will check that the application ruling is AFS which in our system is the code for Denied. If so, the application denied letter will be sent to the applicant via Smartpost.

That basically is what we wanted the process to cover for now. You could continue refining the process and add more activities. But for the sake of brevity, we will stop here.

Your graph should look something like this:

And once again, here is the link for the example graph.

Only now we come to what the headline of the article refers to – taking your graph from the DCR designer to WorkZone so that you can use it for your case management.

There really are only are two quite simple steps to it:

1. Export the graph as an XML-file from the designer
2. Import the graph in WorkZone Configurator

In the designer, you go to File > Export as XML. Then you select a place of your choice to save the file.

Then you need to open WorkZone Configurator and go to Process > Case activities. On that page, you click the plus-button down in the right corner.

In the dialogue that opens, you click the folder icon in the DCR graph field to browse to the XML file. This will then prefill the name and description field with the information that you provided over in the designer.

You can modify this along with the localization fields, start date, end date and the access code. We will just leave them as they are.

And that is it. Now the case activity list can be started manually from a case or (as in our example) be applied automatically using a case monitor (you can go back to the article about the case monitor, to look closer at this or to use your own graph for your case monitor).

In the next article we will sum up and look at how it all works together across the different tools.

Here is a reminder of the different articles in the series:

Mapping input from an Interact form to fields in WorkZone
The Interact service workflow – how you connect Interact and your WorkZone backend
Using the case monitor to automatically initiate case management
Setting up a DCR graph as the basis for a WorkZone case activity list
The connection between the DCR Designer and WorkZone (this article)
A summary article where we recap how all the different elements work in unison