> For the complete documentation index, see [llms.txt](https://kb.theloops.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kb.theloops.io/digitalworkers/ifs-loops-digital-workers/digital-worker-guides/warranty-claims-manager/core-concepts/real-world-scenarios.md).

# Real-world scenarios

## Overview&#x20;

This article walks through two scenarios: a bulk batch of claims arriving as a single email attachment, and the cross-channel duplicate detection that catches a claim resubmitted through a second source.&#x20;

### Scenario: Five Claims, One PDF, Two Incidents&#x20;

Five claims arrive via a single PDF attached to an email in a managed Microsoft Outlook inbox.&#x20;

#### Step 1: Each Claim Resolved Against the Record&#x20;

For each claim, the Warranty Claims Manager resolves the part, reads the acquired date, and checks the claim date against the warranty window.&#x20;

#### Step 2: Duplicate Check Before Any Incident Is Raised&#x20;

It then searches for an existing claim on the same part, and only then decides whether to raise the incident.&#x20;

#### Step 3: A Detailed Breakdown Is Provided&#x20;

Every row is accounted for, with what happened to it and why. Two incidents are raised. Three claims are turned away, each with the rule it failed.&#x20;

#### Step 4: A Rejection Your Team Can Act On&#x20;

That’s a rejection your team can act on, or overturn, without going back to the beginning. The same IFS Assyst screen shown at intake now carries the new incidents, complete with all relevant details.&#x20;

**Result:** No splitting the batch by hand, and no chasing entitlement checks one part at a time. Two legitimate claims become incidents; three ineligible claims are stopped before they become records that would otherwise need investigating and withdrawing later, each with a named, actionable reason.&#x20;

### Scenario: The Same Claim, Two Channels&#x20;

A claim for a failed unit is submitted through the monitored mailbox. Before it can be processed again, the same claim, for the same failure, is submitted a second time through the client portal, a common pattern when a submitter isn’t sure the first attempt went through.&#x20;

#### Step 1: The First Submission Processes Normally&#x20;

The mailbox submission is decomposed, its fields extracted, and entitlement validated against the system of record. No existing claim is found on the same part, so the claim proceeds.&#x20;

#### Step 2: The Second Submission Arrives Through a Different Channel&#x20;

The portal submission arrives later, carrying the same part reference and failure details.&#x20;

#### Step 3: The Duplicate Is Matched, Not Missed&#x20;

The Warranty Claims Manager matches the new submission against open and recently settled claims, regardless of which channel each one arrived through, and identifies it as a duplicate of the claim already created.&#x20;

#### Step 4: The Second Submission Is Suppressed&#x20;

The duplicate is suppressed on its second arrival, with the related existing claim reference provided for traceability, rather than becoming a second incident.&#x20;

**Result:** A pattern that manual review, relying on memory alone, routinely misses is caught automatically, regardless of which channel a resubmission comes through. The same failure is represented by exactly one incident, not two.&#x20;

### What These Scenarios Illustrate&#x20;

Duplicate checking happens before, not after, incident creation. In both scenarios, the search for an existing claim on the same part happens before the worker decides whether to raise an incident, not as cleanup afterward.&#x20;

Every outcome is explained, not just flagged. A rejected claim carries the specific rule it failed. A suppressed duplicate carries the reference to the claim it matches. Nothing is turned away or suppressed without a stated reason.&#x20;

Rejections are actionable, not final dead ends. A team can act on a stated rejection reason, or overturn it, without starting the review from scratch.&#x20;

Duplicate detection isn’t limited to one channel. A claim resubmitted through a different source than the original, mailbox versus portal, is still caught, because matching runs against open and recently settled claims regardless of where each one arrived.&#x20;

Bulk volume doesn’t dilute individual accuracy. Five claims arriving in one document each get the same resolve-check-duplicate sequence as a single claim submitted alone; volume changes the batch size, not the rigor applied to each line.&#x20;