Capture Claims Through Guided Intake
Learning Objectives
After completing this unit, you’ll be able to:
- Explain why guided intake is critical to successful claims processing.
- Describe how to initiate a claim in Digital Insurance.
- Identify the core claim records and their relationship to the claim product model.
- Explain how key claim operations power a configurable intake experience.
Ground Intake in the Claim Model
Claims intake turns a reported loss into a structured claim that businesses can validate, route, and handle. It begins at First Notice of Loss (FNOL), and continues as the platform confirms eligibility, captures incident details, documents involved parties and damaged items, and prepares the claim for financial management.
The quality of intake shapes everything that follows. When coverage is verified, key details are captured, and the relevant coverages are opened, adjusters can begin evaluating the claim immediately. When intake is incomplete, they inherit unverified coverage, missing details, and unconfirmed assumptions.
Digital Insurance approaches intake as configurable orchestration. Salesforce admins design guided experiences for each line of business and channel, while the underlying claim operations execute the same product-driven logic and create the same governed records. A self-service portal and an agent console look different, but they produce the same claim structure.
In this unit, you explore how guided intake uses claim operations and the claim product model to turn a reported loss into a structured, coverage-verified claim record.
Learn About Core Claim Records
Intake creates a governed claim structure that carries forward into claim management and financial processing. These are the key records typically created during intake and how they fit into the broader claims model.
Here’s what each highlighted object represents.
-
Claim (1) represents the root loss record. These records originate from the claim product model and link to the policy for eligibility and term validation.
-
Claim Coverage (2) represents a claim’s relationship to a specific policy coverage. All reserves, payments, and limit tracking flow through this record.
-
Claim Participant (3) represents a person or organization connected to the claim with roles that shape downstream handling.
-
Claim Attribute (4) represents the values of structured attributes captured for a specific claim, based on the attributes defined on the claim root product.
-
Claim Item (5) represents a damaged asset or injury involved in the loss structured according to the claim product’s damage or injury specifications.
-
Claim Item Attribute (6) represents the values of structured attributes captured for a specific claim item, based on the damage or injury attributes defined in the claim product model.
-
Claim Item Related Object (7) represents the claim-item relationship to other records with values that can be referenced by claim item attributes during claim handling.
When intake produces this structure reliably, adjusters begin with the context they need to evaluate and manage the claim.
Create and Update Claims
A focused set of claim operations turns the claim product model into run-time records. Digital Insurance exposes these operations through both Connect APIs and invocable actions, so admins and developers can orchestrate guided intake across channels and experiences.
During intake these operations work together in sequence.
-
Verify Claim Coverage confirms that coverage was in force on the loss date for the insured asset or participant.
-
Create Claim reads the claim product model and creates the governed claim hierarchy, including the root claim, initial items, and modeled attributes.
-
Update Claim adds or modifies items and participants as new information emerges, keeping each element in the correct part of the structure.
-
Get Claim retrieves the full structured claim for review.
-
Open Claim Coverage creates the Claim Coverage record and activates it for financial handling.
The claim product model defines the governed claim-record hierarchy. These claim operations create and maintain that hierarchy as intake unfolds.
Assemble the Intake Experience
Claim operations handle validation and record creation, but the intake experience itself is configurable. Administrators design how claim intake unfolds, deciding what information to collect, when to verify coverage, and how the platform builds the claim structure.
In Digital Insurance, these experiences are typically orchestrated using Omnistudio and Salesforce Flow. Guided screens capture loss details, branching logic adapts the process to the situation, and invocable actions call the appropriate claim operations.
This architecture lets different channels support different user experiences while still producing the same governed claim records. A claims intake specialist in Agent Console, a policyholder submitting FNOL through Experience Cloud, or a broker reporting a loss through a partner site can all follow different interfaces while relying on the same underlying claim logic. For external integrations, developers can call the Connect APIs directly.
This architecture separates experience design from claim execution. Salesforce admins tailor the intake journey to the needs of each line of business and channel, while the service layer ensures that every path creates the same policy-aligned claim structure.
Capture a Claim
To explore how this works, consider this example. At Cumulus Insurance, Natalie Wilson is a claims intake specialist. One morning, she receives a call from a policyholder reporting a rear collision to their vehicle. Natalie opens the Create Claim flow from the customer’s auto policy record and begins the guided intake.
Validate Eligibility
Natalie starts the intake flow that Cumulus administrators configured for auto claims.
She launched the flow from the policy record, so the Insurance Policy field is already populated. Using that policy context, the flow displays the available policy assets and policy coverages. Natalie selects the insured vehicle and the Bodily Injury and Property Damage coverage, then enters the date of loss.
When Natalie selects Next, the flow calls the Verify Claim Coverage invocable action. That action confirms that the selected coverage was active on the reported loss date for the specified insured asset.
If coverage isn’t valid, such as if the policy is inactive or the selected coverage doesn’t apply to that asset, the flow branches accordingly. No claim record is created until eligibility is confirmed.
Capture the Incident and Create the Claim
With eligibility confirmed, the flow moves into structured claim creation for auto claims.
Natalie begins by capturing core incident details. The window collects foundational claim information such as claim name, status, and reason for loss. In this case, the caller reports a rear collision.
These fields align directly to the Auto Claim Root product model that Cumulus configured. The selected product code determines which classifications, attributes, and structural components are created when the claim is instantiated.
When Natalie proceeds, the flow calls the Create Claim invocable action. That action reads the claim product configuration and creates the root Claim record using the defined structure and attributes.
Next, the flow prompts Natalie to capture any additional claim attributes configured for the line of business. For auto claims, that can include incident severity, a police report indicator, or other structured fields defined in the claim model.
The flow then moves to participant capture.
Natalie selects the appropriate Claim Participant Role, such as Involved Driver. That role defines how the participant is connected to the claim and how the platform handles that relationship downstream. As the flow continues, Digital Insurance builds out the claim structure according to the Auto Claim Root configuration, including the claim, participant records, role relationships, and other modeled components.
Review and Activate Claims for Handling
Before completing intake, the flow calls the Get Claim invocable action to retrieve the current claim structure and present a summary. Natalie reviews the incident details, participants, and damaged items to confirm that the required information has been captured.
Different claim products present this review step differently depending on how administrators configure the experience. Underneath, the same claim operation retrieves the same structured claim record.
After the details are confirmed, the flow activates coverage for handling. Based on the criteria configured for auto claims, it calls the Open Claim Coverage invocable action to create the Claim Coverage record and link the claim to the applicable policy coverage.
With coverage opened, the claim is ready for financial handling. The coverage record becomes the container for reserves, payments, and limit tracking during the next phase of processing.
You can open coverage directly within the intake flow or trigger it using a workflow rule tied to a stage transition. Either way, the claim leaves intake with verified eligibility, structured loss details, and activated coverage—ready for the adjuster to begin evaluation.
Natalie focused on capturing the loss clearly. The configured orchestration and underlying claim operations ensured the claim is built correctly.
What’s Next
In this unit, you explored how guided intake turns a reported loss into a structured, governed claim. When intake is configured correctly, claims begin as policy-aligned, coverage-verified structures that are ready for financial handling.
In the next unit, you follow that structured claim into financial processing. The activated claim coverage becomes the anchor for reserves, payments, and limit enforcement. Every financial decision aligns with the product and policy terms defined during setup.