> 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/job-intake-manager/core-concepts/real-world-scenarios.md).

# Real-world scenarios

## Overview&#x20;

This article walks through two contrasting scenarios drawn from real client intake emails: a clean job that the Job Intake Manager resolves and releases with no human touch, and a job where the email body and its attachment disagree on the SLA, showing how the worker handles conflicting information without blocking intake or guessing on a deadline.&#x20;

### Scenario: Clean Job, No Human Touch&#x20;

An email arrives from an EAM platform on behalf of an end client, carrying a complete, unambiguous order: the end client name, the store site, the asset tag number, the problem type, a response SLA of 72 hours, a fix SLA of 120 hours, a named requester with an email address, and a generation timestamp.&#x20;

Without the Job Intake Manager, this would still require a person to open the email, look up the customer, asset and service records in IFS Cloud, work out the SLA commitments, and type the request in by hand.&#x20;

#### Step 1: Customer Resolved by Name&#x20;

The Job Intake Manager parses the email and resolves the customer from the end client name carried in the forwarded mail.&#x20;

#### Step 2: Asset Resolved from the Tag&#x20;

The asset resolves from the tag number against the client-reference cross-reference. Because the asset resolves cleanly, the location and address derive directly from it rather than being read from free text in the email.&#x20;

#### Step 3: Service Resolved from the Asset-Scoped Catalog&#x20;

With the asset resolved, the service resolves from the catalog scoped to that specific asset, rather than from a generic service list.&#x20;

#### Step 4: SLA Commitments Extracted&#x20;

Both SLA values, response and fix, are extracted as duration-based commitments. The reported date in the email is used as the start date, so the clock is understood to have started when the client raised the job, not when the worker processed the email.&#x20;

#### Step 5: Confidence Gate Passes&#x20;

Every mandatory value has resolved deterministically and nothing has been flagged. The confidence gate passes.&#x20;

#### Step 6: Request Created and Released&#x20;

The request is created and released in a single call, carrying the client reference, priority, contact and description. A dispatcher sees the job in IFS Cloud without anyone having opened the email.&#x20;

Result: Zero human decisions were required. A job that would normally take a person several minutes to read, look up and key in is created and released automatically, with every field the dispatcher needs already in place.&#x20;

### Scenario: Body and Attachment Disagree on the SLA&#x20;

The same email pattern, but this time the attached order states the attendance commitment is “within 4 hours,” the stamped expected-attendance timestamp on the order is actually eight hours after the request date, and the forwarding note in the email body claims the priority code means a 24-hour response. Three sources, three different answers.&#x20;

#### Step 1: All Three SLA Signals Extracted&#x20;

The Job Intake Manager extracts all three candidate SLA values rather than picking the first one it finds: the attachment’s stated commitment, the attachment’s stamped datetime, and the body’s priority-code claim.&#x20;

#### Step 2: Configured Precedence Rule Applied&#x20;

Per the client’s configured precedence rule, the attachment’s absolute attendance datetime takes priority over the body’s forwarding note. The worker resolves the SLA to that value rather than escalating the conflict itself.&#x20;

#### Step 3: Confidence Gate Fails&#x20;

Because a genuine conflict was detected between the body and the attachment, the flag fails the confidence gate. Automatic release does not proceed.&#x20;

#### Step 4: Request Created, Held at New&#x20;

The request is still created, carrying every other resolved value, but it sits at New rather than being released automatically.&#x20;

#### Step 5: Coordinator Confirms and Releases&#x20;

A coordinator reviews the flagged conflict, with the candidates and the extracted values already surfaced, confirms the deadline, and releases the request.&#x20;

**Result:** The conflict is resolved without blocking intake and without the worker guessing on a four-hour commitment. The request exists and is visible well before a person would have finished reading the email by hand, and the one genuinely ambiguous decision, which deadline actually applies, is the only part that reaches a person.&#x20;

## What These Scenarios Illustrate&#x20;

Clean jobs require zero decisions. When every value resolves deterministically, the request is created and released in one call. The dispatcher’s first contact with the job is the completed request, not the raw email.&#x20;

Conflicts are surfaced, not silently resolved or blocked. A precedence rule settles the SLA value used for the request itself, but a genuine disagreement between sources still fails the confidence gate and holds the request for a human decision, rather than releasing on an assumption.&#x20;

Creating is not the same as releasing. A request can exist at New, fully populated and visible to a coordinator, without being released to a dispatcher. This separates “we have enough to create a record” from “we are confident enough to act on it automatically.”&#x20;

Every escalation carries full context. When a request is held, the coordinator sees the reason, the candidate values, and the scores behind them, so confirming the deadline is a single decision rather than a re-read of the original email and its attachment.&#x20;

The same workflow handles both outcomes. Parse, Resolve, Create, Attach applies whether the result is full automatic release or a held request awaiting review. There is no separate manual path.&#x20;