Using the capabilities of case activities to automate case handling

In this fourth article in the series (4 of 6), where we look at how to digitize a complete business process with a lot of automated case management included, we will look more closely at the case activity list and the DCR Graph on which it is based. Check the earlier articles to see how the form is set up in Interact, how form submissions are pulled into WorkZone and how case activity lists can be automatically applied to new cases.

In our example, where we have a self-service application form that can be used if a citizen wishes to raise the flag of a foreign nation in Denmark, all the case management is done through a case activity list. WorkZone Case Activity Lists are based on DCR Graphs that you import into KMD WorkZone. For more information and additional help to you get started with DCR Graphs and Case activities, check out the DCR wiki and the WorkZone documentation.

Now, the example we use is quite simple in terms of the types of connections and rules governing the process and is mainly meant to showcase some of the things you can do with DCR Graphs when these are combined with KMD WorkZone. It is not focused on showing all that is possible with DCR Graphs in general.

Many of the activities are executed automatically by WorkZone. In many cases in this example, the complete application process can be handled without human intervention. However, to look out for events where the raising of a foreign flag may be deemed to be potentially problematic, you will scan the application for specific stop words. If you find any of those words, pick the application out of the queue to be handled manually. For this simple example, the words we have categorized as stop words are:

• Boots
• March
• Protest

If you find any of those words in the application, you will have a caseworker evaluate the application. Otherwise, you approve the application automatically. In both cases, the applicant is informed of the result through a Smartpost-letter.
Let us start building the graph. Go to the DCR Designer. If you do not already have an account, you can sign up for a free account that you can use for test purposes. Start a new graph and select a WorkZone template to use (to follow along in this example, you need to use the template 2020.1 or newer and your WorkZone backend also needs to be 2020.1 or newer).

Once you click Save, the designer window will load with a new graph called WorkZone Case Activity Template (2020.1). Change the name to something more descriptive. In our example, we call the graph Flag application. You change the name by clicking the title

Remember that the graph, or rather the case activity list, is automatically added to the case once the application is received from Interact. Now, part of what we will be doing is searching for stop words. And we will look for these words in different places in KMD WorkZone – both in the field where the description from the occasion is mapped to, but we will also do a broader free text search and document search. In the simple example this probably would not be necessary, but we include it just to say that this is also possible if data on the case comes in in a less structured manner.

For this search to work, we need to allow a little time for the backend to index everything. To allow this to happen, the first activity we have in the graph is one that will halt further execution for 10 minutes. Exactly how long we need to wait to make sure the indexing is complete depends on a lot of factors, but 10 minutes should be plenty for most circumstances.

Add your first activity to the canvas and label it: Delayed Start to ensure proper free text indexing of the application and attachments. We want this activity to be executed automatically once the case activity list is loaded, so we will apply the role AUTO. You do this by selecting the activity on the canvas and opening the Resources section in the Options panel on the right. Then select the role AUTO (read more about automatic execution of activities in the documentation).

Once the indexing is ready, the next thing to look at is to initiate case handling. So, first step is to indicate this by setting the case state to Being processed which has the code UB. To update fields in KMD WorkZone, we need to select one of the activity types that comes with the WorkZone template: UpdateEntities. Add another activity to the canvas, give it a label of Set State (UB). In the Options panel, open the Advanced section and in the Event Type dropdown, select the correct type. As soon as you have selected the type, a window pops up where you need to specify the parameter for this activity.

What we want to do is change a field on the case. In the data model cases are called Files. So, the entity you want to change is Files. Next, you need to let WorkZone know on exactly what case(s) you want to change something. Quite often you only want to change something on the case the case activity list is running on and the template is prefilled with what you need to input for this situation: ID eq '{Case.ID}'. Basically, the filter is saying the we want to filter out all cases except the case where ID is equal to the ID of the case we are currently on (case.ID). And we are in luck, because the properties field is also prepopulated with exactly what we need for this activity – we want to make it clear that the case is being processed by setting the value of the state field to Being processed (UB): {"State_Value":"UB"}. This activity should also get the role AUTO, so that it will be executed automatically.

Next, you need to connect the two activities. You do this by first clicking on the first activity and then right-clicking on the second activity. This brings up a contextual menu, from which you can choose the connection you need. The kind of connection we need here is a condition, so select that.

The pattern with setting up connections is basically to first click on the activity you want a connection from and then subsequently right-clicking the activity you want the connection to and choosing the right connection type. If you make a mistake, you need to click the connection, press delete and start over.

A condition-relation means that the first activity must be executed before the second one. Now, this relation is also where we actually give the back-end some time to do the indexing, because we will add a delay to the connection. A delay states that at the second activity cannot be executed before a set amount of time has passed. We want 10 minutes to pass and so we select the orange connection and in the options panel type in PT10M (in DCR you need to use the ISO 8601 to specify durations).

Read more about the different connection and in DCR graphs in the DCR wiki.

You now have two activities where the first one does not actually do anything other than trigger a timer and tells WorkZone to wait 10 minutes before continuing. Once those 10 minutes have passed, WorkZone will automatically change the state of the case.

It is almost time to carry on with adding activities but before we do so, we will exclude the first activity once the second on has been executed, because it should not be possible to execute the first activity again. You do this by selecting the second activity, right-clicking the first one and adding an exclude connection. And you also want to ensure that the second activity is only executed once. This you do by letting it exclude itself. You first click on it and then right-click and select exclude. Your graph should look like this now:

You may ask why we did not also just let the first activity exclude itself. That is because of the delay we have on the condition activity. As soon as an activity is excluded in DCR, the connections from that activity also “do not exist”. So, if we let that activity exclude itself, we would not get the timer to start the next activity after 10 minutes. This is important to remember when doing your modelling.

What you now want the case activity list to do for us, is to check for specific words in the submitted application. If you find any of those words, the application will be taken out of the automatic processing in order for a case worker to look at it. So, you need to set up an activity that looks for those words in the application. In the simple form we have used, it should probably be enough to check the field where the applicant is asked to describe the occasion. But it could also be possible to check any documents on the case or just do a general free text search on the case. Here we will look in detail on how you search the specific field and then you can look in the example graph to see how you search documents and do a general search.

Go ahead and add another activity to the canvas. This time you need to select the event type ValidateEntities. What this does is basically to look for something somewhere you specify in WorkZone and return true if it is found. There are three specific words you want to look for in the application:

• Boots
• March
• Protest

Now, in the parameters window that pops up as soon as you select the event type, you first specify which entity you want to look at. Again, you can go with the default which is Files (cases). For the filter you will again look only on the case you are currently on but you will need extend the filter to get to only return true if we find one or more of the three stop words in the field that hold the description of occasion from the application. The occasion was mapped to the field ANL_Value, which in the UI is called Occasion. To find the code for the field Occasion (which is a custom field), you can open the QueryBuilder, select Cases (Files) as the entity and in the select section, start typing “Occasion” and when you find the field, you can see the code that you need in brackets:

You want the filter to return true if we find any of the three stop words in that field. You do this by setting the filter up as follows:

ID eq '{CurrentFileKey}' and ANL_Value eq '^*BOOTS*|^*MARCH*|^*PROTEST*'

The properties parameter is a required field, but we do not actually need it here, so we just need it to contain something that will always be true. This kind of case we set it up so that the case category is always Flag application, which has the code FLAG. In the model case category is called file group and that means the field we are after is called FileGroup_Value. So, the configuration for the activity will end looking like this:

You should add two more activities to search for the stop words in documents and a general free text search. I will not go into details about those two activities. You can look in the example graph how they are setup.

You want those three activities nested in order to have a better overview. You do this by adding yet another activity to the canvas and labelling it “Check for stop words”. Then you click one of the activities you want nested, right-click the “Check for stop words”-activity and select “Nest under”. You do the same with the two other activities that should be nested.

All the three activities that check for stop words are of the type ValidateEntities. ValidateEntities allows you to validate values on a case based on a condition that you define, and if the condition is met, the subsequent activities will be included or excluded. The ValidateEntities activity type works in connection with guards that you define on the Include and Exclude relation types. If a validate entity is included in a graph, it will always be evaluated automatically. To make this easy to spot when looking on the graph, it can be a good idea to give a role such as e.g. ROBOT. You can add this role in the options panel. It does not change the behaviour of the graph but provides a better overview.

You also need to give these three activities some more descriptive IDs (you will get back to using these shortly). Click on the activity and change the IDs in the options panel (under Advanced)to the following:

• Check for stop words in "occasion": StopWordOccasion
• Check for stop word (document-level): StopWordDoc
• Check for stop word (case-level): StopWordCase

You also only want the graph to check for the stop words once the state of the case has been set to “Processing”, so you want to exclude the three stop word activities initially. You do this by selecting the activities one after the other and unchecking the “Included” box below the label in the Options panel. Furthermore, you want the check for stop words to only run once, so you need to have each of the nested activities to exclude themselves. And then you set an include-connection between the Set State (UB) and the parent “Check for stop words” activity. Now the graph will check for the stop words after the state of the case has been set to “Processing”. Your graph should look like this now:

Now that you have you activities that look for stop words all set, it is time to model what should happen in the two different cases (stop words found or no stop words found).

In this article, we will look at the scenario where no stop words are found and then we will address the other scenario in the next article.

If no stop words are found, there is one more check we want to do before we automatically grant permission to raise the foreign flag. In the self-service form, it was possible to provide a contact phone number, but the field was not required. If the applicant has decided to not include a contact phone number, we would like to manually have a look at the application.

So, you need to add another ValidateEntities activity to the canvas. Label this one “Check for contact information (Phone)”. You can leave the entity and filter parameters as they are as default. In the properties field, we need to find the Contact phone field (find the value you need in the same way as described above) and check if the field is empty:

The content of the properties parameter is in a JSON-like structure and what it states here is basically if contact phone is empty (null) on the case the activity is running on, it should evaluate to true.
You do not need to set a validation interval, so leave this parameter as it is.

You want to have this activity excluded to begin with and you also want it to exclude itself after execution so that it is only executed once. And you also need to change the activity ID for this one to KTLFEmpty.

Before you do anything based on whether or not there is a contact number, you need to go back and set a connection from the parent “Check for stop words” activity to this new activity that you just created. It should be an include-connection (the green one). Once you have set the connection, you click the connection arrow and find the guards field in the option panel. Here you type in:
StopWordCase!=1 and StopWordDoc!=1 and StopWordOccasion!=1

This basically says that all three of the checks for stop words should be negative – that is to say: no stop words were found. So, if none of the stop words were found, the “Check for contact information (Phone)”-activity will be included and executed.

Now you can carry on to the next activity that will be executed if there is contact phone number provided. Add another activity to the canvas. This time the type should be UpdateEntities and you want to leave the entity and filter parameters as they are. The properties parameter should be changed to: {"AFG_Value":"BEV","AFGDATO_Value":"+0d","State_Value":"FB"}. That will update the following properties on the case:

• “Ruling” to “Granted” (BEV)
• “Ruling date” to today’s date (to set a date field to today’s date, you can use the +0d code)
• “State” to “Fully processed” (FB)

Both Ruling and Ruling date are custom field. If you do not already have them in your system, you need to set them up for this to work. Of course, you can also use other fields.
Give the activity a label: “Set ruling, ruling date and state”. Again, to ensure the right order of execution, this activity should be excluded to begin with and should also exclude itself after execution. And you need to set the role to AUTO, so the system will execute it automatically.

You then need to add an include-connection from the check phone activity to this one and set up the guard: KTLFEmpty!=1.
Basically, the case is now fully processed, but you also need to inform the applicant, so you can add another activity of the type Sendsmartpost. This should be executed after the last activity and only executed once (set an include-connection from the previous activity to this one, exclude it initially and set it to exclude itself).

We will not go into a lot of details regarding Smartpost in this article, but here is how we have configured the parameters for the activity in our setup:

You need to have a template letter stored in WorkZone, that will be used to inform the applicant of the decision. In our case the template has the document ID 10313. And we are also adding an attachment to the letter with some general information. This attachment has ID 10315.

You can check the WorkZone documentation for information on setting up a letter using content controls so that it can be personalized with details from the case.
In the recipients parameter, you type in ANS. This is the role that was mapped to the applicant back in the first article. You are basically telling Smartpost to send the letter to the contact on the case who has the role Applicant (ANS).

When you add a Sendsmartpost activity, the default ProcessOwner is set to the case handler of the case. This will not work in this case because the case handling is done automatically, and we have not assigned a case handler. So, you can change this parameter to the keyword {DocumentCaseHandler}. This will then use the case handler on the templates used for the letter and attachment as the process owner for the Smartpost process (so please ensure those documents have a case handler that you can use for this).

That just about wraps up this article. We now have a completely automated flow for all applications that do not contain any of the stop words and where the applicant has provided a contact phone number. In those cases, all is done without any manual steps and the applicant receive the positive response in a Smartpost letter shortly after having sent the application.

In the next article, we will look at handling the cases where there are stop words in the application or there is no contact phone number. And then we will show you how to get the DCR graph into WorkZone as a case activity list.

Here is a reminder of the topics for the different articles:

• 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 (this article)
• The connection between the DCR Designer and WorkZone
• A summary article where we recap how all the different elements work in unison