Salesforce Flow Assignment: Insurance Claim Processing
Business Requirement
An insurance company wants to automate its claim review process using Salesforce Flow.
When a new Claim is submitted, the system should first execute a Fraud Detection Subflow. The subflow returns the following values:
- Fraud Score
- Risk Level
- Recommendation
After receiving the results, determine whether an investigation is required.
An investigation must be created if any of the following conditions are true:
- Fraud Score is greater than 50
- Claim Type = Fire
- Claim Type = Medical Fraud
If an investigation is required:
- Create an Investigation record related to the claim.
- Automatically assign an available Investigator.
- Create a follow-up task for the investigator.
Next, verify that all required claim documents have been uploaded. The required documents are:
- Claim Document
- Photo
- Police Report
- Medical Report
- Invoice
Use a Loop to evaluate each related document.
If any required document is missing:
- Create a task named Upload Missing Documents.
- Assign the task to the claim owner.
If the Claim Amount is greater than $100,000, update the claim priority to Critical.
Update the claim's Approval Status according to the approval stage:
- Pending Manager Approval
- Pending Director Approval
- Pending VP Approval
Create a Scheduled Path that runs 48 hours after the claim enters the approval process.
If the claim is still pending approval after 48 hours:
- Create an Escalation Task.
- Notify the Manager.
Configure email notifications for the following events:
- Customer receives a "Claim Received" email.
- Manager receives an "Approval Required" email.
- Investigator receives an "Investigation Assigned" email.
- Finance receives a "Payment Approved" email.
Implement proper Fault Connectors throughout the flow.
If creating a task fails:
- Create an Error Log record containing:
- Flow Name
- Record ID
- Running User
- Error Message
- Date and Time
- Notify the System Administrator.
Hi Rohit,
This is a solid, well-structured requirement — here's how I'd architect it as a single Record-Triggered Flow on Claim (with supporting elements), broken down by requirement:
1. Trigger & Fraud Detection Subflow
- Record-Triggered Flow on Claim__c, fires on Create (After Save context, since you need the Claim's Id for related records).
- First element: Subflow call to your Fraud Detection Subflow, passing the Claim record/Id as input, and capturing its 3 outputs (Fraud Score, Risk Level, Recommendation) as Flow variables.
2. Investigation Decision Logic
- Decision element with condition:
{!FraudScore} > 50 OR {!ClaimType} = "Fire" OR {!ClaimType} = "Medical Fraud"
- If true:
- Create Records: Investigation__c related to the Claim
- Get Records: query an available Investigator (e.g., filter by Availability__c = true, sorted/limited to 1) — or call a subflow/Apex action if the assignment logic is more complex (round robin, workload balancing, etc.)
- Create Records: Task, Subject = "Investigation Follow-up", OwnerId = the Investigator's Id, WhatId = Claim/Investigation Id
3. Document Completeness Check (Loop)
- Get Records: query related Document__c records for the Claim
- Loop through the 5 required document types, using a Collection (e.g., a text collection variable with the 5 required labels) compared against the actual retrieved document types
- Simplest approach: Assignment to build a list of "found" document types inside the loop, then after the loop use a Decision comparing found list size < 5 (or explicitly checking each required type is present)
- If any missing: Create Records: Task named "Upload Missing Documents", OwnerId = Claim Owner
4. Claim Amount / Priority
- Decision: {!ClaimAmount} > 100000 → Update Records: Claim.Priority__c = "Critical"
5. Approval Status Updates
- This maps well to Salesforce's native Approval Process (Submit for Approval action in Flow) rather than manually managing picklist values — each approval step (Manager → Director → VP) can be an approval step in one Approval Process, and Flow can call "Submit for Approval" as an action. Alternatively, if you're not using native Approvals, use Update Records at each stage transition to set Approval_Status__c accordingly.
6. Scheduled Path for 48-Hour Escalation
- On the same Record-Triggered Flow (or a separate one triggered when Approval Status changes to any "Pending" value), add a Scheduled Path: 48 hours after Claim enters approval process (use a Date/Time field like Approval_Start_Date__c + 48 hours as the trigger time)
- In the scheduled path: Decision checking if Approval_Status__c is still one of the Pending values → if true, Create Records: Escalation Task + Send Email to Manager
7. Email Notifications
- Use Send Email actions (or Email Alerts via Action element) at each relevant point in the flow:
- After Claim creation → Customer "Claim Received"
- When entering approval stage → Manager "Approval Required"
- After Investigator assignment → Investigator "Investigation Assigned"
- After final approval/payment step → Finance "Payment Approved"
8. Fault Connectors + Error Logging
- Add a Fault Path off every Create Records (Task, Investigation, etc.) element
- Each fault path routes to: Create Records: Error_Log__c with fields:
- Flow_Name__c = $Flow.CurrentFlow (or hardcoded name)
- Record_Id__c = the relevant record Id
- Running_User__c = $
User.Id(or full name via a Get Records)
- Error_Message__c = {!$Flow.FaultMessage}
- DateTime__c = {!$Flow.CurrentDateTime}
- Follow the Error_Log__c creation with a Send Email action to the System Administrator
A few build tips:
- Since this flow has multiple distinct triggers (creation, approval status change, scheduled 48hr path), consider whether this should be one Flow with multiple entry criteria/scheduled paths, or split into 2 Flows (Claim Intake + Approval Escalation) for maintainability — with this many branches, splitting is usually cleaner.
- Build and test each section (fraud/investigation, document check, approval, escalation, fault handling) independently before wiring them together — this is a large flow and easier to debug in pieces.
