FAQ

Capabilities & functionality

Q: What does the Job Intake Manager do?

A: The Job Intake Manager is a Digital Worker that turns an inbound job email into a complete IFS Cloud service request. It parses the email and its attachments, resolves the customer, asset, site and service, extracts the SLA commitment, and creates the request carrying the client’s own reference, priority, contact and site access notes. Anything it cannot resolve with confidence is held for a coordinator to review, along with the candidates it considered.

Q: Does a coordinator have to approve every email before a request is created?

A: No. The Job Intake Manager runs autonomously with an exception queue rather than a per-email approval step. When every mandatory value resolves deterministically and nothing is flagged, the request is created and released without any human involvement. Coordinator review is reserved for genuine exceptions.

Q: What happens to an email the worker cannot resolve?

A: No email is silently dropped. Every email reaches a terminal state: created and released, created and held for review, an exception routed to a coordinator, or excluded with a reason, such as when the job detail sits behind an authenticated portal link rather than in the email itself.

Q: Can the Job Intake Manager handle attachments as well as the email body?

A: Yes. It parses the plain-text body, the RTF body, and the text of every attachment, including cases where the entire order is contained in a PDF and the email body carries no useful detail. It also handles attachments that declare an incorrect or generic file type, routing by the actual file extension.

Q: What happens when an email names more than one asset?

A: The worker creates the request for the first asset in the usual way, then adds a further scope to that same request for each additional asset named, reusing the resolved service after revalidating it against the new asset. The result is one request carrying a scope for every asset, not a separate request for each.

Control & Collaboration

Q: Does a coordinator review every request before it reaches a dispatcher?

A: No. Requests where every mandatory value resolves with confidence are created and released automatically. Coordinator involvement is limited to genuine exceptions, blocking issues like no customer match, or non-blocking flags like a candidate ambiguity that needs a quick confirmation.

Q: What is the difference between a blocking exception and a non-blocking flag?

A: A blocking exception, such as no customer match, no service match, or a credit block, stops request creation entirely and escalates to a coordinator, since creating a request on the wrong customer costs more than not creating one. A non-blocking flag, such as multiple asset candidates or an SLA conflict between body and attachment, still results in a created request, but it is flagged for override or held rather than released automatically.

Q: What information does a coordinator see when reviewing an exception?

A: Every exception carries the reason it was flagged, the candidate values the worker considered, the confidence scores for each, and the values that were actually extracted from the email. This means an override is a single, informed decision rather than a re-read of the original email and its attachments.

Q: What happens when a coordinator corrects a match?

A: The correction is applied to the request, and it is also offered as a new entry in that client’s alias or cross-reference table. This means the same email pattern from that client resolves itself automatically the next time it arrives, rather than requiring the same correction repeatedly.

Integration & Technology

Q: What systems does the Job Intake Manager integrate with?

A: The Job Intake Manager integrates with IFS Cloud, where it creates and updates requests, and with Microsoft Teams for exception alerts and the coordinator review digest. It also writes to the Loops data store, which holds the full record of messages, attachments, extractions, candidate sets, decisions, payloads, results and audit trail.

Q: How does the Job Intake Manager receive job emails?

A: Job emails are received through the client’s existing forwarding setup from their CAFM or helpdesk platform. The worker monitors the inbound channel and begins processing automatically as emails arrive.

Q: How does it write to IFS Cloud?

A: The Job Intake Manager is read-mostly against IFS Cloud. It writes in three places only: creating the request, attaching the source email and files, and adding a scope for a second or later asset on a request it already created. It never edits or removes a scope once added, and it never composes an identifier itself, every identifier it uses came from a prior IFS Cloud response.

Q: How are exception alerts delivered?

A: A blocking exception raises an alert to the intake coordinator in Microsoft Teams, including the email, what failed, and the candidates considered. Non-blocking flags and overrides are delivered as a batched digest on a configurable cadence, grouped by client, rather than as an alert per email.

Security & Reliability

Q: How is duplicate request creation prevented?

A: Every request carries a unique external identifier built from a composite fingerprint of client reference, site and asset. IFS Cloud rejects a second request carrying an identifier already in use, and the worker reads that rejection as confirmation the request already exists rather than as a failure requiring a retry. A chased or re-sent order, even with a new message identifier, resolves to the existing request instead of creating a duplicate.

Q: What happens if request creation fails?

A: A failed creation call is queued for a bounded retry and then escalated to a coordinator if it continues to fail. Every retry carries the same external identifier, so a retry after a timeout cannot produce a second request.

Q: Can the Job Intake Manager undo or edit a request after release?

A: No. Release is the one step the worker cannot undo. It never un-releases, cancels, or edits a value it has already written. A released request that turns out to be wrong is corrected by a person in IFS Cloud. Adding a scope is an addition, not an edit, and a scope added in error is removed by a person.

Q: How is audit traceability maintained?

A: Every request records the values extracted, the candidates considered, the scores, and the reason for each match or exception. This gives coordinators and auditors a complete decision trail from the original email through to the created request.

Customization & Performance

Q: Can matching thresholds and SLA mappings be configured per client?

A: Yes. Reference labelling, priority-to-SLA mapping, matching thresholds, the deduplication window, default service organization, alert recipients, and the body-versus-attachment precedence rule are all configuration, not code, and are set per client.

Q: How does the Job Intake Manager handle the different SLA formats each client uses?

A: It handles six SLA encodings: an absolute datetime, an hours-based duration, a “before” deadline, a priority code with the duration embedded in the label, a defect code decoded in a secondary attachment, and cases with no SLA information present. A per-client mapping translates priority and defect codes into a duration and fulfilment event, and an explicit precedence rule applies when the body and an attachment disagree.

Q: What agentic skills does the Job Intake Manager use?

A: The Job Intake Manager is built on four agentic skills: Email & Attachment Parsing, Customer, Asset & Service Resolution, SLA Extraction & Precedence, and Request Creation & Exception Handling. Together they cover the full path from an inbound email through to a created and, where confidence allows, released service request.