> 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/fundamentals.md).

# Fundamentals

## Overview&#x20;

The Job Intake Manager is an AI-powered Digital Worker that turns an inbound job email into a complete IFS Cloud service request. It resolves the client, the asset, the site and the service from the email and its attachments, creates the request carrying the client’s own reference, priority, contact and site access notes, adds a further scope for every additional asset the email named, and attaches the source email and its files to the request. Anything it cannot resolve with confidence goes to a person, along with the candidates it considered. No email is silently dropped.&#x20;

The Job Intake Manager runs autonomously with an exception queue. There is no per-email approval step: supported patterns are created and released without a human touching them, and only genuine uncertainty is routed to a coordinator.&#x20;

## Key Benefits&#x20;

**No human touch on clean jobs:** When every mandatory value resolves deterministically and nothing is flagged, the request is created and released in a single call. A dispatcher sees the job without anyone having opened the email.&#x20;

**Faster response on time-sensitive work:** Requests are created within minutes of the email arriving, protecting attendance and response SLAs that start counting the moment the client raised the job.&#x20;

**No lost detail:** The client’s own reference, the priority, the reporter’s contact details and site access constraints, hazard notes, and authorization requirements are captured on every request whose source carried them, rather than being the fields a person under time pressure skips.&#x20;

**Duplicates and keying errors eliminated:** A composite fingerprint of client reference, site and asset, carried into IFS as the request’s external identifier, means a re-sent or chased order resolves to the existing request rather than creating a second one.&#x20;

**Full decision traceability:** Every request records the values extracted, the candidates considered, the scores, and the reason for each match, so an override is a single decision rather than a re-read of the original email.&#x20;

## The Challenge It Solves&#x20;

Service providers receive new jobs by email, forwarded from the CAFM or helpdesk platform of each client. Different clients use different platforms with different email layouts, so there is no single format to parse. Today, a person reads each one, works out which client, site, asset and service it concerns and what the deadline is, then types a request into IFS Cloud by hand.&#x20;

Three costs follow from this. Duplicates and keying errors, because the same order sometimes arrives more than once and nothing links the request back to the client’s own reference. Delay, on jobs that carry a tight attendance commitment, since the SLA clock is already running by the time a person gets to the email. And loss of detail: the client’s order number, the priority, the reporter’s phone number and the site access constraints are the fields most often dropped in manual entry, and they are the ones the field engineer needs on arrival.&#x20;

## Before and After&#x20;

### Before&#x20;

Before the Job Intake Manager, turning a job email into a service request requires manual effort at every stage:&#x20;

{% stepper %}
{% step %}
Read the forwarded email and any attachments to identify the client, site, and asset
{% endstep %}

{% step %}
Work out the problem type and the service required
{% endstep %}

{% step %}
Determine the priority and the response or completion deadline
{% endstep %}

{% step %}
Look up the customer, asset and service records in IFS Cloud
{% endstep %}

{% step %}
Type the request into IFS Cloud by hand, including reference numbers, contact details and access notes&#x20;
{% endstep %}

{% step %}
Attach the original email and any files, if there’s time to do so&#x20;
{% endstep %}
{% endstepper %}

This process is slow, inconsistent across the different email formats each client uses, and prone to dropped detail under time pressure.&#x20;

### After&#x20;

With the Job Intake Manager, the same process runs automatically:&#x20;

{% stepper %}
{% step %}
Detect and deduplicate the email, matching it against a composite fingerprint of client reference, site and asset&#x20;
{% endstep %}

{% step %}
Parse the headers, body and every attachment, identifying the originating platform and the end client&#x20;
{% endstep %}

{% step %}
Resolve the customer, asset, location, service and service organization from what was extracted&#x20;
{% endstep %}

{% step %}
Extract and resolve the SLA commitment, applying the configured precedence rule if body and attachment disagree&#x20;
{% endstep %}

{% step %}
Create the request, releasing it automatically when every mandatory value resolved with confidence, or holding it for review when it did not&#x20;
{% endstep %}

{% step %}
Attach the source email and every file, and add a further scope for each additional asset the email named&#x20;
{% endstep %}
{% endstepper %}

## How It Works&#x20;

The Job Intake Manager follows a single core workflow: Parse, Resolve, Create, Attach.&#x20;

**Parse:** Every inbound email is deduplicated on a composite fingerprint before anything else happens, because a chased or re-sent order arrives with a new message identifier. The worker then parses the headers, the plain-text and RTF body, and the text of every attachment, walking quoted headers where needed to identify the originating platform and the end client.&#x20;

**Resolve:** The customer is resolved from the end client named inside the forwarded mail, not the sender and not the CAFM platform. The asset is resolved from the client-reference cross-reference, narrowed by location and model as they become known. Location and address are always derived from the resolved asset, never string-matched from free text. The service is resolved from the asset-scoped catalog, and the service organization is resolved from the applicable selection rule.&#x20;

**Create:** The request is built and posted, with automatic release set only when the confidence gate passes, every mandatory value resolved deterministically and nothing flagged. The returned request identifier is stored, the source email and every attachment are attached to the request, and a further scope is added for every additional asset the email named.&#x20;

**Attach and notify:** Every email reaches a terminal state, created and released, created and held, or exception with a reason and the candidate set. Nothing is silently skipped.&#x20;

If the asset does not resolve, the worker resolves the location directly and creates the request without an asset reference, flagged for a coordinator to check, since the request then carries no warranty or contract context. If the address cannot be resolved because the asset does not resolve and the email carries more than one candidate address, the request is created with the location left empty, the candidate addresses written into the notes, and held for review. An empty location a coordinator fills in is preferable to a wrong postcode an engineer drives to.&#x20;

## What Triggers the Job Intake Manager&#x20;

The Job Intake Manager responds to inbound job emails forwarded from client CAFM and helpdesk platforms, and handles the variation across them:&#x20;

**Multiple SLA encodings:** absolute datetimes, hour-based durations, “before” deadlines, priority codes with the duration embedded in the label, defect codes decoded in a secondary attachment, or no SLA information at all.&#x20;

**Conflicting information:** the email body and an attachment disagreeing on the SLA, or the email carrying more than one candidate reference number or site address.&#x20;

**Attachment variation:** orders delivered as PDFs with an empty body, attachments with an incorrect or generic file extension, and orders split across the body and multiple attachments.&#x20;

**Access and hazard information:** asbestos survey references, leasehold restrictions on authorizing works, and site access instructions that must reach the request even though they are not needed to create it.&#x20;

**Portal-gated content:** emails that reference an authenticated portal link rather than carrying the job detail directly. These are excluded, not silently skipped, and go to the review queue with the link attached.&#x20;

**Duplicate orders:** the same order re-sent with a new message identifier, which resolves to the existing request rather than creating a second one.&#x20;

**Multi-asset orders:** a single email naming more than one asset at the same site, which results in one request carrying a scope for each asset.&#x20;