Introduction

A common process step in your case lifecycle is to check for potential duplicates or conflicts of interest. In ShareDo, this is handled by a specialist type of search called process searches. 

These types of searches run as a background process and record their results within a task. They are designed to run in the background so users can continue working through their other tasks. Once the search is complete, the user is notified, and they can view the returned records. Process searches are typically triggered automatically via workflows, although they can be triggered manually if required. 

This article walks you through the configuration of a process search using Duplicate search as an example; this involves the following configuration steps. 

Configuring a search scope for duplicate or conflict checks

Please also refer to the following article, Understanding Search Scopes.

Your starting point in configuring a process search is to navigate to the Search Scopes area of Modeller. 

Here, you will find a list of the searches that are configured in your solution. 

If you filter by Type, you will see some example process searches which you could use as the basis for your configuration.

To create a new process search, click New in the top right corner of the screen, then click Add process search scope.

This opens a blade, allowing you to select from a number of different process search types. Each of the different types supports different search parameters or styles of searches.

For the purposes of this article, we will focus on Duplicate Search v2 (with other searches being supported for legacy purposes).

When configuring this process search, please note the following guidance.

CONFIGURATION	NOTES
Scope Settings	These are largely for information purposes in the case you are calling your duplicate search from a workflow; nevertheless, you should always try to clearly explain your configuration by being as meaningful as possible.
Display	Typically, display settings are disabled for process searches that are called as part of workflows.
Task Configuration	Process searches are managed via work types, so if you are familiar with configuring work types, phase plans and the like, then this configuration section will hopefully feel familiar to a certain extent. Within this section, you can: Choose the Task type that will be used to manage your duplicate search. Note: You will find this Task type within the work type modeller, and it is possible to extend any Task type by creating a derived type of it if your solution requires it. Specify the phases within the task's phase plan for when the search occurs. Executing (or is running). Failed/errored (has not run successfully). Has results (e.g. duplicates exist). No results were found (e.g., no duplicates exist).
Task Assignment	Use this configuration section to specify who the process search task will be assigned to. Note: you can always add to this behaviour by configuring a workflow that assigns roles in a different way.
Chronology	Use this section to configure whether the process search will write to the chronology.
Limits	Depending upon your configuration, there may be a large number of results returned for a process search. For audit purposes, these results are stored against the task itself. The Limits setting is used to limit the number of results stored.
Work Item Scope	This setting defines the work types that will be searched against and whether their category (or sub-type) should match.
Key Date Matching	Describes the key dates that should be used in search results. For duplicates, this may typically involve instruction or incident dates. Additionally, you can specify a tolerance around these dates.
Roles to Compare	You can then configure the roles that will be matched when considering a duplicate. When matching roles are found, the system will use the settings for people, organisations, properties, or vehicles to determine whether there is a match on the role.
Person matching Organisation matching Property matching Vehicles matching	Within these sections, you can specify criteria to match on. The fewer criteria, the more loose the match. You could find loose matches on a surname or postcode, which might return a number of possible duplicates. Or you could be more specific and set more criteria for a tight match that returns fewer duplicates.

With your duplicate or conflict search configured, you are now ready to move on to configuring it within a workflow. 

Calling a process search from a workflow 

When designing your workflow, first configure the triggers that will be used to initiate your search based on your requirements.  

Common examples are: 

PROCESS TRIGGER	NOTES
Calling a process trigger at a certain stage within your case lifecycle.	Usually, process searches such as duplicate checks will be called while an instruction is being initiated. Consequently, you usually use the trigger of Phase Change.
Calling a process search every time a significant event occurs.	Alternatively, you may wish to trigger process searches, such as conflict searches, regardless of the case lifecycle and instead whenever a participant of a specific role is added to a case. In this case, you would typically use the Participant Added or the Participant Role Changed trigger.

With your trigger defined, you are ready to start configuring your workflow.

 Considering the example above, note the following structure:

Next test your workflow. A process search should be created:

Extending your process search implementation 

If you have followed successfully so far, you should now have a workflow that creates a conflict or a duplicate search. You may then wish to extend this implementation in a number of ways, for example:

• Enabling your case handlers to escalate conflict searches to a compliance team quickly.
• Preventing an instruction from being processed if there are outstanding duplicate or conflict searches. 

In designing or implementing processes such as those mentioned above, it is important to note that process searches are just a specialist type of task or work item, and you are free to extend them using standard ShareDo configuration, including the following: 

Process Extension	Configuration Example
Adding a workflow that reassigns a conflict search when it is moved to the Investigation Phase.	If a case handler presses Investigation on the Conflict Search task, then assign this to the compliance team.    To configure the above, you would: Create a new “escalation” workflow Add a trigger for a phase change to “Investigation”.   Within the workflow, perform actions such as: Assign the conflict search to a compliance team. Create an associated task.
Creating a phase guard to stop an instruction from progressing.	To stop an instruction from progressing if an open conflict or duplicate search exists, you would typically configure a phase guard. Either using a Data Quality Rule (see the Data Quality Rules and Guards article) or by configuring a “Child Work Items” completed block.