Use Case:

In this example we will create two real time Flows in Salesforce to cover the following business logic.

  1. Create a Screening Case when a custom field is set to TRUE on the Account record.  In this example we are assuming that screening is going to happen at a later point in the process and not upon the creation of an account record.
  2. Write the Screening Case Salesforce ID back onto the Account record so that we can use it later in the process to keep the screening case updated.  In this example we are going to have a 1:2:1 data model between a record and it's linked screening case, however customer Risk Screener does support a 1:many data model. 
  3. Find and update the Screening Case and send it for re-screening when the Account name, Account Document ID or Account Country is changed. 

It is possible to build out these flows to add more complex logic to:

  1. Automatically set Ongoing Screening to True when the account status changes to be an "Active Client"
  2. Automatically archive the Screening Case when the account status changes to be an "Inactive Client"
  3. Screen records against different World-Check Groups e.g. Accounts with Location of X or Y will be screened against "High Risk" Group and all other Accounts will be screened against "Low Risk" Group.  This allows you flexibility to screen records against different Key Word lists or that have different match thresholds within World-Check.  Access further information on using existing groups or configuring Groups in World-Check One. 

See the Quick Start Guide "Automate your processes" for guidance on how to do this.

Flow 1: Create and update a screening case record for an Account

Preconditions:

This flow is going to utilise three custom fields on the Account object to represent data in Salesforce.  These fields are NOT included in the package create your own fields in a sandbox as necessary.

Field Field Type Description
Initiate Screening Check box Will be used in the entry criteria as a trigger for creating the case, this can be set manually by users or via some other workflow/flow e.g. when an opportunity meets a certain criteria.  A custom field is not necessary for triggering a screening case and you should consider what entry criteria makes sense for your organisation.
Custom ID field Text field Represents a reference ID e.g. Tax Code, Company ID, DUNS number etc that can be passed to World-Check and used by the matching engine,  you may already have a field that represents one or many document Ids.  A full list of supported Id types is available on MyRefintiv.
Primary Screening Case Lookup Relationship to the Screening Case object Will be populated by Flow 2 when the screening case is created.  We can then use this field to easily identify which screening case we wish to update and rescreen should a field on the Account record change.

Steps:

  • Navigate to flow builder.  Setup > Process Automation > Flows > New Flow
  • Select “Record-Triggered Flow” > “Create”
  • In the pop-up box enter:
Object Account
Trigger the Flow When: a record is created or updated
Condition Requirements: Custom Condition Logic is Met (see screenshot)
When to run the Flow for Updated Records: Every time a record is updated and meets the condition requirements
Optimize the Flow for: Actions and Related records

We want the entry criteria to trigger in two scenarios:

  1. The custom field Initiate Screening has been changed to be TRUE.  In this scenario we want to create the screening case.
  2. Where a screening case already exists (which will be defined where the Primary Screening Case is NOT null) if the Account Name, Billing Country or Custom ID fields are changed , we want to update the screening case AND send it to World-Check to rescreen it.   

We are going to use Custom Condition Logic to define the two different entry criteria.

Consider if any additional paremters need to be added to your entry criteria.  E.g. you may have standard suppression/exculsion criteria for not firing Flows in certain scenarios e.g. if large volume data jobs are run by system users.

Your Flow now looks like this:

Save it and give it a useful description.  The next step is to add branches to the flow.  

Click the + icon to add an element and add a "Decision".  Give the Decision a name

We will create two branches or "outcomes":

1. Create Screening Case: handles the initial creation of the screening case when the Initiate Screening flag is set to true

 

    2. Update Screening Case: handles any updates from the source record e.g. if the Account Name, Billing Country or Document ID changes. 

Remember that you will need to specify custom condition logic as you only want to trigger this branch when a screening case exists AND either the Account Name, Billing Country OR Document ID field are updated.  You also want to be very specific about what is changing on the record and only include updates to fields that you are syncing to World-Check.  The Operators IsChanged or PriorValue are ways to achieve this.  E.g. you don't want to be triggering API call outs if fields that are not relevant to the screening process are updated.

TIP! If you are using a scheduled time triggered Flow rather than realtime, you will need to split the update action out into it's own seperate Flow.

Click "Done" you now have two branches or "outcomes".  The next step is to add "Actions" to the branches.  

In the branch "Create Screening Case" on the + and select the element type of "Action".   In the search box type "Automate Screening" and select the action apex-tr_wc1_tr_automateScreening. Click "Done"

Give your Action a name and description and scroll down to the variables.  You are going to set 3.

  1. enableMonitoring - this can be true or false.  It defines whether a case is flagged for Ongoing Monitoring (OGS) at the point of creation or not.  Find out more about OGS here.
  2. objectType - this should be the name of the object you are screening e.g. Account, Contact, Lead - if screening from a custom object then enter "Custom Case". It will call the mapping for that object.
  3. recordId - passs the Record.Id of the origniating record being screened

The rest of the parameters can be left blank at this stage. Click Done.

You are going to repeat this for the "update screening case" path but you are going to add three extra parameters.  To do this you need to have a relationship between the Screening Case and the source record, we are going to leverage the field we created in the preconditions called "Primary Screening Case".  Entering these parameters is going to tell the systems which Screening Case to update in Salesforce and in World-Check.  If you have a many to one relationship model then you will need to use an alternative approach for identifying which screening case to update but you will still need to pass the 3 parameters.

Parameter Corresponding Field API Name Field Label
screeningCaseId Record.Primary_Screening_Case__c Primary Screening Case
worldCheckOneCaseId Record.Primary_Screening_Case__r.tr_wc1_Case_Id__c
 Case Id
worldCheckOneCaseSystemId Record.Primary_Screening_Case__r.tr_wc1__Thomson_Reuters_Case_Id__c Case System Id

 

Your flow now looks like this and is ready to save and test:

Using the inbuilt debug features is a handy way to quickly test that records are flowing through the expected paths, but we would always recommend activating the flow and performing your own tests.  We would also recommend you consider exception handling as part of your flow design. 

Flow 2: Set Primary Screening Case

The Flow 1 path "update screening case" is relying on a relationship existing between the record that is to be screened and the screening case object.  However we haven't yet written any data back into that field.  Flow 2 handles this by writing back the Salesforce ID of the Screening Case to the field on the source record.  Note depending on how many objects you screen you may endup with many branches (Outcomes) within this Flow.

Navigate to Flows and click "New Flow" 

Select "Record-Triggered Flow" > "Create"

Object: Screening Case
Trigger the Flow when: A Record is Created
Set Entry Conditions: None
Optimize the Flow for: Actions and Related Records
Include a Run Asynchronously path... False

Scroll down a select 'Decision'.  A new pop-up window opens, give the decision a Name and description.  In this example we are going to focus on creating one new path (outcome) for the Account object where the field Record.Account__c is not blank.  Remember we pass the ID of the standard object to the created case as part of Flow 1 so we can use it to identify the source object.  

Be aware that depending on the number of objects you screen you may end up with multiple paths, one for each object.  

We are now going to add an "Update Records" element, click the + button under the new branch you have just created and select "Update Records".   We want to check if the Primary Screening Case field on the associated Account is null AND if the ID of the Account record matches the ID of the Account held on the Screening record.  If null then pass the Record ID of the created record to the Primary Screening Case field. 

Within the Update Records Element select:

  1. Specify conditions to identify records and set fields individually
  2. Object = Account
  3. Filter records = (per screenshot)
  4. Set Field Values for the Records = (per screenshot)

 

Save the Flow, test and activate it and test again!

Your Flow will look something like this.  Note this flow is handling many different object types, yours will only need to have branches for the objects you are screening.

You are ready to start testing your Flows end to end.  What we expect to happen.

  1. A screening case will be created when the custom field "Initiate Screening" is set to True on the account object
  2. When the screening case is created the Id of the record will be written back to the account object and saved in a custom field called "Primary Screening Case"
  3. If you update the Name, Billing Country or Document ID of the Account when there is a value in the field Primary Screening Case then the corresponding Screening Case record will be updated in Salesforce AND sent for re-screening in World-Check One.  
    • Tip! A good way to test if the update has gone to World-Check is to check the Audit Events related list on the Screening Case Object.  You should see new audit events "Case Update" and "Case Screened for World-Check" appear with a corresponding time and date stamp.  Note it can sometimes take a few minutes for the audit logs to appear and you will need to refresh your screen.