Workflow - Data360_DQ+ - Latest

Data Store node

When building workflows for case stores where a Case contains record(s) from Data Store(s), you can use a Data Store node to represent an internal database data store containing detail records that are associated with the header records in the case store. Adding a Data Store node to a workflow can make it so that whenever the data store loads with new detail records, an analysis that associates those detail records with case header records will execute. The workflow can also then place newly loaded cases into an initial state and/or queue.

Data Store node properties

Associated Data Store

Select a data store of the internal database type that holds detail records for your cases. Whenever this data store loads with new records, the analysis selected in the Analysis to Execute property will run.

Associated Data Store Search Screen

Select a search screen. An internal database data store might have multiple search screens available to choose from.

When creating internal database data stores, you must create a search screen for the data store. Internal database data store search screens allow case workers to search for detail records within an internal database data store once a header record representing a case has been selected.

Analysis to Execute

Select an Analysis to Execute. You can choose to use the System Provided Analysis or you can select a Custom Analysis that you have built for this purpose:

• System Provided Analysis - The default system analysis uses a Join node. In the Data Store Join Field and Case Store Join Field properties, select the fields on which you want to base the join. When the Associated Data Store loads with new detail records, the system-provided analysis that builds the cases will execute.
• Custom Analysis - If you select Custom Analysis, ensure that the selected analysis is one that uses the data store specified in the Associated Data Store property so that it can create new cases and load them into the case store. When the Associated Data Store loads with new detail records, the analysis that builds cases will need to execute. Selecting the appropriate Analysis to Execute automates this execution.

State node

The State node allows you to define the states that a case will transition through as it is processed by case workers. With case stores, the term "state" refers to a case's status, for example, "Open", "In Progress", or "Closed".

You can assign any name to a state, to match the case management requirements of your organization.

Set a default initial state

You can set a default initial state for all cases that enter a workflow, which don't already have a state, by connecting a Data Store node to a State node.

This means that if the Analysis To Execute that is associated with the Data Store runs, and the resulting state field values produced by the run are null, all cases with a state of null will be assigned the default state.

Set a terminal state

A state that has the Terminal State option selected represents the final state a case will go to when case work is done, for example, "Closed".

Allow Assignments - If Allow Assignments is selected, it will be possible for users to reassign cases that are in the selected state to another user, as long as the selected user has the required permission. If you have selected Allow Assignments, you must also add permissions to restrict assignments to a selected set of users.

In the Environment Groups dialog, you can choose one or more environment groups to assign permissions to. Use the Ctrl key to select multiple items.

Prevent Edits - Prevents a user from using edit, inline edit or mass edit on a selected item that is in this state.

Transition

A workflow Transition is the connecting line between two workflow State nodes. When two State nodes are connected, you can click the connector to display the Properties of the Transition.

• Name - Create a name for the Transition of a case from one state to another. This is the option that will appear in a case worker's drop-down menu when transitioning a case to a new state. You can use any name, however, Transition names should match the State they are transitioning to. For example, when transitioning to the "Assigned" state, you could use a transition named "Assign".
• Permission - Define which users can perform the transition. Permissions are set using environment groups. If a user is part of the selected environment group, they will be able to use the Transition to transition the case into a new state.
• Edit Screen - Define the screen that case workers will use when performing the transition. This screen is made available to the case worker to allow them to view or edit fields from the case when it is transitioned. When creating an Edit Screen, you should include all fields that are relevant to the case at the point in the workflow that the Transition represents. At a minimum, the case's status field should be displayed, since the Transition will affect this field.
• Edit Screen Script - Write a script that will execute when the Transition occurs. For example, write a script to configure the transition screen Alert Reason field and Actions drop-down menu to your requirements. A preview mode enables you to edit and test your script and screen. The script in a transition link will trigger when you perform a transition of state.
• Edit Script - Optionally, write a script that will run when a case worker performs a transition. A common way to use such a script would be to send an email to a user or a group of users when the transition takes place, using the sendEmailToUsers or sendEmailToSupergroups functions. The function formatCaseViewURL can be used to include a URL in the email that will route the user to the designated search screen focused on the particular case that is being transitioned.

Queue node

Adding a Queue node to a workflow helps you to define which users will be assigned which cases, based on the criteria of your case management process.

For example, you could place all cases that have reached a specific state into a queue. You could then give a specific group of case workers access to that queue, so that when they use the case management user interface, they see the cases in the queue and know to work on them.

Name

Define how the queue will appear to case workers who have permission to it.

Search Screen

Select a Search Screen for the queue. This is the search screen that case workers will be able to use to search for cases when they are looking at cases within the queue.

Permission

Define which environment groups of users can access the queue. If a case worker is part of an environment group that has permission to a queue, the case worker will see the queue when managing cases.

Transition To State on Take

When case workers view cases within queues, they have the ability to "Take" a case, which will make them the owner of the case.

D efine which state the case will transition to when a case worker performs a Take. Available states are all states that occur after the case's current Sstate, as defined by the workflow.

Queue Connection

When connecting a Queue node to a State node, you also need to define a Queue Connection. Like a Transition, you can click on a Queue Connection to access its properties.

Name

Specify a name for the queue connection in the workflow. This name is not relevant to case workers.

Routing Expression

When creating a Queue Connection, the Routing Expression controls whether a case makes it into a queue.

For example, consider a scenario where you wanted to define two separate queues based on each case's territoryId field value. You could control the flow of cases into these queues using queue connections.

With this setup, each queue connector's Routing Expression would make it so that only cases for "Territory 9" went into the "Territory 9 Queue" and only cases for "Territory 10" went into the "Territory 10 Queue". Access to each queue could then be restricted to the appropriate case workers, via each Queue node's Permission property.

Workflow example

This example illustrates how the components that can comprise a workflow can be combined.

This workflow begins with the Internal Database Data Store node. When this data store loads, it triggers the execution of another analysis that loads new records into the case store.

When the case store loads, any records that have a null value in their status field will be assigned the "Open" status. This assignment occurs because there is a State node named "Open" connected to the Internal Database Data Store node.

Cases that are in the "Open" state can be transitioned to the "Assigned" state via the "Assign" transition, by those case workers that are part of the transition's environment group. During the transition, those case workers will also have the ability to edit the case, using the transition's Edit Screen. Though it is not shown in the illustration, the Transition could also have a script, which sends an email to a group leader whenever a case is assigned.

Once a case is in the "Assigned" state, a number of actions can occur:

• If the case satisfies the expression written in the "Territory 9 Queue Connection", it will go to the "Territory 9 Queue", where it will be accessible to case workers who have permission to that queue (as defined by the queue's environment group property). The same can be said for the "Territory 10 Queue".
• If a case does not belong to "Territory 9" or "Territory 10", it will go to the All Cases repository, permission to which is set in the case store Other tab.

When a case worker accesses an "Assigned" case, they can either close the case, by using the Close transition to set its state to "Closed", or they can decide to review the case. If they decide to review, they can use the Review transition to set the case's state to "Under Review".

After a case has been set to "Under Review", it must then be reopened. Here the case worker will need to use the Reopen transition to set the case's state to "Open" once again.

If a case is reopened, it can either be "Assigned" and "Closed" or it can loop through the workflow indefinitely.