Skip to main content
Join Trailblazers for Dreamforce 2024 in San Francisco or on Salesforce+ from September 17-19. Register now

Evaluate Claim Rules

Learning Objectives

After completing this unit, you’ll be able to:

  • Configure an Integration Procedure to call the appropriate rule creation service for claims.
  • Test claim rules by preparing the user inputs.

Prepare to Evaluate

Justus has successfully set up actions and rules to automatically open coverages. But to make the process truly seamless, he wants product rules to evaluate whenever a claim is created or updated. Normally, an OmniScript handles this during the first notice of loss (FNOL), capturing claim details and triggering the invokeProductRules service. This service assesses all relevant claim product rules and triggers actions.

For testing, Justus uses an Integration Procedure to input claim data directly and observe the rule evaluation in isolation.

In this unit, learn how to configure an Integration Procedure to streamline the evaluation of claim rules.

Set Up the Service

Justus wants the rule evaluation to take place immediately after a claim is created or updated, so he makes a new version of the Integration Procedure used to create the claim.

The process for invoking claim product rules involves using a single service: insClaimService:invokeProductRules. You can call this service from an Integration Procedure or OmniScript using a Remote Action element.

Add the Remote Action below the Create Claim component. In the example screen, the action is called EvaluateRules.

Structure of Integration Procedure with Evaluate Rules following Create Claim action.

Next, choose the appropriate Class (insClaimService) and Method (invokeProductRules) for the service.

EvaluateRules remote action that calls the invokeProductRules service.

Make sure to specify the remote options for the service call. Unlike the createUpdateClaim service, this service has no inputKey option. Instead, use the objectId key to reference the claimId.

The claimId is returned as an output in the previous remote action component, so reference its path as the value for the objectId.

Path of claimId from previous remote action is referenced as objectId for the service.

Set the includeStateTransition option to true. When the rule evaluates to true, the claim transitions to the state specified in the rule.

Finally, set the transitionName option to Draft > Open. This way, the rules run only if associated with this specific transition. The two rules set for Dwelling and Personal Property both reference this transition.

Test the Service

After configuring the options for the invokeProductRules service, it’s time to test it.

Retrieve the original input JSON used to create the claim, and paste it into the Input Parameters of the Integration Procedure.

Input Parameters for the claim creation.

Find the two attributes used in the rule expressions, claimStructureDamaged and claimContentsDamaged. Both currently have an “Unanswered” value, which doesn’t meet the rule conditions.

In this example, each value is changed to “true.”

claimContentsDamaged field is changed from unanswered to true.

Now, both rules evaluate to true, and both coverages automatically open on the claim.

Run the procedure, and view the output data in the Debug Log. You can select the EvaluateRules component to take a closer look.

Debug log with the EvaluateRules action highlighted.

This element displays the output data for the invokeProductRules service. If the service runs as expected, it returns a series of true rules.

For a more organized tree view, paste the data into a JSON viewer.

Data from EvaluateRules debug log is cleaned up in JSON viewer.

Notice that the stateTransit updated the claim record from Draft to Open, which is expected when a rule evaluates to true. Also, the allFalse key equals false, which means that at least one rule is true. Next, examine the true rules.

Expand the trueRules object to confirm the Claim Damaged Property spec returned two true rules. This makes sense because both rule conditions were specific to the Claim Damaged Property.

True rules for Claims Damaged Property include two nodes.

Expand the falseRules object to confirm that the Injury spec returned two false rules. This also makes sense—neither of the rules contained conditions related to the claim injury spec, so no coverage should open on this spec.

False rules on the claim injury spec.

The first true rule from the Claim Damaged Property displays a series of rule details.

Rule details for first true rule.

The Open Dwelling Coverage rule evaluates as true and calls the Open Building Coverage Integration Procedure.

The second true rule has a similar structure.

Rule details for second true rule.

This time, the Personal Property coverage rule evaluates as true and calls the appropriate Integration Procedure.

Finally, navigate to the newly created claim record, and confirm that the coverages successfully opened on the claim.

Two claim coverages with different loss reserves open on Ernie Newton’s claim.

On the Financials tab, Justus confirms that Ernie Newton, the claimant, has dwelling and personal property coverage opened on his damaged property. Their loss reserves match the values set in the remote options of each Integration Procedure.

And with that, you have learned the ins and outs of managing and automating claims using the Digital Insurance Platform. With these basic tools and principles, you can build out automated and intelligent processes for simplifying and optimizing the entire claims management journey.

Want to Learn More?

If you’re a Salesforce customer, check out these learning journeys to discover how to skill up on our suite of digital transformation tools and industry applications.

Resources