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

# Real-world scenarios

## Overview&#x20;

This article walks through two scenarios drawn from real service closure work: a request scope that passes validation cleanly and moves straight to an approved invoice, and a scope that fails validation, gets corrected, and is validated again.&#x20;

### Scenario: Clean Scope, Straight to Approval&#x20;

A request has one or more scopes, and each scope has the tasks the technicians actually worked on. The Service Closure Manager works at scope level, because that is the level invoicing happens at.&#x20;

#### Step 1: Task Context Retrieved&#x20;

For each task under the scope, the Service Closure Manager retrieves what the technician left behind: performed work, remarks, action taken, and cause details, reading all four together as one account of the job rather than four separate fields.&#x20;

#### Step 2: System Records Reconciled&#x20;

Underneath that, the worker reconciles the system records: what was planned, what was actually used and costed, and what came back as a return.&#x20;

#### Step 3: Sales Lines and Hours Checked&#x20;

Sales lines and hours are checked next, with planned duration checked against what was reported and what was charged as labor. Everything falls inside the configured tolerance.&#x20;

#### Step 4: Every Task Passes&#x20;

Every task under the scope passes its material, return, and time reporting checks.&#x20;

#### Step 5: Invoice Preview Created&#x20;

With every task in the scope validated, an invoice preview is created and sent for review.&#x20;

#### Step 6: Person Approves&#x20;

A person approves the invoice preview, and it proceeds.&#x20;

Result: A request scope moves from completed work to an approved invoice with a single human decision, the approval itself, because every task under it already reconciled cleanly.&#x20;

### Scenario: Scope Held for Correction&#x20;

The same process, but this time a check does not clear.&#x20;

#### Step 1: Scope Completed, Validation Runs&#x20;

A scope is completed. The Service Closure Manager validates every task under it: materials, returns, sales lines, and hours, reconciling the technician’s account of the job against the system records.&#x20;

#### Step 2: A Check Fails&#x20;

One of the checks does not clear. Something is outside the configured tolerance.&#x20;

#### Step 3: Result Delivered in Plain Language&#x20;

The result comes back, listing every check in plain language along with the reason. This scope is not ready. The message shows exactly which task, which check, and why.&#x20;

#### Step 4: No Invoice Preview Created&#x20;

No invoice preview is created, and that is deliberate. Nothing progresses toward invoicing on a scope that has not reconciled.&#x20;

#### Step 5: Record Corrected in IFS&#x20;

Someone corrects the data in IFS, exactly where they would normally.&#x20;

#### Step 6: Scope Validated Again&#x20;

The scope goes round again. Same data in, same result out, because the checks are deterministic. Every scope gets the same checks, and nothing is invoiced until it reconciles.&#x20;

**Result:** The person responsible for the record is told what and why in plain language, corrects it in the normal place, and the scope is re-evaluated automatically. The approval, once the scope does reconcile, stays with a person on the record.&#x20;

## What These Scenarios Illustrate&#x20;

The scope, not the task, is the invoicing boundary. The Service Closure Manager works at scope level because that is the level invoicing happens at, checking every task under a scope before anything can move forward.&#x20;

A technician’s account of the job is read as a whole. Performed work, remarks, action taken, and cause details are read together as one account of the job, not as four boxes to be filled in independently.&#x20;

Nothing is invoiced until it reconciles. A scope that does not pass every check produces no invoice preview at all, deliberately, rather than a partial or flagged one.&#x20;

Failures are plain language, not internal codes. When a scope is not ready, the person responsible sees exactly which task, which check, and why, so the correction is a single, informed action rather than a search.&#x20;

The same checks run every time, deterministically. A corrected record goes through the identical validation the original record did. Same data in, same result out.&#x20;

Approval always stays with a person. Whether a scope clears immediately or needs a round of correction first, the invoice preview only proceeds once a person has explicitly approved it.&#x20;