> This is part 1 of 3 of the full documentation (pages 1–100 of 259). > The content is paginated: fetch every part to see all of it. > Next part: https://kb.theloops.io/llms-full.txt/1 > Page index: https://kb.theloops.io/llms.txt # Home Welcome to your team’s developer platform

Welcome to the IFS Loops Knowledge Base. Select your IFS Loops product to learn more.

			Cover image
Agent Studio	A no-code platform for building, deploying, and managing AI agents that automate complex business workflows.	IFS Loops Agent Studio	ChatGPT Image Apr 21, 2026, 10_54_23 AM.png
Digital Workers	A suite of AI-powered digital workers that automate high-volume operational processes across supply chain, procurement, and inventory management.	IFS Loops Digital Workers	ChatGPT Image Apr 21, 2026, 10_56_41 AM.png
CX Platform	AI-powered tools that automate and enhance customer interactions, agent support, and contact center performance management.	IFS LoopsCX Platform	ChatGPT Image Apr 21, 2026, 10_52_29 AM.png

# IFS Loops Digital Workers Welcome to your team’s developer platform

IFS Loops Digital Worker Knowledge Base

Welcome! Explore our guides and resources to get the most out of IFS Loops Digital Workers, purpose-built AI that autonomously executes complex processes across your enterprise systems so your team can focus on the work that matters most.

			Cover image
Digital Worker guides	Guides and resources for every Digital Worker in your toolkit.	Digital Worker guides	DW guides.png
How-to guides	Practical, step-by-step guidance across a range of tasks.	How-to guides	how-to-guides.png
Integrations	Connect seamlessly with 65+ enterprise tools across CRM, ticketing, and more.	Integrations	integrations (2).png
Release notes	Stay up to date with the latest product updates and feature enhancements.	Digital Workers: release notes	release notes (2).png

# Digital Worker guides Each Digital Worker is purpose-built for a specific role in your operations. Select one below to explore what it does and how it works.

			Cover image
Customer Order Manager	End-to-end customer order automation	Customer Order Manager	ChatGPT Image Apr 20, 2026, 04_42_20 PM.png
Closeout and Improvement Manager	Automated maintenance work order validation and closeout	Closeout and Improvement Manager	make this image lavander, a little smaller and bac (2).png
Dispatcher Assistant	Manage real-time service disruptions	Dispatcher Assistant	ChatGPT Image Apr 20, 2026, 04_48_34 PM.png
Job Intake Manager	Automated job email intake and service request creation	Job Intake Manager	JIM OB.png
Job Rate Manager	Automated labor rate classification and rule-based cost decisions	Job Rate Manager	make this image a little smaller and the backgroun.png
Inventory Replenisher	Real-time demand forecasting & restocking	Inventory Replenisher	ChatGPT Image Apr 20, 2026, 04_39_13 PM.png
Knowledge Manager	Deliver real-time, contextual knowledge to service teams across any channel	Broken link	ChatGPT Image Apr 20, 2026, 04_44_10 PM.png
Material Replenisher	Automated parts sourcing & allocation	Material Replenisher	DW MR.png
Reconciliation Manager	Intelligent account matching and period-close automation	Reconciliation Manager	make this image lavander, a little smaller and bac.png
Supplier Invoicing Manager	Automated invoice intake, validation, and exception handling	Supplier Invoicing Manager	DW SIM.png
Supplier Order Manager	Efficiently manage supplier order confirmations and communication	Supplier Order Manager	ChatGPT Image Apr 20, 2026, 04_41_20 PM.png
Service Closure Manager	Automated service work validation and invoice readiness	Service Closure Manager	Service closure ob.png
Sourcing Manager	Automated PR-to-RFQ sourcing and supplier recommendations	Sourcing Manager	sourcing manager ob.png
Time Entry Manager	Automated project time entry and submission	Time Entry Manager	make this image a little smaller and the backgroun (1).png
Warranty Claims Manager	Automated warranty claim intake and validation	Warranty Claims Manager	make this image lavander, a little smaller and bac (1).png

# Customer Order Manager Handling customer orders takes focus, but repetitive intake work shouldn’t slow teams down. This knowledge base guides you through using the Customer Order Manager, from initial setup to handling customer orders efficiently in daily operations. ### Jump right in

		Cover image
Watch & learn	See this Digital Worker in action.	create an image for watch and learn.png	Watch & learn
Core concepts	Essential context for understanding how it all works.	create an image for core concepts_.png	Core concepts
FAQ	Quick answers to common questions.	create an image for frequently asked questions_.png	FAQ
How-to guides	Practical, step-by-step guidance across a range of tasks	create a tile image representing digital worker gu (2).png	How-to guides

# Watch & learn Watch the video below to see this Digital Worker in action {% embed url="" %} # Core concepts Explore core concepts to build a solid understanding of the Digital Worker. These articles will give you the context needed to get the most out of your Digital Worker.

		Cover image
Fundamentals	Learn the full scope of what's possible	ChatGPT Image Apr 20, 2026, 06_56_23 PM.png	Fundamentals
Architecture & capabilities	Discover the components and integrations	ChatGPT Image Apr 20, 2026, 07_00_55 PM.png	Architecture & capabilities
Real-world scenarios	Practical examples of the platform in action across common business use cases.	ChatGPT Image Apr 20, 2026, 07_04_03 PM.png	Real-world scenarios

# Fundamentals ## Overview The Customer Order Manager is an AI-powered Digital Worker designed to free order processing teams from manual data entry so they can focus on the work that actually requires human expertise. It handles incoming customer orders, extracts critical information from various document formats, validates order details against IFS Cloud, and creates complete order records automatically. By transforming unstructured, manual order intake into a fast, reliable, and error-resistant process, the Customer Order Manager gives teams their time back for building customer relationships, resolving complex issues, and managing exceptions that require genuine judgment. ## Key benefits **Universal format handling:** Processes orders arriving in any format, PDFs, images, Excel sheets, emails, EDI, eliminating format fragmentation and standardizing intake across all channels. **Accuracy and speed combined:** Intelligent validation eliminates part number mismatches, unit conversion errors, and duplicate orders, while delivering instant customer acknowledgment. **Error prevention built-in:** The system cross-checks part numbers, quantities, prices, and delivery details against system records before creating any order. Issues are flagged before they become problems. **Seamless scalability:** Handles high-volume and peak-season periods without bottlenecks, processing orders consistently regardless of volume. **Human expertise elevated:** Routine order creation is handled automatically. Teams focus on exceptions, customer relationships, and decisions that require business judgment. ## The Challenge It Solves Customer order management is often manual and fragmented. Teams must interpret incoming requests, validate details, and create orders across multiple systems. This leads to delays in order processing, errors in data entry, inconsistent customer communication, and limited visibility into order status. In practice, this means teams are spending time on tasks like opening email attachments, re-entering data into ERP systems, manually validating part numbers, converting units, chasing clarifications, and sending acknowledgment emails. High order volumes and inconsistent incoming formats compound the problem, creating bottlenecks during peak periods and increasing the risk of errors that require costly correction. ## Before and after ### Before Before the Customer Order Manager, order processing requires manual effort at every stage: {% stepper %} {% step %} Process inbox and review purchase orders via email, EDI, or portal {% endstep %} {% step %} Extract order details manually {% endstep %} {% step %} Validate customer pricing and terms {% endstep %} {% step %} Check availability constraints {% endstep %} {% step %} Handle discrepancies via email back-and-forth {% endstep %} {% step %} Send acknowledgments {% endstep %} {% step %} Update ERP {% endstep %} {% step %} Follow up on exceptions {% endstep %} {% endstepper %} This manual process introduces data entry errors, inconsistent validation, slow processing cycles, and a poor customer experience during the wait for confirmation. ### After With the Customer Order Manager, the same cycle is compressed into four automated steps: {% stepper %} {% step %} Extract unstructured purchase orders from multiple channels {% endstep %} {% step %} Validate pricing and terms, handle discrepancies {% endstep %} {% step %} Check availability and handle exceptions {% endstep %} {% step %} Update ERP and send automated acknowledgments {% endstep %} {% endstepper %} Routine orders are processed without any human involvement. Exceptions are routed to the right person with full context already attached. ## How it works The Customer Order Manager executes a comprehensive automated workflow that handles the complete order lifecycle from intake to confirmation. **Extraction and initial setup:** The Digital Worker applies extraction rules to pull relevant information from incoming order documents. It retrieves default values such as site ID and coordinator information, identifies the customer by searching for and retrieving the customer ID from the system, and applies site mapping by checking if the customer is registered to a specific site ID using predefined dictionary mapping. **Validation and cross-referencing:** Before creating the order, the system verifies the customer PO number doesn't already exist in IFS Cloud to prevent duplicates, retrieves customer-specific order defaults, and resolves any differences between the customer's part numbers and internal sales part numbers. **Part number resolution:** The system cross-references customer part numbers with sales part numbers and retrieves conversion factors to translate between different quantity representations. This handles scenarios where customers count parts in bulk, such as sets of 12, while the system tracks individual units. **Address matching:** The Digital Worker fetches all addresses stored for the customer and matches the delivery address from the purchase order with system records to ensure accurate fulfilllment. **Order creation:** The system creates the complete customer order in IFS Cloud with all validated information and updates the part number registry if new parts have been added. **Customer communication:** The Digital Worker sends acknowledgments and confirmations back to customers, ensuring timely communication throughout the process. # Architecture & capabilities ## Overview The Customer Order Manager is built on a set of integrated agentic skills coordinated by a Supervisor Agent. This article covers the core skills that make up the Digital Worker, how its agent modes and configuration options work, the full order management workflow, integration points, and how it determines when to proceed automatically versus when to involve a human. ## Agentic skills The Customer Order Manager operates through five core skills. Each handles a distinct part of the order management process. #### Customer communication Handles all order-related conversations with customers, including acknowledgments, status updates, and clarifications. This skill sends confirmations when orders are received and processed, and drafts clarification requests when information is missing or unclear. All customer-facing communication is managed through this skill, ensuring a consistent and timely response regardless of order volume. #### Order processing Interprets incoming orders and converts them into validated purchase order confirmations with correct details and validations. This skill parses order content from emails, PDFs, and other document formats, structures the data, validates completeness, and prepares it for ERP entry. It handles unstructured formats and applies extraction rules to reliably pull part numbers, quantities, prices, and delivery information. #### Asset discovery Identifies the relevant assets, configurations, or product context needed to fulfilll the customer order accurately. This skill validates parts, sizes, and units against system records, ensuring that what the customer has ordered maps correctly to what exists in IFS Cloud before any order is created. #### Quote evaluation Reviews pricing and quote details to ensure the order aligns with agreed commercial terms before processing. This skill checks customer-specific pricing, discounts, and contract terms, flagging any discrepancies between the incoming order and the terms on record. #### Notifications Keeps teams informed by sending timely alerts and updates when actions, approvals, or exceptions are required. When an order is processed successfully, teams receive confirmation via Microsoft Teams. When an exception is detected, the notification includes full context so the team can make a decision quickly. ## Agent modes and configuration The Customer Order Manager offers two agent configurations to match the complexity of different order types. **Basic agent mode** uses standard language models for straightforward order processing with clear part numbers and standard formats. This mode is suitable for high-volume, well-structured orders. **Reasoning mode** employs advanced reasoning models for complex scenarios requiring deeper analysis, unclear formats, or sophisticated validation logic. This mode is appropriate when orders involve ambiguous formatting, non-standard part references, or multi-step validation requirements. In Reasoning Mode, administrators can configure: * **Reasoning effort:** Controls how much computational effort the agent applies to problem-solving and validation * **Verbosity:** Adjusts how detailed the agent's responses and logging will be, supporting transparency and debugging * **Concurrent processing:** Enables parallelization of tool execution to improve performance when handling multiple orders simultaneously ## Order management workflow The following table outlines the full order management workflow from initial intake through to customer communication. | Order Intake & Parsing | Parses orders from email, EDI, and portals; extracts customer, items, quantity, price, and dates; handles unstructured formats | Structures order data, validates completeness, triggers order workflow | Email / EDI / IFS | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------- | ----------------- | | Order Validation & Contract Check | Validates pricing, checks customer terms and discounts, identifies inconsistencies | Flags discrepancies, applies validation rules, routes for exception or auto-processing | IFS / Teams | | Availability & Feasibility Check | Checks stock availability, identifies constraints such as lead time or capacity, detects fulfilllment risks | Confirms feasibility, flags constraints, triggers alternative flows if needed | IFS | | Order Creation & Processing | Validates structured order data, ensures ERP readiness | Creates order in IFS Cloud, ensures data consistency, triggers downstream processes | IFS | | Exception Handling & Resolution | Identifies mismatches in price, date, or quantity; detects incomplete orders | Triggers human-in-the-loop review, suggests resolution options, resumes flow after decision | Teams / Email | | Customer Communication | Detects need for acknowledgment or clarification, identifies delays or issues | Sends order confirmations, drafts clarification emails, provides status updates | Email | ## Tools and integration layer The Customer Order Manager uses a comprehensive set of tools to interact with IFS Cloud and connected systems: * **Get Defaults:** retrieves site ID and coordinator defaults * **Get Customer ID:** searches and matches customer names to retrieve customer IDs * **Get Customer Bases:** fetches customer-specific defaults needed for order creation * **Get Addresses:** retrieves stored customer addresses for validation and matching * **Check PO Number:** validates whether a customer PO number has been used previously * **Get Sales Part Numbers:** retrieves cross-reference information for part number resolution * **Get Part Information:** fetches detailed information for each part including conversion factors * **Create and Update Order:** generates the customer order record in IFS Cloud * **Update Entities:** adds new parts to the system when necessary ## Integration points **Email Systems:** Monitors Microsoft Outlook and Gmail inboxes continuously, processing incoming customer orders with PDF, image, and Excel attachments in real time. **ERP Platforms:** Integrates directly with IFS Cloud to read customer records, validate part numbers and pricing, and write complete order details automatically. **Collaboration Platforms:** Uses Microsoft Teams, Slack, OneNote, and Google Drive for exception notifications, approvals, and documentation. **CRM Systems:** Connects with Salesforce, HubSpot, and Qoncierge to maintain customer relationship context and communication history. **Document Processing:** Handles PDFs, images (JPG, PNG), Excel sheets, and EDI with high extraction accuracy using OCR and AI-powered parsing. ## Human-in-the-loop design The Customer Order Manager is designed so that routine processing happens automatically and human judgment is applied where it's genuinely needed. The system proceeds independently when: * Part numbers are valid and exist in the system * Quantities are standard and delivery requirements are clear * Customer information matches existing records * The order is complete with no exceptions or discrepancies Human input is required when: * Part numbers are invalid or don't exist in the system * Information is unclear or missing and requires clarification * Only some line items in an order are valid * Orders involve pricing discrepancies or contract term conflicts * Business judgment is required for high-value or complex decisions When an exception is detected, the system identifies the specific issue, sends a detailed notification via Microsoft Teams with complete context, allows team members to provide guidance directly in the Teams channel, and executes the approved action immediately once a decision is made. ## Testing and validation The platform includes an evaluation environment for testing and development. Teams can input sample email bodies with realistic content, attach PDF documents containing customer order information, trigger the agent and observe processing in real time, and monitor all tool calls and interactions. Debug mode provides detailed visibility into the inputs and outputs of each tool call. Advanced view breaks down each operation into form input, API task, and response processing components for complete transparency into how each step is being handled. # Real-world scenarios ## Overview This article walks through two practical scenarios that illustrate how the Customer Order Manager handles incoming purchase orders. The first covers a clean, straightforward order that processes without any human intervention. The second covers an order with invalid line items, showing how the Digital Worker detects the issue, escalates to a team member, and executes the corrected order once a decision is made. ### Scenario 1: Standard order processing This scenario covers the most common type of interaction, a customer sends a purchase order with valid part numbers, standard quantities, and clear delivery requirements. Everything matches what's in the system. **What triggers it:** A customer sends an email to the order manager's monitored inbox with a purchase order attached as a PDF. **What the Digital Worker does:** 1. The Customer Communication skill detects the incoming email, identifies it as a purchase order, and acknowledges receipt to the customer. 2. The Order Processing skill extracts all fields from the PDF, customer details, part numbers, quantities, prices, and delivery dates, and structures them for validation. 3. The Asset Discovery skill validates the parts, sizes, and units against IFS Cloud to confirm everything is accurate and matches system records. 4. The order is created in IFS Cloud with complete details and released into the processing workflow. 5. The Notifications skill sends confirmation to the team via Microsoft Teams and a confirmation back to the customer that their order has been received and is being fulfillled. **Result:** The complete order is created in IFS Cloud with no manual intervention. The team receives immediate visibility via Teams. The customer receives a confirmation without having to follow up. The entire process, from email receipt to ERP entry to customer acknowledgment, happens automatically. ### Scenario 2: Order with invalid line items This scenario covers an order where not all line items are valid. The customer submits an order with three line items, but only one part number exists in the system. The other two are invalid. #### Step 1: Order received and processed The customer sends their purchase order via email, unaware that two of the three part numbers cannot be found in IFS Cloud. The Digital Worker picks up the email, reads through it, and begins processing the attached PDF, cross-referencing every line item against the part catalog in IFS Cloud at the same time. #### Step 2: Exception detected The system identifies that two of the three part numbers are invalid. Rather than making assumptions, processing bad data into the system, or rejecting the entire order, the Digital Worker flags the issue and sends a notification via Microsoft Teams. The notification includes full context: which line items are valid, which are not, and what the issue is. The team has everything they need to make a decision without doing any additional investigation. #### Step 3: Human decision made A team member reviews the exception in Teams and instructs the Digital Worker to proceed, creating the order for the one valid line item and holding the others pending clarification with the customer. This decision takes seconds, not the 10 to 15 minutes it would have taken to manually process the entire order from scratch and then discover the errors. #### Step 4: Order created The Digital Worker executes the instruction immediately. The order is created in IFS Cloud with only the valid line item, with correct quantity and all other details exactly as specified. The team receives confirmation that the order has been created. **Result:** The Customer Order Manager didn't blindly process incorrect data or reject the order entirely. It identified exactly what was wrong, surfaced the issue to the right person with full context, and executed precisely what was decided, leaving the team in control of the exception while handling all the processing work automatically. ## What these scenarios illustrate **Clean orders require no human involvement.** When an order is complete and valid, the Digital Worker handles the entire process end to end, extraction, validation, ERP entry, and customer confirmation, without the team needing to look at it. **Exceptions are caught before they cause problems.** The system detects issues at the validation stage, before any bad data enters IFS Cloud. Teams are notified with enough context to make a fast, informed decision. **Partial orders can be actioned.** The Digital Worker doesn't treat an order as all-or-nothing. Valid line items can be processed independently while exceptions are handled separately, keeping fulfilllment moving without waiting for every issue to be resolved. **Teams stay in control of decisions, not data entry.** The human role in the process is judgment, deciding what to do with exceptions, how to communicate with customers, and what the right business call is. The Digital Worker handles all of the processing that surrounds those decisions. # FAQ ### Capabilities & functionality **Q: What does Customer Order Manager do for me?** A: It streamlines customer communications, automatically updates sales orders, manages delivery requests, and sends confirmations — reducing manual effort so you can focus on customer satisfaction. **Q: How quickly does Customer Order Manager respond to customer requests?** A: In near real-time. As soon as a customer email or portal message arrives, Customer Order Manager scans it, extracts key details, and updates your ERP or CRM system, often before your team sees the message. **Q: How does Customer Order Manager know what to update?** A: It parses customer communications (emails, attachments, or forms) to capture order details and cross-checks them against your existing sales orders for accuracy. **Q: What if a customer changes multiple details at once?** A: Customer Order Manager can process combined updates — for example, a shipping address change and an updated quantity — applying them accurately and keeping a full record of the original request. **Q: Does Customer Order Manager support global customers?** A: Yes. It supports multilingual parsing, international shipping details, multiple currencies, and region-specific tax rules to ensure orders are processed correctly. ### Control & collaboration **Q: Will customers realize they're interacting with a digital worker?** A: No. Customer Order Manager uses professional business communication templates, so responses appear to come from your customer service or sales team. **Q: Can I override Customer Order Manager's decisions?** A: Yes. You can define thresholds for automation and set rules requiring human review — for example, high-value order changes, unusual requests, or special discounts. **Q: What happens if a customer doesn't confirm their order?** A: Customer Order Manager automatically follows up with reminder messages. If the customer remains unresponsive, it escalates the case to a team member. **Q: How will this affect my role?** A: Instead of manually updating orders and chasing confirmations, you'll spend more time resolving complex issues, improving customer experience, and growing customer relationships. ### Integration & technology **Q: How does Customer Order Manager connect to ERP or CRM systems?** A: It uses standard APIs to validate and update orders, ensuring customer requests flow directly into your core systems. **Q: Which APIs does Customer Order Manager rely on?** A: Core APIs handle sales order creation, updates, confirmations, and document retrieval to maintain accurate and reliable records. **Q: Can Customer Order Manager integrate with tools beyond ERP?** A: Yes. It can connect with Outlook, Gmail, Teams, and other communication platforms to centralize customer interactions across channels. ### Security & reliability **Q: How are customer interactions tracked?** A: Every message sent, order updated, and confirmation logged is written back to your ERP or CRM history. Entries are stamped with the digital worker's ID for full transparency. **Q: How is customer data protected?** A: Sensitive customer and order data stays within your ERP, CRM, and email environments. Customer Order Manager uses secure APIs and logs all transactions for compliance. **Q: What happens if ERP or CRM systems are unavailable?** A: Customer Order Manager queues updates and retries once systems are restored. Urgent customer communications are still drafted and logged, then reconciled when connectivity returns. ### Customization & performance **Q: Can Customer Order Manager adapt to our unique customer workflows?** A: Yes. It supports configuration of custom rules, triggers, and approval steps tailored to your ERP or CRM setup and customer engagement practices. **Q: How is performance measured?** A: Typical KPIs include order response time, percentage of automated customer requests processed, reduction in manual errors, and time saved per week. These are tracked via dashboards. # Case studies See how our customers are using this Digital Worker to transform their operations. # Closeout and Improvement Manager Closing out maintenance work takes judgment, but repetitive validation and paperwork shouldn't slow supervisors down. This knowledge base guides you through using the Closeout and Improvement Manager, from initial setup to handling work order closeout efficiently in daily operations. ### Jump right in

		Cover image
Watch & learn	See this Digital Worker in action.	create an image for watch and learn.png	Watch & learn
Core concepts	Essential context for understanding how it all works.	create an image for core concepts_.png	Core concepts
FAQ	Quick answers to common questions.	create an image for frequently asked questions_.png	FAQ
How-to guides	Practical, step-by-step guidance across a range of tasks	create a tile image representing digital worker gu (2).png	How-to guides

		Cover image
Fundamentals	Learn the full scope of what's possible	ChatGPT Image Apr 20, 2026, 06_56_23 PM.png	Fundamentals
Architecture & capabilities	Discover the components and integrations	ChatGPT Image Apr 20, 2026, 07_00_55 PM.png	Architecture & capabilities
Real-world scenarios	Practical examples of the platform in action across common business use cases.	ChatGPT Image Apr 20, 2026, 07_04_03 PM.png	Real-world scenarios

# Fundamentals ## Overview The Closeout and Improvement Manager is an AI-powered Digital Worker that runs maintenance work order closeout end-to-end for supervisors, planners, reliability engineers, and asset managers. Instead of a supervisor reviewing every completed task by hand, it validates work against the plan, scores documentation quality, surfaces follow-up work and reliability findings, and orchestrates authorization and closure. The Closeout and Improvement Manager has the bandwidth to read and review every task in full, not just the ones that look uncertain. Even when every number matches the plan exactly, it still reads the technician’s remarks in full, which is where it catches what a quick glance at matching hours would miss. ## Key Benefits **Reduced admin effort:** Supervisors focus on reliability, not paperwork, since the Digital Worker handles the review that used to consume their time. **Faster closeouts:** Work orders close in a fraction of the time it takes to review each one by hand. **Higher data quality:** Consistent, complete maintenance documentation, evaluated the same way on every task rather than depending on how much time a supervisor had that day. **Better reliability:** Follow-up work and improvement opportunities are captured systematically, including the ones buried in a technician’s remarks rather than flagged explicitly. **Stronger governance:** Policies, tolerances, and approvals are enforced consistently across every closeout decision. ## The Challenge It Solves Managing maintenance work order closeouts is often manual, inconsistent, and time-consuming. Maintenance supervisors spend significant effort reviewing technician work notes, validating reported labor and materials, checking documentation quality, identifying follow-up work, and confirming asset records are complete before authorizing completion. The result is delayed work order closure, inconsistent documentation, missed improvement opportunities, and reduced visibility into maintenance performance. When the numbers on a task match the plan exactly, a quick look and a pass through the approval queue is commonplace, and given the volume, it’s easy for something to slip through unnoticed, like a follow-up issue mentioned only in passing in the technician’s own words. ## Before and After ### **Before** Before the Closeout and Improvement Manager, closing out a maintenance work order requires manual effort at every stage: {% stepper %} {% step %} Review the technician’s work notes, remarks, and reported findings by hand {% endstep %} {% step %} Manually validate reported labor and materials against what was planned {% endstep %} {% step %} Judge documentation quality and completeness task by task {% endstep %} {% step %} Look for follow-up work or improvement opportunities buried in free-text notes, often only catching what stands out on a quick read {% endstep %} {% step %} Confirm asset records are complete before authorizing completion {% endstep %} {% step %} Authorize each work task and close the parent work order manually {% endstep %} {% endstepper %} ### **After** With the Closeout and Improvement Manager, the same process runs automatically: {% stepper %} {% step %} Full work context is retrieved for the completed task: work order, asset, technician, and plan details {% endstep %} {% step %} Documentation quality is assessed, scoring the technician’s remarks, actions, and findings for completeness and clarity {% endstep %} {% step %} Planned work is validated against actual: labor, materials, services, and costs checked against configurable tolerances {% endstep %} {% step %} Follow-up work and improvement opportunities are detected, including issues mentioned only in the technician’s own words {% endstep %} {% step %} Maintenance is recommended where needed, raising a work request, fault report, or maintenance change request {% endstep %} {% step %} Work tasks are authorized automatically when every check passes, with exceptions routed for review {% endstep %} {% step %} Asset integrity is validated, tracking serialized install, removal, and return actions {% endstep %} {% step %} The parent work order is closed once every child task and follow-up is accounted for, and a closeout summary is generated {% endstep %} {% endstepper %} ## **How It Works** The Closeout and Improvement Manager follows an eight-step sequence for every completed work task and the parent work order it belongs to. **Work Context & Validation:** The worker retrieves the work task, work order, asset, technician, and plan details, along with labor, materials, services, tools, measurements, and notes, enriched with the asset’s history and past maintenance context. **Documentation Quality Assessment:** Technician remarks, action taken, and findings are evaluated. Completed work steps and required fields are validated, documentation completeness and clarity are checked, and a documentation quality score is determined. **Planned vs Actual Validation:** Reported labor is compared against planned labor, along with materials, services, tools, and equipment. Costs are validated against plan using configurable tolerance rules, and variances and exceptions are identified. **Follow-up Work & Improvement Detection:** Notes and observations are analyzed using AI to detect new defects, anomalies, or incomplete work, and to identify recurring issues or reliability risks. Follow-up actions or improvement opportunities are recommended. **Maintenance Recommendation:** A work request or fault report is created for new issues, or a maintenance change request is created for process or plan improvements, routed for approval to the supervisor, planner, or reliability engineer. **Work Task Authorization:** All validation results are consolidated, and business rules and approval policies are applied. A work task that passes every check is auto-authorized; anything else is routed for human-in-the-loop review. **Parent Work Order Validation:** The worker confirms every child work task is completed and authorized, checks for pending follow-up actions or maintenance change requests, and validates the asset hierarchy and any serialized component updates before the work order is ready for closeout. **Work Order Closeout:** A closeout summary is generated with key decisions and insights, the work order status is updated to closed, the audit trail and closeout history are recorded, and notifications are sent via Microsoft Teams and email. ## What Triggers the Closeout and Improvement Manager **A completed work task:** The worker retrieves full work context the moment a technician completes a work task in IFS Cloud. **A parent work order nearing closeout:** Once every child task under a work order is authorized, the worker validates the parent order to confirm it’s ready to close. **A documentation quality check:** Every completed task’s remarks, actions, and findings are assessed for completeness and clarity, regardless of whether the reported numbers already match the plan. **A variance outside tolerance**: Labor, materials, services, or costs that fall outside the configured tolerance are identified as exceptions requiring review. **A follow-up or improvement signal in the notes:** Free-text remarks and observations are analyzed for new defects, anomalies, recurring issues, or reliability risks, even when nothing in the structured data flags a problem. # Architecture & capabilities ## Overview The Closeout and Improvement Manager is built on five agentic skills that together take a completed maintenance work task from initial review through to a closed work order: Work Context & Quality Assessment, Work Validation & Authorization, Follow-up Work & Improvement Detection, Maintenance Decision Closeout, and Closeout Summary & Notification. This article covers those skills, the closeout workflow they share, integration points, and how the system keeps a supervisor in the loop on the decisions that need one. ## Agentic Skills #### Work Context & Quality Assessment Detects completed work tasks and retrieves the work task, work order, asset, technician, and plan details, enriched with the asset’s history and past maintenance context. This skill also evaluates the technician’s remarks, actions taken, and findings, scoring documentation completeness and clarity so that quality is assessed the same way on every task. #### Work Validation & Authorization Compares reported labor, materials, services, tools, and equipment against what was planned, validating costs against configurable tolerance rules and identifying variances and exceptions. This skill also consolidates every validation result, applies business rules and approval policies, and auto-authorizes a work task once it passes all checks, routing anything else for human-in-the-loop review. #### Follow-up Work & Improvement Detection Analyzes notes and observations using AI to detect new defects, anomalies, or incomplete work, and to identify recurring issues or reliability risks. This skill recommends follow-up actions or improvement opportunities, including ones mentioned only in a technician’s own words rather than flagged through structured data. #### Maintenance Decision Closeout Creates a work request or fault report for a new issue, or a maintenance change request when the finding points to a process or plan improvement, and routes it for approval to the supervisor, planner, or reliability engineer. This skill also validates the parent work order: confirming every child task is completed and authorized, checking for pending follow-up actions or maintenance change requests, and validating the asset hierarchy and any serialized component updates before closeout. #### Closeout Summary & Notification Generates a closeout summary capturing key decisions and insights, updates the work order status to closed, records the audit trail and closeout history, and sends notifications through Microsoft Teams and email. #### Closeout Workflow The following table outlines the process from a completed work task through to a closed work order. | Stage | What the System Does | Action / Output | Channel | | --------------------------------- | -------------------------------------------------------------------------------------------- | --------------------------------------------- | ------------- | | Work Context & Validation | Retrieves work task, order, asset, technician, and plan details, enriched with asset history | Work context assembled | IFS Cloud | | Documentation Quality Assessment | Evaluates technician remarks, actions, and findings | Documentation quality score determined | IFS Cloud | | Planned vs Actual Validation | Compares reported labor, materials, and costs against plan tolerances | Variances and exceptions identified | IFS Cloud | | Follow-up & Improvement Detection | Analyzes notes with AI for defects, anomalies, and recurring issues | Follow-up actions or improvements recommended | IFS Cloud | | Maintenance Recommendation | Creates a work request, fault report, or maintenance change request | Recommendation routed for approval | IFS Cloud | | Work Task Authorization | Consolidates validation results and applies approval policies | Task auto-authorized, or routed for review | IFS Cloud | | Parent Work Order Validation | Confirms child tasks and follow-ups are complete | Work order confirmed ready for closeout | IFS Cloud | | Work Order Closeout | Generates closeout summary and updates work order status | Work order closed, notifications sent | Teams / Email | ## Integration Points **IFS Cloud (EAM/Maintenance):** The primary system of record. The Closeout and Improvement Manager reads work orders, work tasks, asset data, and maintenance history, and writes back authorizations, recommendations, and closeout status. **Microsoft Teams:** Used to send closeout notifications and route exceptions for human-in-the-loop review. **Outlook/Email:** Used alongside Teams for closeout notifications. **Other Enterprise Systems:** Additional integration points beyond core IFS Cloud EAM/Maintenance functionality, as configured for the deployment. ## Human-in-the-Loop Design The Closeout and Improvement Manager is designed so that clean, fully validated work authorizes and closes automatically, while exceptions and genuine judgment calls surface to a supervisor with an explanation attached. The system authorizes and proceeds automatically when: * Reported labor, materials, services, and costs fall within the configured tolerance against plan * Documentation quality clears the required bar * No follow-up or improvement action is pending approval A supervisor, planner, or reliability engineer is brought in when: * A validation result falls outside tolerance and is routed as an exception * A follow-up work request, fault report, or maintenance change request needs approval * The parent work order has a pending follow-up action or maintenance change request still undecided Exceptions are surfaced with explanations, so a supervisor can approve, reject, or clarify a decision rather than having to reconstruct the reasoning themselves. ## Feedback and Continuous Improvement Maintenance governance is enforced consistently: the same policies, approval rules, tolerance limits, and asset hierarchy validations apply to every work task, regardless of who completed it or how busy the supervisor reviewing it might be. Real-time operational visibility, through dashboards on work status, exception trends, improvements, and closeout performance, gives supervisors and reliability engineers insight into where closeout bottlenecks and recurring issues are showing up across the maintenance team, rather than that picture only emerging after the fact. # Real-world scenarios ## Overview This article walks through a six-month service on a coupling assembly, where every number matches the plan exactly, showing how the Closeout and Improvement Manager still catches a reliability issue that a quick review would have missed. ### Scenario: A Clean Match That Wasn’t Entirely Clean A technician completes a six-month service on a coupling assembly and reports four hours against four hours planned, an exact match. The work finishes inside the service window, and the documentation is properly completed. #### Step 1: The Easy Read When the hours match the plan, giving it a quick look and continuing through the approval queue is commonplace. Given the volume of work orders moving through closeout, it’s easy for something to slip through unnoticed under that kind of review. #### Step 2: Full Context Retrieved and Validated The Closeout and Improvement Manager has the bandwidth to read and review the entire task, not just the numbers. It retrieves the full work context, work order, asset, technician, and plan details, and validates the documentation. #### Step 3: Every Check Passes The hours match, the timing falls inside the service interval, and the documentation clears the quality bar. Every check passes, and the Digital Worker’s assessment aligns with the supervisor’s. #### Step 4: The Remarks Are Read in Full But the Closeout and Improvement Manager also catches details the human reviewer didn’t. Buried in the technician’s remarks is an additional activity resolved: a recurring vibration issue on the coupling. #### Step 5: Duplicate Records Ruled Out After confirming no additional records were already created for the issue, the Digital Worker opens a follow-up inspection to determine whether the coupling needs permanent corrective action. #### Step 6: A Maintenance Change Request Raised It also raises a maintenance change request to review the equipment configuration and the maintenance strategy behind the asset. Result: A work order that would have closed cleanly on a quick review instead surfaces a recurring reliability issue, with a follow-up inspection opened and a maintenance change request raised, both traced directly back to the technician’s own words in the remarks. ### What This Scenario Illustrates **A perfect match is not the same as a complete review**. Hours matching the plan exactly is exactly the kind of task most likely to get a quick look rather than a full read, and that’s precisely where something can slip through. **The Closeout and Improvement Manager reads every task in full**, regardless of how clean it looks. It doesn’t reserve full attention for tasks that already look uncertain. **Follow-up issues are found in free text**, not just flagged fields. The vibration issue was resolved and mentioned in passing in the technician’s remarks, not raised as a separate structured finding. **Duplicate-checking happens before anything is opened**. The worker confirms no additional records already exist for the issue before opening a follow-up inspection, avoiding redundant work. **A single finding can trigger two different kinds of follow-up.** The same buried detail led to both a task-level follow-up inspection and a request-level maintenance change request examining the asset’s configuration and maintenance strategy. **Manual review no longer stands between a completed task and a closed work order**. Supervisors get their time back, reducing admin effort, closing work orders faster, capturing higher quality maintenance data, strengthening asset reliability, and reinforcing governance across every closeout decision. # FAQ ### Capabilities & functionality **Q: What does the Closeout and Improvement Manager do?** A: The Closeout and Improvement Manager is a Digital Worker that runs maintenance work order closeout end-to-end. It retrieves full work context, assesses documentation quality, validates planned work against actual, detects follow-up work and improvement opportunities, recommends maintenance where needed, authorizes work tasks, validates asset integrity, and closes the parent work order with a generated summary. **Q: Does it only catch problems, or does it also review work that looks clean?** A: It reviews every task in full, including ones where the reported hours match the plan exactly. A clean match on the numbers is exactly the kind of task most likely to get only a quick look in manual review, which is why the Digital Worker reads the full remarks regardless of how clean a task appears. **Q: How does it find follow-up work that isn’t flagged explicitly?** A: It analyzes technician notes and observations using AI to detect new defects, anomalies, incomplete work, or recurring issues, including ones mentioned only in passing in free-text remarks rather than raised as a separate structured finding. **Q: What happens when a follow-up issue is found?** A: The worker first confirms no additional records already exist for the issue, then opens the appropriate follow-up, such as an inspection, and can also raise a maintenance change request when the finding points to a broader configuration or maintenance-strategy question. **Q: Does the Closeout and Improvement Manager close the work order itself?** A: It closes the parent work order once every child task is completed and authorized and no follow-up action or maintenance change request is still pending, generating a closeout summary with the key decisions and insights behind it. ### Control & Collaboration **Q: Does every work task get auto-authorized?** A: No. A work task is auto-authorized only once it passes every validation check. Anything that falls outside tolerance or needs judgment is routed for human-in-the-loop review instead. **Q: Who reviews an exception the Closeout and Improvement Manager raises?** A: The supervisor, planner, or reliability engineer relevant to the finding, depending on whether it’s a work task authorization exception or a maintenance recommendation awaiting approval. **Q: What does a supervisor see when reviewing a flagged item?** A: Exceptions are surfaced with an explanation, so a supervisor can approve, reject, or clarify the decision rather than having to reconstruct the reasoning behind the flag themselves. **Q: How are closeout decisions communicated to the team?** A: Notifications are sent through Microsoft Teams and email, and a closeout summary capturing the key decisions and insights is generated for every closed work order. ### Integration & Technology **Q: What systems does the Closeout and Improvement Manager integrate with?** A: It integrates with IFS Cloud’s Enterprise Asset Management and Maintenance modules as the primary system of record, Microsoft Teams and Outlook/Email for notifications and exception review, and other enterprise systems as configured for the deployment. **Q: What data does it pull when reviewing a completed task?** A: The work task, work order, asset, technician, and plan details, along with labor, materials, services, tools, measurements, and notes, enriched with the asset’s history and past maintenance context. **Q: What triggers the Closeout and Improvement Manager to begin reviewing a task?** A: A technician completing a work task in IFS Cloud triggers the worker to retrieve full work context and begin the review. **Q: Does it validate asset records as part of closeout?** A: Yes. It validates the asset hierarchy and tracks serialized install, removal, and return actions, confirming asset integrity before the parent work order is ready to close. ### Security & Reliability **Q: How is documentation quality assessed consistently?** A: The same evaluation applies to every task: technician remarks, actions taken, and findings are scored for completeness and clarity using a consistent documentation quality assessment, rather than depending on how much time a reviewer had. **Q: What keeps a variance from slipping through unnoticed?** A: Reported labor, materials, services, and costs are checked against configurable tolerance rules on every task, and anything outside tolerance is identified as a variance or exception rather than silently passed. **Q: Is there an audit trail for closeout decisions?** A: Yes. The audit trail and closeout history are recorded as part of Work Order Closeout, alongside the generated closeout summary capturing the key decisions and insights behind it. **Q: How is governance enforced across different supervisors and sites?** A: The same policies, approval rules, tolerance limits, and asset hierarchy validations are applied consistently to every work task, regardless of who completed it or which supervisor would otherwise be reviewing it. ### Customization & Performance **Q: Can tolerance rules be configured?** A: Yes. Planned versus actual validation, covering labor, materials, services, and costs, is checked against configurable tolerance rules rather than a fixed threshold. **Q: What kind of maintenance recommendations can the Digital Worker raise?** A: A work request or fault report for a new issue, or a maintenance change request when a finding points to a broader process, configuration, or maintenance-strategy question, routed for approval to the relevant supervisor, planner, or reliability engineer. **Q: What visibility does the Closeout and Improvement Manager provide beyond individual work orders?** A: Dashboards provide insight into work status, exception trends, improvements, and closeout performance, giving supervisors and reliability engineers visibility into bottlenecks and recurring issues across the maintenance team. **Q: What are the five core skills behind the Closeout and Improvement Manager?** A: Work Context & Quality Assessment, Work Validation & Authorization, Follow-up Work & Improvement Detection, Maintenance Decision Closeout, and Closeout Summary & Notification. Together, they take a completed task from initial review through to a closed work order. # Case studies See how our customers are using this Digital Worker to transform their operations. # Dispatcher Assistant Managing dispatch operations takes coordination, but repetitive scheduling work shouldn't hold teams back. This knowledge base guides you through using the Dispatcher Assistant to streamline dispatch workflows in daily operations. ### Jump right in

		Cover image
Watch & learn	See this Digital Worker in action.	create an image for watch and learn.png	Watch & learn
Core concepts	Essential context for understanding how it all works.	create an image for core concepts_.png	Core concepts
FAQ	Quick answers to common questions.	create an image for frequently asked questions_.png	FAQ
How-to guides	Practical, step-by-step guidance across a range of tasks	create a tile image representing digital worker gu (2).png	How-to guides

		Cover image
Fundamentals	Learn the full scope of what's possible	ChatGPT Image Apr 20, 2026, 06_56_23 PM.png	Fundamentals
Architecture & capabilities	Discover the components and integrations	ChatGPT Image Apr 20, 2026, 07_00_55 PM.png	Architecture & capabilities
Real-world scenarios	Practical examples of the platform in action across common business use cases.	ChatGPT Image Apr 20, 2026, 07_04_03 PM.png	Real-world scenarios

# Fundamentals ## Overview The Dispatcher Assistant is an AI-powered Digital Worker designed to keep field service operations stable when conditions aren't. It monitors live schedules and execution signals continuously, identifies exceptions and SLA risks early, while corrective options still exist, and generates ranked reallocation options with clear reasoning behind each one. Low-risk actions can proceed automatically. Higher-impact decisions are escalated to dispatchers with everything needed to confirm quickly. Customer communication is handled throughout, keeping all parties informed without adding to the dispatcher's workload. By converting reactive, manual exception handling into a structured, proactive process, the Dispatcher Assistant gives dispatch teams time back for the complex trade-offs, difficult customer conversations, and judgment calls that genuinely require human experience. ## Key Benefits **Early exception detection:** SLA risks and schedule disruptions are identified as they develop, not after a breach has already occurred, giving dispatchers time to act while options are still available. **Ranked reallocation options:** When an exception is detected, the system evaluates engineer availability, skill match, travel feasibility, and downstream impacts, then surfaces ranked options with the reasoning behind each one, so dispatchers make informed decisions rather than quick guesses. **Automated customer communication:** Customers are notified automatically when schedules change, appointments are renegotiated via email or SMS, and confirmations are handled end to end, without dispatcher involvement for routine cases. **Consistent exception decisions:** All disruptions follow the same structured, explainable flow aligned with PSO logic, eliminating the variability that comes from relying on individual dispatcher experience across regions and teams. **Scalable disruption management:** The same approach handles both individual exceptions and large-scale regional events such as weather or outages, without requiring additional dispatcher headcount. **Full traceability:** Every exception, recommendation, and schedule change is tracked and auditable end to end. ## The challenge it solves Dispatch teams operate in a constant state of disruption. Delays, cancellations, overruns, and last-minute customer changes force dispatchers into reactive firefighting. SLA risks are often identified too late, schedules are manually reshuffled mid-day, and communication across customers, engineers, and systems becomes fragmented. At scale, regional events amplify the problem, creating operational bottlenecks and inconsistent outcomes. In practice, dispatchers are spending 40 to 60% of their time on exception management: manually reassigning jobs, calling or emailing customers to reschedule, spending 10 to 20 minutes per disrupted job on coordination, managing bulk disruption events without a structured process, and relying heavily on individual experience to make reallocation decisions. Schedule changes and customer communication are handled separately, creating gaps and inconsistency. ## Before and After ### Before Before the Dispatcher Assistant, handling a schedule exception requires manual effort at every stage: {% stepper %} {% step %} Monitor engineer delays, overruns, and incoming exceptions {% endstep %} {% step %} Review job details, SLA commitments, and the current schedule {% endstep %} {% step %} Assess impact across downstream appointments {% endstep %} {% step %} Identify conflicts and prioritization issues {% endstep %} {% step %} Manually explore reallocation or rescheduling options {% endstep %} {% step %} Contact customers to renegotiate appointments {% endstep %} {% step %} Update the schedule and systems with agreed changes {% endstep %} {% endstepper %} This process is slow, inconsistent across teams, and limited in its ability to account for downstream impacts before changes are made. ### After With the Dispatcher Assistant, the same process runs in five automated steps:
{% stepper %} {% step %} Detect exceptions in real time, monitors delays, overruns, and regional events automatically {% endstep %} {% step %} Evaluate impact on schedule and SLA, identifies affected appointments using PSO and business rules {% endstep %} {% step %} Generate optimized resolution options, proposes engineer swaps, resequencing, or alternative slots {% endstep %} {% step %} Orchestrate customer negotiation, engages customers via email or SMS, presents options, manages responses {% endstep %} {% step %} Execute and update systems, confirms the new appointment, updates IFS Cloud, logs the outcome and audit trail {% endstep %} {% endstepper %} ## How It Works The Dispatcher Assistant continuously monitors live schedules and execution signals in PSO, interpreting customer and system-driven exceptions and assessing their impact on time-to-breach, SLA exposure, and engineer capacity. **When an exception is detected:** the system evaluates the situation using real-time availability, engineer capability and location, SLA and priority constraints, travel optimization, and customer history, accounting for downstream impacts before any recommendation is made. **Best-fit appointment options are generated:** ranked by SLA exposure, travel efficiency, and priority. For routine, low-risk exceptions the system can proceed automatically. For higher-impact or lower-confidence decisions, the exception is escalated to the dispatcher with ranked options and clear reasoning, everything needed to confirm quickly without additional investigation. **Customer communication is managed throughout:** proposing new appointment windows, handling back-and-forth responses, refining slots based on customer feedback, and confirming the agreed appointment across all stakeholders. **All decisions are revalidated and logged before commit:** maintaining full oversight and auditability. ## What Triggers the Dispatcher Assistant The Dispatcher Assistant responds to a wide range of operational exceptions that break or threaten the live schedule: **Engineer availability shifts:** engineer calls in sick, is stuck in traffic, experiences a vehicle breakdown, exceeds driving hours, or has a certification lapse. **Job duration drift:** a job overruns its expected duration due to asset complexity, unexpected parts requirements, or safety escalations. **SLA and priority changes:** a customer escalates, a VIP account is prioritized, an asset criticality is reclassified, or a regulatory deadline approaches. **Parts and material disruptions:** a required part is unavailable at van stock, a transfer is delayed, or an incorrect part was dispatched. **Customer behavioral changes:** a customer cancels last minute, restricts site access, or requests a different appointment window. **Environmental and external event:** severe weather, flooding, transport strikes, or regional power outages requiring bulk rescheduling. **System and data anomalies:** duplicate work orders, missing SLA data, or scheduling rule misconfigurations.
# Architecture & capabilities ## Overview The Dispatcher Assistant is built on four agentic skills coordinated by a Support Agent. It operates as a real-time exception orchestrator, running continuously alongside PSO, monitoring live operational signals, and managing the full exception response cycle from detection through to customer confirmation and system update. This article covers the core skills, the full dispatch management workflow, integration points, and how the system determines when to act autonomously versus when to escalate to a dispatcher. ## Agentic Skills #### Customer Exception Parsing & Intent Detection Understands and interprets customer communications and operational signals to accurately identify service disruptions and required actions. This skill distinguishes between different exception types, cancellation, reschedule request, site access issue, job scope change, and extracts relevant context such as asset, location, work order, and urgency level. It classifies the exception and triggers the appropriate workflow, including highlighting SLA exposure risk before any action is taken. #### Engineer & Resource Reallocation Analysis Analyzes engineer availability and workload to recommend optimal reallocations and minimize service disruption. This skill evaluates engineer skill match against job requirements, location and travel feasibility, regional workload balance, and live job completion probability, accounting for the downstream impact on other appointments before any reallocation is proposed. It surfaces ranked options with the reasoning behind each, so dispatchers have the context to make a fast, informed decision. #### Appointment Renegotiation & Customer Communication Manages customer-facing interactions to reschedule appointments, propose alternatives, and maintain clear, consistent communication throughout the process. This skill generates new appointment options ranked by SLA compliance, travel efficiency, and customer priority, then engages the customer via email, SMS, or Teams, handles back-and-forth responses, refines options based on customer feedback, and captures the confirmed appointment for schedule update. It operates autonomously for routine renegotiations and escalates to dispatchers when customer preferences or constraints require judgment. #### PSO Schedule Exception Explanation & Dispatcher Support Explains schedule changes and optimization decisions by translating PSO outputs into clear, actionable insights for dispatchers. This skill identifies the root cause of an exception, analyzes schedule inefficiencies and available slack capacity, and surfaces trade-off options with clear impact explanations, helping dispatchers understand not just what changed, but why, and what the consequences of each resolution option would be. This is particularly valuable for exceptions where PSO has produced a recommendation that requires dispatcher confidence before it can be actioned. ## Dispatch Management Workflow The following table outlines the full exception management workflow from initial detection through to stakeholder notification. | **Stage** | **What the System Does** | **Action / Output** | **Channel** | | ---------------------------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------- | ------------------- | | **Exception Detection** | Detects live disruptions, delays, cancellations, SLA risks, parts readiness issues | Triggers exception workflow, identifies affected job, engineer, and schedule window | FSM / PSO / Teams | | **Context & Impact Analysis** | Evaluates schedule, SLA risk, engineer availability, and constraints; assesses downstream impact | Surfaces SLA breach risk, flags high-priority customers, identifies affected downstream appointments | FSM / PSO | | **Slot Generation & Optimization** | Creates best-fit appointment options ranked by SLA exposure, travel efficiency, and priority | Proposes engineer swap, resequencing, or new appointment slots; accounts for real-time availability and constraints | FSM / PSO | | **Customer Negotiation** | Engages customer via email, SMS, or Teams; proposes options; handles responses | Presents appointment options, iterates based on customer feedback, captures confirmed slot | Email / SMS / Teams | | **Confirmation & Schedule Update** | Confirms agreed slot, updates IFS Cloud schedule, reassigns engineer if needed | Schedule updated, engineer notified with job pack and relevant resources | IFS Cloud / PSO | | **Stakeholder Notification** | Notifies customer, engineer, and dispatch; logs the full decision | Confirmation sent, outcome recorded, full audit trail maintained | Email / SMS / Teams | **Exception paths:** When no suitable slot is available, the system expands the search window and escalates to the dispatcher with trade-off options. When a decision is high-impact or low-confidence, the exception is routed to the dispatcher with ranked scenarios and clear reasoning. When a customer rejects proposed options, the system iterates with new proposals or adjusts based on stated preferences before escalating if needed. ## Integration Points **IFS Cloud / PSO:** Core integration for live schedule data, engineer availability, SLA commitments, and appointment updates. The Dispatcher Assistant runs alongside PSO, reading optimization outputs and writing confirmed schedule changes back into the system. **ERP / Inventory Systems:** Provides parts availability context relevant to job feasibility and appointment timing. **CRM / Ticketing Systems:** Provides customer history, priority context, and communication records. **Email / SMS:** Primary channels for customer appointment renegotiation and confirmation. **Collaboration Platforms:** Microsoft Teams and email for human-in-the-loop escalation, dispatcher decision support, and engineer notification. **Knowledge Platforms:** Connects to knowledge sources to provide relevant job resources to newly assigned engineers. ### Human-in-the-Loop Design The Dispatcher Assistant is designed so that routine exception handling proceeds automatically and dispatcher judgment is applied to the decisions that genuinely require it. The system proceeds automatically when: * The exception is low-risk and a clear resolution exists within configured parameters * Customer communication follows a standard renegotiation pattern * Engineer reallocation meets all feasibility criteria without conflict * The action falls within approved thresholds for autonomous execution Dispatcher approval is required when: * The exception is high-impact or the confidence in the recommended action is low * No suitable slot is available within the standard search window * Trade-offs between SLA protection, customer impact, and engineer workload require judgment * The customer rejects proposed options and the situation requires a strategic decision When escalating to a dispatcher, the system surfaces ranked options with clear reasoning, impact explanations, and trade-off context, everything needed to make a confident decision in seconds rather than minutes. Once the dispatcher confirms, the system executes immediately and handles all downstream communication and system updates. ## Feedback and Continuous Improvement Dispatchers can rate the Dispatcher Assistant's recommendations with a thumbs up or thumbs down directly in the Teams interface. This feedback loop reinforces effective behavior and surfaces patterns for improvement over time, both in how exceptions are classified and in how reallocation options are ranked and presented. All exceptions, recommendations, decisions, and outcomes are logged with full traceability, providing the data needed for ongoing performance analysis, SLA auditing, and operational improvement. # Real-world scenarios ## Overview This article walks through one of the most common field service disruptions, a technician needing to leave early, and shows how the Dispatcher Assistant handles it end to end. The scenario is shown twice: once through the Microsoft Teams interface, and once through the Dispatch interface. Both result in the same outcome, illustrating that the Dispatcher Assistant operates consistently across whichever interface the dispatcher is working in. ### Scenario: Technician Leaves Early, Reassignment via Microsoft Teams A technician has to go home early, leaving a job unassigned for the remainder of the day. Without the Dispatcher Assistant, this would require the dispatcher to identify the affected job, check who has capacity, evaluate their suitability, make the reassignment, notify the new technician, and contact the customer, multiple steps across multiple systems, typically taking 10 to 20 minutes per disrupted job. #### Step 1: Exception Detected The Dispatcher Assistant detects that the technician needs to leave early and proactively surfaces the issue in Microsoft Teams before the dispatcher has spotted it manually. It immediately pulls the relevant job details, what was scheduled, the timing, and the expected duration, so the dispatcher has full context from the first message. #### Step 2: Available Resources Identified The system analyzes engineer availability and evaluates who has the capacity, skills, and travel feasibility to take the job. Two available technicians are surfaced as options. Alongside each option, the Dispatcher Assistant includes additional context, previous experience with similar jobs, current availability, location, and any other relevant factors, giving the dispatcher everything needed to make the right call quickly. #### Step 3: Dispatcher Makes the Selection The dispatcher reviews the options in Teams and selects the technician they want to assign. The decision takes seconds rather than the time it would have taken to manually investigate each option. #### Step 4: Reassignment Executed The Dispatcher Assistant populates the reassignment details and pulls any relevant resources for the job, documentation, job context, or other materials, sending them directly to the newly assigned technician. The schedule is updated automatically. #### Step 5: Feedback Captured The dispatcher gives a thumbs up or thumbs down on the recommendation. This simple feedback loop helps the Dispatcher Assistant track and improve its performance over time, both in how it ranks options and how it presents context for decision-making. #### Step 6: Customer Notified Automatically The Dispatcher Assistant emails the customer to let them know their schedule has changed. No manual email drafting, no risk of the notification being missed or delayed. The customer is informed promptly with a clear, professional message. **Result:** A process that would normally span multiple steps, multiple people, and significant back-and-forth is resolved end to end with a few keystrokes. The job is reassigned, the new technician is briefed, and the customer is notified, all handled through a single Teams interaction. ### Same Scenario: Reassignment via the Dispatch Interface The same exception, a technician leaving early, can also be handled directly through the Dispatch interface rather than Teams. The process and outcome are identical; the interface is different. The Dispatcher Assistant surfaces the notification in the Dispatch interface, providing the same level of detail: which job is affected, the original schedule, and how long it was set to last. Two available resources are presented with additional context to support the decision. The dispatcher selects the preferred technician, the job is reassigned, relevant resources are shared with the new technician, and the customer is automatically notified. The feedback mechanism works the same way, the dispatcher gives a thumbs up or down, and the full decision is logged with an audit trail. ## What This Scenario Illustrates **Exceptions are caught proactively, not reactively.** The Dispatcher Assistant surfaces the issue before the dispatcher has had to spot it themselves, early enough that a clean reassignment is straightforward rather than a last-minute scramble. **Options come with reasoning, not just names.** The system doesn't just show who is available, it provides the context behind each option, so the dispatcher's decision is informed rather than instinctive. Experience, availability, and location are all surfaced alongside the recommendation. **The dispatcher makes the decision; the system does the rest.** Once the dispatcher selects a technician, everything else, the reassignment, the technician briefing, the customer notification, happens automatically. The dispatcher's role is the judgment call, not the coordination work surrounding it. **Customer communication is never a separate step.** Notifying the customer is part of the same automated process, not an afterthought. The customer receives a timely, professional update without the dispatcher having to draft or send anything manually. **The interface is flexible; the process is consistent.** Whether the dispatcher is working in Teams or in the Dispatch interface, the same structured process applies, the same context, the same ranked options, the same automated execution after confirmation. This consistency reduces reliance on individual dispatcher experience and ensures exceptions are handled the same way across teams and regions. **Feedback improves future recommendations.** The thumbs up/down mechanism is not just a nicety, it creates a structured signal that helps the Dispatcher Assistant refine how it ranks and presents options over time. # FAQ ### Capabilities & functionality **Q: What does the Supplier Invoicing Manager do?** A: The Supplier Invoicing Manager is a Digital Worker that automates supplier invoice intake, validation, and exception routing for accounts payable teams. It ingests invoices received by email, parses and extracts the invoice data, validates each invoice against the corresponding purchase order and goods receipt, and either auto-approves the invoice or routes it for human review based on the outcome of that validation. ERP records are updated automatically once an invoice is approved. **Q: What is three-way matching and how does the Digital Worker perform it?** A: Three-way matching is the process of comparing an invoice against both the originating purchase order and the goods receipt to confirm that what was invoiced matches what was ordered and received. The Supplier Invoicing Manager executes this comparison automatically for every invoice it processes. It applies configurable tolerance logic to determine whether any differences fall within acceptable thresholds or require escalation. **Q: How does the Digital Worker handle invoices that do not match the PO or receipt?** A: When the Digital Worker detects a discrepancy that falls outside the defined tolerance thresholds, it flags the mismatch and routes the invoice to an AP team member for review. The reviewer receives the relevant details and context needed to assess the situation. Once they provide a decision, the Digital Worker takes follow-up action, including emailing the supplier to request a correction if needed. **Q: What happens after a valid invoice is approved?** A: Valid invoices are auto-approved without requiring manual touchpoints. The ERP is updated immediately to reflect the approval, and a copy of the invoice is attached to the record. The entire process runs without human intervention for invoices that match within tolerance. **Q: Can the Digital Worker handle service charges and line-item variances?** A: Yes. Charge and variance interpretation is one of the Digital Worker's core capabilities. It classifies variances across line items and determines whether each can be resolved within configured thresholds or requires escalation for review. This prevents unclear charges from stalling the approval process or slipping through unchecked. ### Control & Collaboration **Q: Does a human review every invoice?** A: No. Invoices that match within configured tolerance thresholds are auto-approved without any manual review. Human involvement is reserved for genuine exceptions, specifically invoices where discrepancies, unclear charges, or variances cannot be resolved automatically. This keeps your AP team focused on decisions that require judgment rather than routine processing. **Q: How does the Digital Worker involve AP team members when an exception occurs?** A: When an invoice requires human review, the Digital Worker routes it to the appropriate team member with the relevant details surfaced so they can act quickly and with full context. The reviewer assesses the situation and provides their feedback, after which the Digital Worker handles any required follow-up. **Q: What information does the reviewer receive when an invoice is escalated?** A: Escalated invoices are accompanied by the details needed to understand the discrepancy, including the invoice data, the relevant purchase order and receipt records, and the nature of the mismatch or variance. Reviewers can make informed decisions without having to manually locate supporting documents. **Q: How does the Digital Worker communicate with suppliers?** A: After a reviewer assesses a discrepancy and provides feedback, the Digital Worker sends an email directly to the supplier to flag the issue and request a correction. This removes the need for manual inbox monitoring or back-and-forth coordination by the AP team. ### Integration & Technology **Q: What systems does the Supplier Invoicing Manager integrate with?** A: The Supplier Invoicing Manager integrates with email platforms, enterprise applications including ERP and CRM systems, collaboration tools, and document platforms. This allows it to receive invoices from existing inbound channels and update records in the systems your team already uses. **Q: How does the Digital Worker receive invoices?** A: Invoices are captured from inbound email channels. The Digital Worker monitors these channels, ingests invoices as they arrive, and prepares them for processing automatically. No manual upload or intervention is required to initiate the process. **Q: How does it update the ERP after processing?** A: Once an invoice is approved, the Supplier Invoicing Manager updates the invoice status in the ERP directly. This keeps invoice progress and outcomes visible in your system of record without requiring manual data entry by the AP team. **Q: What collaboration and document platforms are supported?** A: The Digital Worker supports integration with collaboration platforms including Slack and Microsoft Teams, and document platforms including IFS and Google Drive. Refer to your implementation documentation for the full list of supported connectors available in your environment. ### Security & Reliability **Q: How is audit traceability maintained?** A: Every decision the Digital Worker makes is traceable. Discrepancies, the context in which they were detected, and how they were resolved are all recorded with full traceability. This means AP teams and auditors can review the rationale behind any approval or escalation after the fact. **Q: What prevents duplicate payments or overpayment?** A: The Digital Worker enforces consistent matching rules and applies idempotency controls to prevent invoices from being processed more than once. Combined with three-way matching against PO and receipt records, this significantly reduces the risk of duplicate payments and overpayment. **Q: How are exceptions handled consistently?** A: Exception routing follows defined tolerance and matching rules configured for your environment. Every invoice is evaluated against the same criteria, regardless of volume or who is processing the queue. Consistent rules also make it easier to audit exception decisions and identify patterns over time. ### Customization & Performance **Q: Can matching rules and tolerance thresholds be configured?** A: Yes. The Supplier Invoicing Manager uses configurable tolerance logic for three-way matching and auto-approval decisions. This allows organizations to define the thresholds that reflect their own procurement and finance policies, rather than applying fixed rules that may not suit their business. **Q: Can the Digital Worker be adjusted to route specific exception types differently?** A: Exception routing is governed by the rules configured in your environment. Invoices that fall outside tolerance thresholds are escalated with decision rationale, allowing your team to define how different types of discrepancies should be handled and by whom. **Q: What agentic skills does the Supplier Invoicing Manager use?** A: The Supplier Invoicing Manager is built on four agentic skills: Invoice Intake & Parsing, 3-Way Match, Charge & Variance Interpretation, and Exception Handling. Each skill handles a distinct part of the invoice processing lifecycle, and together they cover the full path from invoice receipt through to ERP update or supplier follow-up. # WIP - Case studies See how our customers are using this Digital Worker to transform their operations. # Job Intake Manager Handling inbound job requests takes focus, but repetitive intake work shouldn't slow teams down. This knowledge base guides you through using the Job Intake Manager, from initial setup to handling job intake efficiently in daily operations. ### Jump right in

		Cover image
Watch & learn	See this Digital Worker in action.	create an image for watch and learn.png	Watch & learn
Core concepts	Essential context for understanding how it all works.	create an image for core concepts_.png	Core concepts
FAQ	Quick answers to common questions.	create an image for frequently asked questions_.png	FAQ
How-to guides	Practical, step-by-step guidance across a range of tasks	create a tile image representing digital worker gu (2).png	How-to guides

		Cover image
Fundamentals	Learn the full scope of what's possible	ChatGPT Image Apr 20, 2026, 06_56_23 PM.png	Fundamentals
Architecture & capabilities	Discover the components and integrations	ChatGPT Image Apr 20, 2026, 07_00_55 PM.png	Architecture & capabilities
Real-world scenarios	Practical examples of the platform in action across common business use cases.	ChatGPT Image Apr 20, 2026, 07_04_03 PM.png	Real-world scenarios

# Fundamentals ## Overview 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. 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. ## Key Benefits **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. **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. **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. **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. **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. ## The Challenge It Solves 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. 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. ## Before and After ### Before Before the Job Intake Manager, turning a job email into a service request requires manual effort at every stage: {% 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 {% endstep %} {% step %} Attach the original email and any files, if there’s time to do so {% endstep %} {% endstepper %} This process is slow, inconsistent across the different email formats each client uses, and prone to dropped detail under time pressure. ### After With the Job Intake Manager, the same process runs automatically: {% stepper %} {% step %} Detect and deduplicate the email, matching it against a composite fingerprint of client reference, site and asset {% endstep %} {% step %} Parse the headers, body and every attachment, identifying the originating platform and the end client {% endstep %} {% step %} Resolve the customer, asset, location, service and service organization from what was extracted {% endstep %} {% step %} Extract and resolve the SLA commitment, applying the configured precedence rule if body and attachment disagree {% endstep %} {% step %} Create the request, releasing it automatically when every mandatory value resolved with confidence, or holding it for review when it did not {% endstep %} {% step %} Attach the source email and every file, and add a further scope for each additional asset the email named {% endstep %} {% endstepper %} ## How It Works The Job Intake Manager follows a single core workflow: Parse, Resolve, Create, Attach. **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. **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. **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. **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. 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. ## What Triggers the Job Intake Manager The Job Intake Manager responds to inbound job emails forwarded from client CAFM and helpdesk platforms, and handles the variation across them: **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. **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. **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. **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. **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. **Duplicate orders:** the same order re-sent with a new message identifier, which resolves to the existing request rather than creating a second one. **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. # Architecture & capabilities ## Overview The Job Intake Manager is built on four agentic skills that together carry an inbound job email from arrival to a created and released service request. It operates autonomously with an exception queue rather than a per-email approval step, running the same Parse, Resolve, Create, Attach workflow for every supported email pattern. This article covers the core skills, the full intake workflow, integration points, and how the system determines when to act autonomously versus when to escalate to a coordinator. ## Agentic Skills #### Email & Attachment Parsing Parses the headers, plain-text body, RTF body and the text of every attachment on an inbound email, walking quoted headers where needed to identify the originating platform and the end client. This skill handles attachment variation directly, including PDFs with an empty message body, attachments declaring an incorrect or generic MIME type, and orders split across the body and multiple attachment types. It also performs the first deduplication pass, matching the email against a composite fingerprint of client reference, site and asset before parsing continues. #### Customer, Asset & Service Resolution Resolves the customer from the end client named inside the forwarded mail, the asset from the client-reference cross-reference narrowed by location and model, the location and address by deriving them from the resolved asset rather than string-matching free text, and the service from the asset-scoped catalog. This skill also resolves the service organization and delivery unit from the applicable selection rule, falling back to the client’s default organization when no rule matches. A no-match on customer or service blocks request creation. A no-match on asset downgrades and flags the request rather than blocking it. #### SLA Extraction & Precedence Extracts SLA commitments across the six encodings that appear in client email: absolute datetime, hours duration, a “before” deadline, a priority code with the duration embedded in the label, a defect code decoded in a secondary attachment, and cases where no SLA information is present at all. This skill applies a per-client mapping from priority and defect codes to duration and fulfilment event, parses each encoding form, and applies an explicit, configurable precedence rule when the email body and an attachment disagree. Extracted datetimes are converted into the operating time zone of the resolved service organization, after the resolution chain rather than at extraction, since organization is not yet known when the email is first parsed. #### Request Creation & Exception Handling Builds and posts the service request, setting automatic release only when every mandatory value has resolved deterministically and nothing has been flagged. It stores the returned request identifier, attaches the source email and every file, and adds a further scope for every additional asset the email named, reusing the first scope’s service after revalidating it against the new asset. This skill also owns idempotency: a repeated request carrying an external identifier already in use is rejected by IFS Cloud, and the worker reads that rejection as confirmation the request already exists rather than as a failure to retry. ## Intake Workflow The following table outlines the full intake process from email arrival through to request creation. | Stage | What the System Does | Action / Output | Channel | | ---------------- | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | ----------------- | | Deduplication | Matches the email against a composite fingerprint of client reference, site and asset | Skips processing if unchanged, or proceeds if new | Email | | Parsing | Reads headers, body and every attachment, identifies originating platform and end client | Candidate values extracted for customer, asset, service, SLA and reference | Email | | Resolution | Resolves customer, asset, location, service and service organization from the extracted values | Confirmed or flagged matches, with candidate sets and scores recorded | IFS Cloud | | SLA Extraction | Parses the SLA encoding present, applies precedence rule if body and attachment disagree | Duration or absolute deadline resolved and converted to the organization’s time zone | IFS Cloud | | Confidence Gate | Evaluates whether every mandatory value resolved deterministically with nothing flagged | Sets automatic release true or false | IFS Cloud | | Request Creation | Posts the request, attaches source materials, adds a scope for each further asset named | Request created, released or held, notification sent | IFS Cloud / Teams | Exception paths: When no customer match, no service match, or a credit block is found, the worker holds and escalates without creating a request, since creating a request on the wrong customer costs more than not creating one. When multiple asset or location candidates exist, the worker takes the highest-scoring candidate, creates the request, and flags it for override. When a request-creation call fails, it queues for a bounded retry and then escalates, with every retry carrying the same external identifier so a retry cannot produce a duplicate. ## Integration Points **IFS Cloud:** The primary integration. Read-mostly, writing in three places only: request creation, the chosen attachment route, and the add-scope sequence for a second or later asset. Adding a scope is the only case in which the worker touches a request that already exists, and it only ever adds: it never edits or removes an existing scope. No identifier is ever composed by the worker, every identifier it sends came from a prior API response. **Microsoft Teams:** Exception alerts and the review digest. A blocking exception raises an alert to the intake coordinator with the email, what failed, and the candidates considered. Non-blocking flags and overrides ride a batched digest on a configurable cadence, grouped by client. **Loops data store**: System of record for messages, attachments, extractions, candidate sets, decisions, payloads, results and the full audit trail. ## Human-in-the-Loop Design The Job Intake Manager is designed so that clean, confidently-resolved jobs create and release automatically, and coordinator judgment is reserved for genuine exceptions. The system creates and releases automatically when: * Every mandatory value, customer, asset, location, service and SLA, resolved deterministically * No candidate ambiguity was flagged during resolution * The SLA extraction succeeded without a body-versus-attachment conflict, or the conflict was resolved by the configured precedence rule without triggering the confidence gate Coordinator review is required when: * No customer match, no service match, or a credit block is found, blocking creation entirely * Multiple asset or location candidates exist, or the address cannot be derived from the asset * Body and attachment disagree on the SLA in a way that fails the confidence gate * The email is portal-gated, with the job detail behind an authenticated link rather than in the message When escalating, the system surfaces the reason, the candidates considered, the scores, and the extracted values, so an override is a single decision rather than a re-read of the original email. ## Feedback and Continuous Improvement Coordinators correct the customer, site, asset or service on an exception. That correction is applied to the request and offered as a new entry in the client’s alias or cross-reference table, so the same email pattern resolves itself automatically the next time it arrives. No-match and false-match rates are tracked per client and per field to calibrate matching thresholds. A high override rate on a single client points at that client’s mapping tables rather than at the underlying model. Every exception, recommendation, decision and outcome is logged with full traceability, providing the evidence base for ongoing accuracy review and threshold tuning. # Real-world scenarios ## Overview 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. ### Scenario: Clean Job, No Human Touch 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. 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. #### Step 1: Customer Resolved by Name The Job Intake Manager parses the email and resolves the customer from the end client name carried in the forwarded mail. #### Step 2: Asset Resolved from the Tag 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. #### Step 3: Service Resolved from the Asset-Scoped Catalog With the asset resolved, the service resolves from the catalog scoped to that specific asset, rather than from a generic service list. #### Step 4: SLA Commitments Extracted 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. #### Step 5: Confidence Gate Passes Every mandatory value has resolved deterministically and nothing has been flagged. The confidence gate passes. #### Step 6: Request Created and Released 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. 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. ### Scenario: Body and Attachment Disagree on the SLA 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. #### Step 1: All Three SLA Signals Extracted 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. #### Step 2: Configured Precedence Rule Applied 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. #### Step 3: Confidence Gate Fails Because a genuine conflict was detected between the body and the attachment, the flag fails the confidence gate. Automatic release does not proceed. #### Step 4: Request Created, Held at New The request is still created, carrying every other resolved value, but it sits at New rather than being released automatically. #### Step 5: Coordinator Confirms and Releases A coordinator reviews the flagged conflict, with the candidates and the extracted values already surfaced, confirms the deadline, and releases the request. **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. ## What These Scenarios Illustrate 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. 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. 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.” 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. 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. # 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. # Case studies See how our customers are using this Digital Worker to transform their operations. # Job Rate Manager Applying job rate rules takes precision, but repetitive classification work shouldn't slow teams down. This knowledge base guides you through using the Job Rate Manager, from initial setup to handling job rate decisions efficiently in daily operations. ### Jump right in

		Cover image
Watch & learn	See this Digital Worker in action.	create an image for watch and learn.png	Watch & learn
Core concepts	Essential context for understanding how it all works.	create an image for core concepts_.png	Core concepts
FAQ	Quick answers to common questions.	create an image for frequently asked questions_.png	FAQ
How-to guides	Practical, step-by-step guidance across a range of tasks	create a tile image representing digital worker gu (2).png	How-to guides

		Cover image
Fundamentals	Learn the full scope of what's possible	ChatGPT Image Apr 20, 2026, 06_56_23 PM.png	Fundamentals
Architecture & capabilities	Discover the components and integrations	ChatGPT Image Apr 20, 2026, 07_00_55 PM.png	Architecture & capabilities
Real-world scenarios	Practical examples of the platform in action across common business use cases.	ChatGPT Image Apr 20, 2026, 07_04_03 PM.png	Real-world scenarios

# Fundamentals ## Overview The Job Rate Manager is an AI-powered Digital Worker that turns complex job rate rules into consistent, automated decisions for payroll, project, and operations teams. Triggered by a work order or project transaction, it enriches the time entry with the right master data and rule sets, classifies the resource and the time, applies the applicable labor, union, travel, equipment, and cost rules, and recommends the correct time and cost types before updating transactions in IFS Cloud, with human-in-the-loop review where needed. The Job Rate Manager never classifies on its own judgment. Classification comes from the rule engine first, and the update to IFS Cloud follows only once that classification is set. That order is what makes the output safe to hand to payroll. ## Key Benefits **Faster rate creation:** Rates are determined in minutes rather than manual cycles, replacing spreadsheet-based calculation with an automated decision. **Higher accuracy:** Complex rule sets, labor, union, travel, equipment, and cost rules, are applied consistently every time, regardless of who entered the underlying data. **Reduced dependency:** Less reliance on tribal knowledge and the handful of subject matter experts who previously carried the exceptions in their heads. **Compliance ready:** Supports collective bargaining agreements, apprenticeship tiers, and FUTA/SUTA thresholds, with every rate decision traceable and auditable. **Payroll ready:** Produces clean job cost details ready for export to ADP and other payroll systems. ## The Challenge It Solves Job rate determination in construction and field-heavy operations draws on many rule sources at once: customer-specific agreements, labor and union rules, equipment and travel costs, and cost rules that change frequently. That knowledge often sits with only a few individuals who know the exceptions by heart. Determining rates by hand against all of these sources is slow and inconsistent, which leads to revenue leakage, audit challenges, and heavy dependence on tribal knowledge. When the person who understands a particular union agreement’s quirks is unavailable, the whole team stalls. ## Before and After #### Before Before the Job Rate Manager, determining the correct rate for a reported time entry requires manual effort at every stage: {% stepper %} {% step %} Identify which customer agreement, union rule, or labor classification governs the employee and the job {% endstep %} {% step %} Look up the applicable geography-specific rules, calendars, and rate agreements by hand {% endstep %} {% step %} Classify the reported time against overtime and double-time thresholds, often relying on one person’s memory of how a particular agreement works {% endstep %} {% step %} Manually split or correct time entries across the right pay categories {% endstep %} {% step %} Re-key or correct payroll and billing lines when a rate was misapplied or based on an outdated rule {% endstep %} {% endstepper %} #### After With the Job Rate Manager, the same process runs automatically: {% stepper %} {% step %} A work order or project transaction triggers the Job Rate Manager the moment it comes in {% endstep %} {% step %} The time entry is enriched with employee, labor classification, rate agreement, union, and job cost data {% endstep %} {% step %} Geography-specific rules, calendars, and the applicable rate agreements are loaded {% endstep %} {% step %} The resource and the time are classified against the correct thresholds for regular, overtime, and double-time hours {% endstep %} {% step %} Labor, union, travel, equipment, fringe, and burden cost rules are applied, and hours are split across the correct pay categories {% endstep %} {% step %} The correct time and cost types are recommended, and the corresponding transactions are updated or created in IFS Cloud, with human-in-the-loop approval where needed {% endstep %} {% endstepper %} ## How It Works The Job Rate Manager follows a consistent eight-step sequence for every transaction. **Capture time entries:** The worker triggers automatically on work order and project transactions. **Enrich context:** It pulls employee, labor classification, rate agreement, union, and job cost data relevant to the entry. **Prepare rule sets:** Geography-specific rules, calendars, and the applicable rate agreements are loaded. **Classify resource and time:** The worker determines the resource group, labor classification, and how the reported hours split across regular, overtime, and double-time thresholds. **Apply rate rules:** Labor, union, travel, equipment, fringe, and burden cost rules are run against the classified time. **Structure time:** Hours are split into regular, overtime, and double-time categories by threshold. **Recommend types:** The worker suggests the correct time and cost types, logged for reuse on similar entries. **Update and log:** Transactions are split, created, or updated in IFS Cloud, with human-in-the-loop approval where the worker’s confidence requires it. ## What Triggers the Job Rate Manager **A work order or project transaction:** The worker activates the moment a new transaction of either type comes in. **A time entry requiring classification:** Any reported time that needs to be evaluated against labor, union, travel, equipment, or cost rules to determine the correct pay category. **Thresholds and premiums:** Hours that cross a regular, overtime, or double-time threshold, or that fall on a day governed by a premium rule, such as a registered public holiday. **Missing or conflicting information:** Where required information is missing or rules conflict, the transaction is flagged and routed to a person rather than finalized on an assumption. # Architecture & capabilities ## Overview The Job Rate Manager is built on four agentic skills that together take a work order or project transaction from intake through to an updated IFS Cloud record: Work Transaction Intake, Job Classification & Rule Evaluation, Time Categorization, and Exception Handling. This article covers those skills, the workflow they share, integration points, and how the system keeps a person in the loop when information is missing or rules conflict. ## Agentic Skills #### Work Transaction Intake Captures work order and project transaction details, including employee information, job type, location, and the labor information required to determine a rate. This skill extracts the transaction details that every downstream skill depends on, and is what triggers the Job Rate Manager the moment a new transaction comes in. #### Job Classification & Rule Evaluation Identifies the applicable union agreements, equipment, shift, and labor classifications for the transaction, and validates the labor conditions against them. This skill matches the applicable customer, location, and job rules, and loads the geography-specific rules, calendars, and rate agreements that govern the entry. #### Time Categorization Applies business rules, premiums, overtime, allowances, and customer-specific conditions to categorize time into the correct time type. This skill splits reported hours into regular, overtime, and double-time categories by threshold, and recommends the correct time and cost types. #### Exception Handling Identifies missing information, conflicting rules, or ambiguous scenarios that require human review. Nothing is finalized without review when a case is flagged: the worker surfaces what’s missing or conflicting and routes the case to a person rather than resolving it on an assumption. #### Job Rate Workflow The following table outlines the process from transaction intake through to a billing and payroll update. | Stage | What the System Does | Action / Output | Channel | | ------------------------- | ----------------------------------------------------------- | --------------------------- | ------------ | | Work Request Intake | Extracts work details, employee, equipment, and job type | Required inputs validated | ERP | | Rule Identification | Matches applicable union, customer, location, and job rules | Correct rule set determined | ERP | | Labor Time Classification | Applies premiums, overtime, allowances, and classifications | Time types calculated | Rules Engine | | Exception Validation | Detects missing or conflicting information | Exceptions escalated | Teams | | Rate Confirmation | Validates the calculation | Audit trail generated | ERP | | Billing & Payroll Update | Prepares final outputs | Payroll and billing updated | ERP | ## Integration Points **IFS Cloud:** The primary system of record. The Job Rate Manager reads work order and project transaction details and writes back by splitting, creating, or updating time and cost transactions once classification and rule evaluation are complete. **Rules Engine:** Applies labor, union, travel, equipment, fringe, and burden cost rules against the classified time, and is the authority classification is drawn from before any update is made. **Collaboration (Microsoft Teams):** Used to escalate exceptions, missing information, and conflicting rules to a person for review. **Payroll systems:** Job cost details are prepared in a form ready for export to ADP and other payroll systems. ## Human-in-the-Loop Design The Job Rate Manager is designed so that classification and rule application run automatically, while genuine ambiguity is routed to a person rather than resolved on a guess. The system flags for review when: * Information required to determine a rate is missing from the transaction * Applicable rules conflict with one another * A scenario is ambiguous enough that finalizing it without review carries risk The system proceeds automatically when: * The applicable agreement, classification, and rule set can be determined cleanly from the enriched transaction data * Hours can be classified against regular, overtime, and double-time thresholds without contradiction In every case, classification comes from the rule engine first, and the update to IFS Cloud follows only once that classification is set. This ordering is what makes the output safe to hand to payroll: nothing is written based on the worker’s own judgment ahead of the rules that govern it. ## Feedback and Continuous Improvement Because rate determination runs on a rule engine rather than case-by-case judgment, the same agreement and the same set of facts produce the same classification every time, regardless of who entered the original data. Every rate decision generates an audit trail as part of rate confirmation, giving payroll and finance teams a consistent, traceable record of how each transaction was classified and why, rather than a rate that depended on which person happened to calculate it. # Real-world scenarios ## Overview This article walks through one employee’s reported time across four days of the same week, showing how the Job Rate Manager applies the same agreement differently depending on the day, the hours already worked that week, and the type of day involved. ### Scenario: One Employee, One Week Under the Same Agreement #### Step 1: Agreement Established The Job Rate Manager first establishes which agreement governs this employee. Every decision that follows traces back to that agreement. #### Step 2: Thursday, Fourteen Hours Split Three Ways Thursday, fourteen hours land on a single line, entered as one entry, because that’s how a long day typically gets recorded. The Job Rate Manager classifies the time: eight hours regular, a daily cap, four hours overtime, and two hours double time, three pay categories from one entry. It updates one line and creates two. The original entry is corrected to eight hours regular, and two new lines are written beside it for overtime and double time. Classification comes from the rule engine first, and the update follows; that order is what makes the output safe to hand to payroll. #### Step 3: Friday, Nine Hours, a Different Result Friday, nine hours are reported: six hours regular, three hours overtime. Thursday’s cap was eight regular hours. Friday, under the same agreement, the same employee gets six, because this employee has nearly used up their regular hours for the week. Only six remain before the weekly cap, so six of Friday’s hours are classified as regular and the rest roll into overtime, regardless of how the hours were originally entered. The Job Rate Manager isn’t applying one flat rule to every day. It’s evaluating this employee’s actual position in the agreement on that date, which is the difference between a calculator and a rule engine. #### Step 4: Saturday, No Split Needed Saturday, six hours are reported, all of it overtime. No split is needed here, so the Job Rate Manager doesn’t create one. It corrects the type on the existing line and stops. #### Step 5: Sunday, a Full Day of Double Time Sunday, another six hours come back as double time for the entire day, not just the hours past a threshold. Registered public holidays follow the same pattern: Saturday overtime, Sunday double time. **Result:** Across four days under the same agreement, the same employee’s hours are classified four different ways, each correct for that specific day and that specific point in the week. Every union agreement carries quirks like these, and the Job Rate Manager applies them the same way regardless of who entered the data. ## What This Scenario Illustrates The agreement governs every decision that follows. Establishing which agreement applies happens first, and every classification made afterward traces back to it. Classification comes before the update, always. The Job Rate Manager never classifies on its own judgment; the rule engine sets the classification, and only then does the update to IFS Cloud follow. That order is what makes the output safe to hand to payroll. The same rule set produces different results depending on position in the week. Thursday’s eight-hour regular cap and Friday’s six-hour regular cap come from the same agreement applied to the same employee. The difference is how many regular hours were already used, which is the difference between a calculator and a rule engine. No unnecessary lines are created. When a day’s hours don’t need splitting, like Saturday’s straight overtime, the worker corrects the existing line and stops rather than generating extra entries. Premium days apply to the whole day, not just the hours past a threshold. A double-time Sunday, or a registered public holiday, is treated as double time from the first hour, not only the hours that would otherwise exceed a cap. Consistency holds regardless of who entered the data. Every union agreement carries its own quirks, and the Job Rate Manager applies them the same way every time, whether the underlying entry was clean or came in as one long line for a fourteen-hour day. # FAQ ## Capabilities & functionality **Q: What does the Job Rate Manager do?** A: The Job Rate Manager is a Digital Worker that turns complex job rate rules into consistent, automated decisions for payroll, project, and operations teams. It enriches each work order or project transaction with the right master data, classifies the resource and time, applies the applicable labor, union, travel, equipment, and cost rules, and recommends the correct time and cost types before updating transactions in IFS Cloud. **Q: What rule sources does the Job Rate Manager draw on?** A: Customer-specific agreements, labor and union rules, equipment and travel costs, geography-specific rules and calendars, and cost rules that change frequently, all applied together against each reported time entry. **Q: How does the Job Rate Manager split a single time entry into multiple pay categories?** A: It classifies the reported hours against the applicable thresholds, regular, overtime, and double-time, and updates the original entry to reflect the first category while creating new lines for any additional categories the hours fall into. A fourteen-hour day, for example, can become one corrected line and two new ones. **Q: Does the same agreement always produce the same split for the same number of hours?** A: No. The Job Rate Manager evaluates an employee’s actual position in the agreement on that date, not just the number of hours reported. The same nine-hour day can classify differently depending on how many regular hours the employee has already used that week. **Q: What happens when no split is needed?** A: The Job Rate Manager corrects the type on the existing line and stops, rather than creating unnecessary additional entries. ## Control & Collaboration **Q: Does the Job Rate Manager ever classify time on its own judgment?** A: No. Classification always comes from the rule engine first, and the update to IFS Cloud follows only once that classification is set. This order is what makes the output safe to hand to payroll. **Q: What happens when information is missing or rules conflict?** A: The transaction is flagged and routed to a person for review. Nothing finalizes without review when a case is ambiguous. **Q: How are exceptions delivered to the person who needs to review them?** A: Exceptions are escalated through Microsoft Teams, surfacing what’s missing or conflicting so the reviewer can resolve it. **Q: Who reviews an exception the Job Rate Manager raises?** A: The relevant payroll, project, or operations team member configured to receive that escalation, who resolves the missing information or conflicting rule before the transaction proceeds. ## Integration & Technology **Q: What systems does the Job Rate Manager integrate with?** A: It integrates with IFS Cloud as the primary system of record, reading work order and project transaction details and writing back updated, split, or newly created time and cost transactions. It uses a rules engine to apply labor, union, travel, equipment, fringe, and burden cost rules, and Microsoft Teams for exception escalation. **Q: What triggers the Job Rate Manager to process a transaction?** A: A work order or project transaction. The worker activates the moment a new transaction of either type comes in. **Q: Does the Job Rate Manager connect to payroll systems?** A: It prepares clean job cost details in a form ready for export to ADP and other payroll systems. **Q: How does the Job Rate Manager know which rules apply to a given transaction?** A: It enriches the transaction with employee, labor classification, rate agreement, union, and job cost data, then loads the geography-specific rules, calendars, and applicable rate agreements that govern that entry. ## Security & Reliability **Q: How is a rate decision made auditable?** A: Every rate decision generates an audit trail as part of rate confirmation, giving payroll and finance teams a consistent, traceable record of how each transaction was classified and why. **Q: Is classification consistent regardless of who entered the original data?** A: Yes. Because rate determination runs on a rule engine rather than case-by-case judgment, the same agreement and the same set of facts produce the same classification every time. **Q: What stops an ambiguous transaction from being finalized incorrectly?** A: Exception handling identifies missing information, conflicting rules, or ambiguous scenarios and routes them to a person. Nothing finalizes without review in those cases. **Q: Can the Job Rate Manager apply the wrong rule without anyone noticing?** A: Rule identification matches the applicable union, customer, location, and job rules before classification runs, and rate confirmation validates the calculation and generates an audit trail, so the basis for every decision is visible and checkable. ## Customization & Performance **Q: Does the Job Rate Manager support multiple union agreements and locations?** A: Yes. It is designed for organizations working with multiple labor agreements, a large number of job codes, and different pay rates by location, loading the geography-specific rules and calendars relevant to each transaction. **Q: How does the Job Rate Manager handle premium days like public holidays?** A: A premium day, such as a registered public holiday, is classified as the applicable premium type, for example double time, for the whole day rather than only the hours that would otherwise exceed a threshold. **Q: How fast is rate determination compared to a manual process?** A: Rates are determined in minutes rather than manual cycles, replacing spreadsheet-based calculation and reliance on a small number of experienced staff. **Q: What are the four core skills behind the Job Rate Manager?** A: Work Transaction Intake, Job Classification & Rule Evaluation, Time Categorization, and Exception Handling. Together, they take a transaction from intake through to a rate decision that’s safe to hand to payroll. # Case studies See how our customers are using this Digital Worker to transform their operations. # Knowledge Manager Managing organizational knowledge takes diligence, but tracking and retrieving information shouldn't slow teams down. This knowledge base guides you through using the Knowledge Manager to organize and surface the right information in daily operations. ### Jump right in

		Cover image
Watch & learn	See this Digital Worker in action.	create an image for watch and learn.png	Watch & learn
Core concepts	Essential context for understanding how it all works.	create an image for core concepts_.png	Core concepts
FAQ	Quick answers to common questions.	create an image for frequently asked questions_.png	FAQ
How-to guides	Practical, step-by-step guidance across a range of tasks	create a tile image representing digital worker gu (2).png	How-to guides

		Cover image
Fundamentals	Learn the full scope of what's possible	ChatGPT Image Apr 20, 2026, 06_56_23 PM.png	Fundamentals
Architecture & capabilities	Discover the components and integrations	ChatGPT Image Apr 20, 2026, 07_00_55 PM.png	Architecture & capabilities
Real-world scenarios	Practical examples of the platform in action across common business use cases.	ChatGPT Image Apr 20, 2026, 07_04_03 PM.png	Real-world scenarios

# Fundamentals ## Overview The Knowledge Manager is an AI-powered Digital Worker designed to put trusted, relevant answers directly in the flow of work for service and operations teams. It interprets questions in natural language, searches across every connected knowledge source simultaneously, and returns context-specific guidance with citations, so teams can act quickly and with confidence rather than spending time searching, second-guessing, or escalating unnecessarily. Beyond retrieval, the Knowledge Manager continuously monitors interactions to identify missing, low-confidence, or conflicting knowledge. Where gaps are detected, it flags them automatically and supports structured content creation or enrichment, so the knowledge base evolves based on actual field demand rather than static documentation cycles. ## Key Benefits **Answers at the point of need:** Guidance is delivered directly in Microsoft Teams or other configured interfaces, no system switching, no manual document browsing, no searching across multiple tools. **Context-specific, not generic:** Responses are tailored to the specific asset, configuration, and operational scenario rather than returning broad documentation that may or may not apply. **Trusted results with citations:** Every response includes source links so users know exactly where the guidance comes from and can assess its authority. Confidence indicators help users understand how reliable the answer is. **Continuous knowledge improvement:** Every interaction generates signals about what knowledge is working, what is missing, and what needs review. Gaps are flagged automatically and draft knowledge can be generated for human approval, ensuring the knowledge base improves over time. **Consistent outcomes across teams:** All users receive guidance drawn from the same validated sources, reducing the inconsistency that comes from relying on individual expertise or informal knowledge sharing. **Governed by design:** Role-based visibility, escalation paths, and full auditability ensure that human oversight is maintained where it matters, particularly in high-compliance or safety-sensitive environments. ## The Challenge It Solves Accessing knowledge across service operations is fragmented, inconsistent, and time-consuming. Engineers and agents typically search across multiple systems, manuals, SharePoint, ERP records, ticket histories, PDFs, often relying on incomplete or outdated information. Critical knowledge gaps go unidentified, leading to repeated issues, slower resolutions, and increased operational risk. In practice, this looks like engineers spending 15 to 20 minutes per job on information lookup, searching 4 to 6 systems before finding a relevant answer, encountering conflicting guidance that applies to slightly different configurations, escalating to senior colleagues when documentation is unclear, and applying best-guess resolutions that may not fully resolve the issue. Knowledge from resolved jobs is rarely captured in a reusable form, so the same questions surface repeatedly. ## Before and After ### Before Before the Knowledge Manager, resolving a field issue involves manual searching at every stage: {% stepper %} {% step %} Search across multiple systems, manuals, SharePoint, tickets, emails {% endstep %} {% step %} Interpret incomplete or unclear problem context {% endstep %} {% step %} Review multiple documents and sources {% endstep %} {% step %} Compare conflicting or generic guidance {% endstep %} {% step %} Ask colleagues or escalate for support {% endstep %} {% step %} Apply a best-guess resolution {% endstep %} {% step %} Leave knowledge uncaptured or buried in free-text notes {% endstep %} {% endstepper %} The result is high search effort, inconsistent answers, slow resolution times, and knowledge that never gets reused. ### After With the Knowledge Manager, the same process runs in four steps: {% stepper %} {% step %} Interpret the query, context, and asset configuration automatically {% endstep %} {% step %} Retrieve, validate, and rank knowledge across all sources simultaneously {% endstep %} {% step %} Deliver precise guidance and surface cited sources in a single response {% endstep %} {% step %} Capture feedback and flag gaps for continuous improvement {% endstep %} {% endstepper %} ## How It Works **When a question comes in:** the Knowledge Manager forms a working hypothesis before retrieving any information, interpreting the intent behind the query, identifying the asset type and configuration, assessing urgency and operational risk, and determining which knowledge sources are most relevant. It then searches all connected sources simultaneously and returns ranked results with confidence signals and citations. **If the query lacks sufficient context for a high-confidence response:** the system asks a targeted follow-up question rather than returning generic guidance. When the right answer exists, it comes back as specific, actionable steps, not a document dump. **Every interaction is tracked:** confidence levels, follow-up questions, resolution outcomes, and recurring patterns are all monitored in the background. This continuous monitoring powers the knowledge gap detection capability, ensuring that what engineers keep asking but can't find reliable answers to is surfaced for content review and enrichment. **When a job is resolved:** the Knowledge Manager can convert the interaction and outcome into structured knowledge, drafted for human review and, once approved, published back into the knowledge base for future use. ## Knowledge Orchestration The Knowledge Manager operates across five continuous functions: **Seek:** A question is raised from the field or support desk. The Knowledge Manager captures context at source, asset ID, configuration, fault pattern, location, user role, risk level, and enriches the query before retrieval begins. **Surface:** Unified search runs across structured and unstructured sources simultaneously, manuals, historical service logs, prior resolutions, bulletins, tickets, and safety updates. Results are ranked by reliability and contextual match. Generic or unsafe guidance is suppressed. **Monitor:** The system continuously watches for changes that invalidate, improve, or create knowledge, source updates such as manual revisions and safety notices, changes in circumstances such as asset upgrades and firmware changes, and field outcomes such as confirmed fixes, rejected workarounds, and repeat visits. **Strengthen:** Gaps, conflicts, and low-confidence guidance are detected automatically. The system highlights the difference between what teams keep asking and what the knowledge base can actually answer, flagging missing configuration steps, recurring searches, and unreliable sources for review. **Generate:** Where knowledge is missing or repeatedly requested, the Knowledge Manager supports structured creation, drafting service log updates, proposing new content, generating configuration-specific guidance, routing everything through a human approval process before it is published back into the knowledge base. # Architecture & capabilities ## Overview The Knowledge Manager is built on five agentic skills that work together to deliver contextual knowledge retrieval and continuous knowledge improvement. This article covers the core skills, how the system is deployed and accessed, integration points, and how human oversight is maintained throughout. ## Agentic Skills #### Conversational Query Interpretation Understands user intent and context from natural language queries, identifying intent, urgency, asset type, and operational risk without relying on keyword matching. This skill forms a working hypothesis before any retrieval begins, enriching the query with asset and service history metadata, distinguishing troubleshooting requests from procedural queries, and routing to the most appropriate knowledge sources. If the query lacks sufficient context for a high-confidence response, it asks a targeted follow-up question rather than proceeding with incomplete information. #### Multi-Source Knowledge Search Searches simultaneously across multiple structured and unstructured systems to gather relevant information, manuals, engineering documentation, bulletins, historical work orders, case resolutions, similar asset failures, and prior repair outcomes. Unlike basic search, this skill cross-checks content consistency across sources, weighs recency and outcome history, and assembles a unified operational view rather than returning individual documents. #### Context-Aware Retrieval Fetches knowledge tailored to the specific asset, configuration, and operational scenario. Using asset ID, configuration variant, service history, and job context, this skill delivers configuration-specific troubleshooting steps and suppresses non-applicable or outdated instructions. The result is guidance that applies to the exact situation the user is facing, not generic documentation that requires interpretation. #### Relevance Ranking Evaluates and prioritizes validated, configuration-aligned guidance while suppressing outdated or low-confidence content. This skill ranks results based on source validation, usage signals, and resolution effectiveness across historical cases, returning guidance with clear confidence indicators so users understand how reliable each piece of guidance is. High-confidence, validated steps are surfaced first; unsafe or generic content is filtered out. #### Knowledge Gap Detection Identifies repeated queries, workarounds, and unresolved patterns to surface missing or weak documentation for continuous improvement. This skill monitors confidence levels and outcome signals from every interaction, detects recurring questions that the knowledge base cannot answer well, and automatically flags gaps for review. Where gaps are identified, it supports structured content creation, generating draft knowledge articles from field feedback and routing them through a human approval process before they are published. ## Deployment and Access The Knowledge Manager is a user-invoked conversational agent. It responds to questions raised directly by engineers, agents, or planners, it does not run as a background processing worker. **Primary interface:** Microsoft Teams, accessible on both desktop and mobile. Teams provides the conversational interface through which users submit questions, receive guidance, follow up, and rate responses. **Additional interfaces:** * API access for integration into existing customer chatbots or service platforms * Embedded chat widget deployable with a single line of code into any web interface * Deep integration into existing bots such as Salesforce Einstein, where the Knowledge Manager acts as a callable skill that receives context from the host bot and returns structured, governed responses This interface-agnostic design means the Knowledge Manager can enhance existing conversations and service platforms without requiring users to switch tools. ## Connected Knowledge Sources The Knowledge Manager connects to a wide range of knowledge sources across an enterprise: * **Manuals and technical documentation:** equipment manuals, engineering bulletins, safety notices * **Service management systems:** ServiceNow, Zendesk, Freshdesk, Salesforce Service Cloud * **Knowledge platforms:** Confluence, Notion, Guru, SharePoint, Google Drive * **ERP and field service systems:** IFS Cloud (FSM, PSO, service requests), Dynamics * **CRM systems:** Salesforce, HubSpot, Kustomer, Gainsight * **Collaboration and document tools:** Microsoft Teams, Google Drive, Poka * **Historical service records and case notes:** resolved tickets, prior repair outcomes, field job notes Sources are configured based on what is relevant and authorized for each deployment. The system can operate across any combination of structured and unstructured sources simultaneously. ## Integration Points **Collaboration Platforms:** Microsoft Teams and Slack serve as the primary conversational interfaces for field engineers and support teams. **Enterprise Applications:** IFS Cloud, Salesforce, and other enterprise platforms provide asset data, service history, and operational context that enriches retrieval. **Support Systems:** ServiceNow, Zendesk, Freshdesk, and similar platforms provide ticket history and case resolution data. **Knowledge Platforms:** SharePoint, Confluence, Notion, Guru, and Google Drive provide document-based knowledge content. **Email:** Outlook and Gmail support communication workflows where needed. **Documents:** IFS Loops and Google Drive support document retrieval and knowledge base management. ### Human-in-the-Loop Design The Knowledge Manager is designed with human oversight built in at the points where it matters most, particularly in high-compliance and safety-sensitive environments. Knowledge retrieval proceeds automatically when: * The query contains sufficient context for a high-confidence response * Matching knowledge exists across connected sources * The guidance is validated and configuration-appropriate Human input is required when: * The query lacks sufficient context and the system asks a clarifying question * A knowledge gap is detected and draft content is generated for review and approval * A response is rated negatively and the interaction is flagged for review * Knowledge from a resolved interaction is converted to a draft article requiring approval before publication Role-based visibility ensures users receive guidance appropriate to their role and access level. Escalation paths are maintained for cases that require senior review. Full auditability means every query, response, confidence rating, and outcome signal is tracked, supporting compliance requirements and continuous quality improvement. ### Feedback and Continuous Improvement Every response can be rated with a thumbs up or thumbs down directly in the interface. This feedback, combined with follow-up question patterns, resolution confirmation signals, and recurring gap detection, feeds continuously into improving both response quality and knowledge content. The feedback loop operates at two levels: improving how the system retrieves and ranks existing knowledge, and identifying what new or updated knowledge needs to be created. Both are monitored automatically, with human review triggered at the content approval stage rather than requiring manual monitoring of individual interactions.
# Real-world scenarios ## Overview This article walks through two practical scenarios that illustrate how the Knowledge Manager supports field engineers in the flow of work. The first follows a technician resolving a fault using the Knowledge Manager through Microsoft Teams, covering the full interaction from initial question through to job closure and knowledge capture. The second illustrates what happens when a question cannot be fully answered, showing how the system handles gaps rather than returning unreliable guidance. ### Scenario 1: Field Fault Resolution via Teams This scenario follows a field service engineer encountering a fault code on site and using the Knowledge Manager to resolve it, without searching across multiple systems, calling a senior colleague, or leaving the issue partially resolved. #### Start of Day The engineer opens their job in the mobile app. Before they arrive on site, the Knowledge Manager has already assembled a contextual knowledge pack based on the asset configuration, service history, and any relevant manuals, so the engineer arrives with relevant context already available rather than starting from scratch on site. #### Fault Encountered A fault code appears that the engineer hasn't seen recently on this configuration. Rather than opening multiple systems to search for relevant procedures, the engineer submits a question in natural language through Microsoft Teams, describing the scenario they're dealing with. #### Knowledge Manager Responds The Knowledge Manager interprets the intent behind the question, identifies the asset type and configuration from the job context, and searches all connected knowledge sources simultaneously: manuals, historical service records, prior case resolutions, and engineering bulletins. Within seconds, a response comes back directly in Teams with: * The most relevant diagnostic steps for that specific asset configuration * Citations showing exactly which sources the guidance came from * Links to supporting documentation for reference The engineer does not need to open any other system. The guidance is specific to the asset they are working on, not a generic procedure that requires interpretation. #### Follow-Up and Clarification The engineer follows the diagnostic steps and adds some additional context about what they're observing. The Knowledge Manager responds with further detail, continuing the conversation naturally and maintaining the context of the original question throughout. Each response can be rated with a thumbs up or thumbs down. This feedback is captured automatically and contributes to improving future responses for similar queries. #### Issue Resolved The engineer follows the recommended steps and resolves the issue on the first visit. The interaction has replaced what would previously have been 15 to 20 minutes of searching across multiple systems, a phone call to a senior technician, and a potential follow-up visit due to incomplete or generic guidance. #### Job Notes Generated When the job is closed, the Knowledge Manager can generate a set of job notes from the interaction, structured from the conversation, the guidance used, and the outcome. The engineer reviews and submits them. These notes contribute to the knowledge base, ensuring that the resolution is captured in a reusable form rather than buried in free-text. ### Scenario 2: Handling a Knowledge Gap This scenario covers what happens when a question arrives that the Knowledge Manager cannot answer with high confidence, for example, a query about a non-standard configuration for which documentation is incomplete or missing. #### Question Submitted An engineer submits a question about safety or configuration steps for a non-standard installation. The Knowledge Manager interprets the query and begins searching connected sources. #### Low Confidence Detected The system finds some relevant content but identifies that the available guidance has low confidence for this specific configuration, perhaps because documentation is partial, conflicting, or has not been updated to reflect recent equipment changes. Rather than returning the low-confidence guidance as if it were reliable, the Knowledge Manager does two things: 1. Requests additional context from the engineer, asking a targeted follow-up question to narrow the scenario before returning guidance. This ensures that if a reliable answer exists, it can be retrieved more precisely. 2. Flags the gap in the background, registering that this configuration has been queried and that the available knowledge is insufficient to answer it with confidence. #### Guidance Returned with Appropriate Signals If a high-confidence answer can be assembled after clarification, it is returned with citations and confidence indicators. If the gap is genuine and cannot be resolved from current sources, the Knowledge Manager communicates this clearly rather than returning unreliable guidance, and escalation paths are available for cases that require senior review. #### Gap Triggers Content Action The flagged gap is logged automatically. If the same configuration is queried repeatedly without a satisfactory answer, the Knowledge Manager surfaces this pattern for review, identifying it as a knowledge gap that needs to be addressed. It can generate a draft knowledge article based on the interaction context, which is routed through a human approval process before being published back into the knowledge base. Over time, this means the knowledge base evolves based on what engineers are actually encountering in the field, not just what was documented when the system was first set up. ### What These Scenarios Illustrate **Knowledge is delivered in the flow of work.** Engineers don't leave Teams to find answers. The entire interaction, question, guidance, follow-up, job notes, happens in the same interface they're already using. **Guidance is specific, not generic.** The Knowledge Manager uses asset ID, configuration, service history, and job context to return steps that apply to the exact situation. Generic documentation that might not apply is filtered out. **Citations make trust explicit.** Every response includes sources, so engineers can see where the guidance comes from and assess its authority. Confidence indicators make the reliability of each answer visible. **The system asks rather than guesses.** When context is missing or confidence is low, the Knowledge Manager asks a targeted follow-up question rather than returning uncertain guidance. This is particularly important in safety-sensitive environments where acting on incorrect information carries real risk. **Gaps are captured, not ignored.** When knowledge doesn't exist or is insufficient, the system flags it automatically rather than letting the gap persist. Over time this drives continuous improvement of the knowledge base from real field demand. **Resolved jobs feed future answers.** Knowledge generated through interactions, job notes, resolution steps, workarounds, is structured and routed for review rather than left in free-text notes. This turns individual resolutions into reusable organizational knowledge. # FAQ ## Capabilities & Functionality **Q: What does the Knowledge Manager do?** A: The Knowledge Manager is a Digital Worker that gives service and operations teams fast access to trusted, relevant guidance in the flow of work. When a user submits a question, it interprets the intent behind it, searches across every connected knowledge source simultaneously, and returns ranked answers with citations and confidence indicators so users know exactly where the guidance comes from. It flags gaps in the knowledge base automatically, improves with user feedback, and can generate structured knowledge articles from resolved work for human review and approval. **Q: What sources does it search when answering a question?** A: The Knowledge Manager searches across all connected sources simultaneously, including manuals, PDFs, job histories, case notes, and resolved cases. It can connect to enterprise applications, support platforms, knowledge platforms, and document repositories. The specific sources available depend on the integrations configured for your environment. **Q: How does it handle ambiguous or incomplete questions?** A: When a question does not contain enough information to return a confident answer, the Digital Worker asks a targeted follow-up question to clarify what is needed. It interprets the intent behind queries, including asset context, urgency, configuration, and role, so it can ask the right question rather than returning low-confidence results or requiring the user to rephrase and resubmit. **Q: How does it rank and present answers?** A: Answers are ranked by relevance, confidence, and source authority. The Digital Worker surfaces the most appropriate guidance first and displays citations alongside each response so users can see exactly which source the guidance comes from. Confidence indicators give users a clear signal of how well-supported each answer is, which is particularly important in compliance-sensitive or safety-critical environments. **Q: Can it generate knowledge from resolved work?** A: Yes. After a complex issue is resolved, the Digital Worker can generate a structured draft knowledge article from the interaction. This draft is submitted for human review and approval before it becomes part of the searchable knowledge base. No unreviewed content enters the knowledge base automatically. ## Control & Collaboration **Q: Does a human review the guidance before it reaches the user?** A: Knowledge that already exists in the connected sources is surfaced directly to users with citations and confidence indicators rather than passing through a review step at query time. The human-in-the-loop model applies at the knowledge creation stage: articles generated from resolved work are reviewed and approved by a knowledge owner before they are added to the knowledge base and made available for future queries. **Q: How does the Digital Worker handle questions it cannot answer confidently?** A: When the Digital Worker cannot find a confident answer, it does not surface low-quality or speculative guidance. Instead, it flags the gap automatically for review by the knowledge team. The question pattern is tracked so that recurring unanswered questions become visible and can be prioritized for knowledge development. **Q: How does feedback from users improve the Digital Worker over time?** A: Each response can be rated with a thumbs up or thumbs down. This feedback is used to improve how the Digital Worker responds and which content it surfaces. The system also learns from confirmed outcomes and human review decisions, so the quality of guidance improves as the knowledge base and usage patterns develop. **Q: Can it generate job notes from an interaction?** A: Yes. At the end of an interaction, the Digital Worker can generate a set of job notes based on the conversation. These notes can be reviewed by the user and submitted automatically, reducing the time required for post-job documentation. ### Integration & Technology **Q: What systems and platforms does the Knowledge Manager integrate with?** A: The Knowledge Manager integrates with enterprise applications, support platforms, email, knowledge management platforms, collaboration tools, and document repositories. This allows it to search across the sources your teams already use and deliver answers through the channels where they already work. **Q: How do users access it?** A: Users access the Knowledge Manager through Microsoft Teams on desktop and mobile, as well as through other connected communication channels. The interface supports natural language questions and follow-up queries within the same conversation, so users can get further detail or run diagnostic steps without switching tools or starting over. **Q: What knowledge sources can it connect to?** A: The Knowledge Manager can connect to knowledge platforms including Notion, Confluence, and Google, support platforms including Zendesk and Intercom, enterprise applications including IFS and Salesforce, document repositories including Google Drive, and email platforms including Microsoft Outlook and Gmail. Refer to your implementation documentation for the specific connectors enabled in your environment. ### Security & Reliability **Q: How does the Digital Worker ensure the guidance it surfaces is trustworthy?** A: Every response includes citations that identify the source of the guidance and confidence indicators that reflect how well-supported the answer is. Users are never presented with guidance stripped of its provenance. This means teams can make informed decisions about how much weight to place on any given response, which is particularly important in high-compliance or safety-sensitive contexts. **Q: What prevents outdated or unsafe guidance from being surfaced?** A: The Relevance Ranking skill surfaces validated steps and suppresses outdated or unsafe guidance based on source authority and confidence scoring. Knowledge gaps and weak guidance are flagged for review rather than surfaced to users. The human-in-the-loop approval process for new knowledge articles also prevents unreviewed content from entering the knowledge base. **Q: How is role-based access and visibility managed?** A: The Knowledge Manager supports role-based visibility, ensuring that users see guidance appropriate to their role and context. Escalation paths and traceability are built into the system, keeping humans in the loop where compliance or operational risk requires it. **Q: Is there an audit trail of interactions and guidance provided?** A: Yes. The Digital Worker is governed by design, with full visibility and auditability across interactions. This supports compliance requirements and gives operations and knowledge teams the oversight they need to manage guidance quality and track how the system is being used. ### Customization & Performance **Q: Is it suitable for high-compliance or safety-sensitive environments?** A: Yes. The Knowledge Manager is specifically designed for service and operations teams in high-compliance or safety-sensitive environments. The combination of source citations, confidence indicators, role-based visibility, human-in-the-loop knowledge approval, and full auditability makes it appropriate for contexts where acting on incorrect or outdated guidance carries real operational or safety risk. **Q: What agentic skills does the Knowledge Manager use?** A: The Knowledge Manager is built on five agentic skills: Conversational Query Interpretation, Context-Aware Retrieval, Knowledge Gap Detection, Relevance Ranking, and Multi-Source Knowledge Search. Together these skills cover the full path from interpreting a user's question through to surfacing ranked, cited guidance and identifying where the knowledge base needs to be strengthened. **Q: Can it be configured for specific asset types, teams, or operational contexts?** A: Yes. The Context-Aware Retrieval skill delivers asset- and configuration-specific guidance based on the operational context of the query. The sources it searches, the knowledge it prioritizes, and the escalation paths it applies can all be configured to reflect your organization's specific asset types, team structures, and compliance requirements.
# WIP - Case studies See how our customers are using this Digital Worker to transform their operations. # Inventory Replenisher Keeping inventory at the right levels is critical, but manual replenishment shouldn’t demand constant human effort. This knowledge base helps you get the most out of the Inventory Replenisher, covering setup, configuration, and efficient day‑to‑day replenishment management. ### Jump right in

		Cover image
Watch & learn	See this Digital Worker in action.	create an image for watch and learn.png	Watch & learn
Core concepts	Essential context for understanding how it all works.	create an image for core concepts_.png	Core concepts
FAQ	Quick answers to common questions.	create an image for frequently asked questions_.png	FAQ
How-to guides	Practical, step-by-step guidance across a range of tasks	create a tile image representing digital worker gu (2).png	How-to guides

		Cover image
Fundamentals	Learn the full scope of what's possible	ChatGPT Image Apr 20, 2026, 06_56_23 PM.png	Fundamentals
Architecture & capabilities	Discover the components and integrations	ChatGPT Image Apr 20, 2026, 07_00_55 PM.png	Architecture & capabilities
Real-world scenarios	Practical examples of the platform in action across common business use cases.	ChatGPT Image Apr 20, 2026, 07_04_03 PM.png	Real-world scenarios

# Fundamentals ## Overview The Inventory Replenisher is an AI-powered Digital Worker designed to free inventory planners from the repetitive work of processing purchase requisitions so they can focus on the strategic supply management that actually requires human expertise. It continuously monitors ERP systems, validates supplier data, applies configured business rules, and automatically converts purchase requisitions into purchase orders, ensuring material availability while minimizing carrying costs and stockouts. By transforming manual, reactive replenishment into an intelligent, autonomous process, the Inventory Replenisher gives planners time back for strategic sourcing, supplier relationship building, demand planning, and category management. This is work that requires human judgment, negotiation skills, and strategic thinking. ## Key Benefits **Automated requisition processing:** Purchase requisition lines in planned status are evaluated, validated, and converted to purchase orders automatically when all configured conditions are met, without any manual review required for clean lines. **Consistent rule enforcement:** Business rules for supplier validity, minimum order quantities, price thresholds, and freight grouping are applied the same way every time, eliminating the inconsistency that comes from different planners making different judgment calls on routine processing. **Proactive exception visibility:** Lines that don't meet processing conditions are flagged immediately with specific reasons, giving planners clear visibility into what needs attention and why, rather than discovering problems downstream. **Freight load optimization:** When multiple requisitions exist for the same supplier, the system intelligently groups orders to minimize partial shipments and reduce transportation costs automatically. **Continuous background operation:** The Digital Worker runs on a configured schedule, hourly, daily, weekly, or event-triggered, processing requisition lines in the background without requiring planners to initiate or monitor the run. ## The Challenge It Solves Inventory replenishment is often reactive and manual. Planners must validate suppliers, apply supplier-specific rules, and convert requisitions into purchase orders across systems, a process that requires checking each line individually against multiple conditions before anything can be actioned. Disconnected systems and inconsistent rule application lead to delays, supply risks, excess inventory, and limited visibility into what has been processed versus what is still pending. In practice, this means planners are spending time on tasks like retrieving planned PR lines from IFS Cloud, reviewing each line against supplier rules and MOQ requirements, determining which lines can be actioned, manually converting valid PRs to POs, updating the ERP, and managing exceptions, all work that is repetitive, rules-based, and consumes time that could be spent on strategic decisions. ## Before and After ### Before Before the Inventory Replenisher, processing a batch of purchase requisition lines requires manual effort at every step:
{% stepper %} {% step %} Retrieve PR lines from IFS Cloud {% endstep %} {% step %} Review each PR line individually {% endstep %} {% step %} Review supplier rules on a per-line basis {% endstep %} {% step %} Determine supplier guidelines and applicability {% endstep %} {% step %} Convert valid PRs to purchase orders {% endstep %} {% step %} Update the ERP {% endstep %} {% step %} Manage exceptions separately {% endstep %} {% endstepper %} This process is reactive, prone to inconsistency, and typically takes 30 to 45 minutes per processing run, time that compounds across daily or weekly replenishment cycles. ### After With the Inventory Replenisher, the same cycle runs in three automated steps: {% stepper %} {% step %} Retrieve and review PR lines automatically {% endstep %} {% step %} Apply supplier rules and business conditions {% endstep %} {% step %} Create purchase orders for valid lines and route exceptions to planners {% endstep %} {% endstepper %} Valid lines are processed without any human involvement. Invalid lines are flagged with clear reasons. The entire run that previously took 30 to 45 minutes happens in under a minute. ## How It Works The Inventory Replenisher executes a five-step automated workflow that handles the complete replenishment cycle from requisition identification through purchase order creation. **Requisition Line Identification:** The Digital Worker queries all purchase requisition lines in planned status within a defined timeframe, typically the last 24 hours. It retrieves planned requisitions based on latest order date, filters by configured date range, applies processing limits (default 20 lines, configurable to thousands), and extracts key attributes including supplier information, part numbers, quantities, prices, and delivery requirements. **Supplier Validation and Grouping:** Before processing any orders, the system confirms each supplier is active and approved, validates that suppliers are properly connected to the relevant company and site, organizes requisition lines by supplier number to enable consolidated processing, and verifies that expected delivery timelines are available and reasonable. **Condition Evaluation and Business Rules:** The system applies customizable business rules to determine which lines should be released. These include supplier-specific validation criteria, minimum order quantity requirements, price thresholds to validate that line totals or order values fall within acceptable ranges, supplier exclusions to automatically reject requisitions from blocked suppliers, and freight load considerations to optimize order groupings and reduce transportation costs. **Release and Purchase Order Creation:** Valid lines are automatically released from planned to released status in IFS Cloud, and complete purchase orders are generated. Invalid lines are flagged with specific reasons logged. Exception notifications are sent via Teams, Slack, or email for any lines requiring manual review. A complete audit trail of all decisions, validations, and actions is maintained for compliance and analysis. **Continuous Monitoring:** The Digital Worker runs on a configured schedule, daily, hourly, weekly, or event-triggered, continuously processing in the background without requiring planner initiation. # Architecture & capabilities ## Overview The Inventory Replenisher is built on a set of integrated agentic skills coordinated by a Digital Worker agent. This article covers the core skills, agent modes and configuration options, the full replenishment workflow, integration points, and how the system determines when to process automatically versus when to route to a planner. ## Agentic Skills The Inventory Replenisher operates through five core skills, each handling a distinct part of the replenishment process. #### Actionize Planning Outcomes Translates planning recommendations, shortages, and demand signals into actionable replenishment steps rather than leaving them as static insights. This skill bridges the gap between what the planning system has identified as needed and what actually needs to happen in IFS Cloud, turning MRP signals, reorder point triggers, and project demand into executable replenishment actions. #### Supplier Validation Confirms that replenishment actions are tied to the correct supplier based on sourcing rules, contracts, and approved vendor lists. Before any purchase order is created, this skill verifies that the supplier is active and approved in the system, properly connected to the relevant company and site, and that expected delivery timelines are available and valid. #### Conditional Selection Evaluates business conditions such as MOQ, value thresholds, lead times, and approval rules to determine whether actions can be automated or require human review, applied per supplier, per site, or per any other configured dimension. This is the skill that enforces consistency: the same rules are applied to every line, every run, regardless of which planner would have otherwise handled it manually. #### Purchase Order Creation Generates purchase orders automatically when all conditions are met, ensuring accuracy in quantities, pricing, and delivery dates. This skill handles both the creation of new purchase orders and the decision of whether to add lines to an existing purchase order or create a new one, logic that can be customized through the Digital Worker's configuration. #### Stock Re-Allocation Optimizes inventory by reallocating available stock across sites or demands to prevent shortages while minimizing excess inventory. When stock exists elsewhere in the network that can address a shortage before triggering a new external procurement, this skill identifies and acts on that opportunity. ## Agent Modes and Configuration The Inventory Replenisher offers two agent configurations to match the complexity of different replenishment environments. **Basic Agent Mode** uses standard language models for straightforward requisition processing with clear business rules. This mode is suitable for environments with well-defined supplier conditions and predictable replenishment patterns. **Reasoning Mode** employs advanced reasoning models for complex scenarios requiring deeper analysis of business rules, supplier conditions, and freight optimization. This mode is appropriate when supplier-specific rules are numerous or interdependent, when freight grouping logic is complex, or when exception handling requires more nuanced evaluation. In Reasoning Mode, administrators can configure: * Reasoning effort: Controls the computational effort applied to rule evaluation and supplier selection * Verbosity: Adjusts the detail level in responses and logging for transparency and debugging * Concurrent processing: Enables parallelization of supplier processing to improve performance when handling multiple suppliers simultaneously ## Replenishment Workflow The following table outlines the full replenishment workflow from demand signal monitoring through to exception handling. | **Stage** | **What the System Does** | **Action / Output** | **Channel** | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | | **Demand Signal Monitoring** | Monitors MRP, order points, and project demand; monitors purchase requisition lines in planned state | Initiates replenishment workflow | IFS | | **Replenishment Decision** | Applies business constraints including MOQ, lead time, and supplier availability | Decides whether to procure or fulfilll internally; routes to sourcing if needed | IFS | | **PR Creation & Enrichment** | Checks requisition with correct supplier, quantity, and constraints | Auto-checks PRs; enriches with context for faster approvals | IFS | | **PR to PO Conversion** | Evaluates PR readiness for conversion; aligns with ERP authorization rules; detects safe-to-auto-release scenarios | Auto-releases valid PRs; converts PR to PO; routes to Supplier Order Manager for execution | IFS | | **Exception Handling** | Identifies MOQ conflicts, supplier constraints, and abnormal demand; detects ambiguity in decision-making | Triggers human-in-the-loop workflows; suggests alternatives such as reallocation, delay, or order splitting; resumes automated flow after decision | Teams / IFS | ## Tools and Integration Layer The Inventory Replenisher uses a comprehensive set of tools to interact with IFS Cloud and connected systems: **Get Planned Requisition Lines:** retrieves all requisition lines in planned status within the specified date range **Validate Supplier:** confirms supplier status, company assignment, and approval conditions Check Business Rules: applies customizable conditions for MOQ, pricing thresholds, and supplier-specific requirements **Auto-Release Requisition:** changes the status of valid lines from planned to released **Create Purchase Order:** generates complete PO records in IFS Cloud with all validated information **Log Results:** stores detailed execution logs for audit and troubleshooting **Send Notifications:** alerts users through Teams, Slack, or email for exceptions and approvals ## Integration Points **ERP Platforms:** Connects directly with IFS Cloud and other enterprise systems to read requisition lines, validate supplier data, and write purchase orders automatically. **Email Systems:** Integrates with Microsoft Outlook and Gmail for supplier communications and exception notifications. **Collaboration Platforms:** Uses Microsoft Teams and Slack for exception notifications, approval workflows, and real-time visibility into processing status. **Planning Systems:** Integrates with material planning (MRP), demand forecasting modules, and automated planning systems to receive requisitions from multiple sources. **IoT Sensors:** Receives demand signals from connected equipment and sensors to inform replenishment decisions. **Logistics/TMS:** Connects with transportation management systems for delivery coordination and inbound visibility. **CRM Systems:** Connects with Salesforce, HubSpot, and Qoncierge to maintain supplier relationship context and historical performance data. ## Human-in-the-Loop Design The Inventory Replenisher is designed so that routine replenishment processing happens automatically and human judgment is applied to lines and scenarios that genuinely require it. The system proceeds independently when: * Suppliers are valid, active, and approved in the system * Requisition lines meet minimum order quantity requirements * Line totals fall within configured price thresholds * Orders align with freight load optimization rules Human review is required when: * Suppliers are invalid or blocked in the system * Requisitions do not meet minimum order quantities * Line totals exceed configured price thresholds * Forecast deviations or unexpected demand patterns are detected * High-value orders require strategic judgment When exceptions are detected, the system identifies the specific validation failures preventing automatic processing, sends a detailed notification via Teams or Slack with complete context, provides a clear reason for each invalid requisition line, and maintains a complete audit trail of all decisions and validations. ## Testing and Validation The platform includes an evaluation environment for testing and development. Teams can trigger processing runs manually with specific date ranges, monitor execution in real time as the agent processes each supplier, review validation results for each requisition line, and observe purchase order creation attempts. Debug mode provides detailed visibility into inputs and outputs of each validation step. Execution summaries show total valid lines processed, invalid lines flagged, purchase orders created, and any failures, with complete audit trails available in detailed logs. # Real-world scenarios ## Overview This article walks through the Inventory Replenisher in action, illustrating how it processes a batch of purchase requisition lines, validating each one against configured business rules, creating purchase orders for lines that meet all conditions, and flagging the rest for planner review. It also covers how the system can be triggered manually for visibility into its decision-making, and how it runs as a background worker in normal operation. ### Scenario: Automated Requisition Processing with Mixed Results This scenario covers a typical replenishment run where the Digital Worker processes a batch of purchase requisition lines, some of which meet all configured conditions and some of which do not. #### Setup: Configuring Business Rules Before the Digital Worker runs, administrators configure the business rules that govern which requisition lines can be processed automatically. These rules act as the control center for the replenishment process and can include: * Supplier validity requirements (only process lines where the supplier is active and approved) * Minimum order quantity conditions (lines must meet the supplier's MOQ to proceed) * Price threshold limits (line totals or order values must fall within acceptable ranges) * Supplier exclusions (automatically reject requisitions from blocked suppliers) * Freight load grouping logic (how lines should be grouped into purchase orders) These rules are configured once and applied consistently to every processing run. They can be updated at any time as business requirements change. #### Normal Operation: Background Processing In normal operation, the Inventory Replenisher runs on a configured schedule, every hour, every day, every week, or triggered by a specific event. It processes in the background continuously, retrieving planned requisition lines from IFS Cloud, applying the configured business rules, creating purchase orders for valid lines, and notifying planners of any exceptions, all without requiring any manual initiation. #### Manual Trigger for Visibility For teams who want to observe the Digital Worker's decision-making process in real time, such as during initial setup or validation, the system can also be triggered manually via Microsoft Teams. When invoked through Teams, the Digital Worker fetches the current planned requisition lines and returns a detailed report showing how each line was evaluated before any purchase orders are created. This gives planners full visibility into which lines matched which conditions and why, so they can verify the logic before instructing the system to proceed. #### Processing the Requisition Lines In this example, the Digital Worker is triggered and retrieves 10 purchase requisition lines currently in planned status. For each line, it pulls the part number, ordered quantity, minimum order quantity, supplier details, and pricing, and evaluates every line against the full set of configured business rules simultaneously. The results come back within seconds: * 3 lines are valid, each one meets the supplier validity condition, the minimum order quantity condition, and the price threshold condition. These lines are ready to be converted to a purchase order. * 7 lines are invalid, each one fails one or more conditions. The Digital Worker identifies exactly which condition each line failed and reports this clearly, so planners know precisely what needs to be resolved before those lines can be processed. #### Purchase Order Creation The planner reviews the results, confirms the valid lines, and instructs the Digital Worker to proceed. The system auto-releases the three valid lines from planned to released status in IFS Cloud and creates a single purchase order, PO 143, containing all three lines with correct quantities, pricing, and delivery details. The Digital Worker also applies grouping logic to determine whether these lines should be added to an existing purchase order or require a new one. In this case, a new purchase order is created. This grouping behavior is fully configurable through the Digital Worker's instructions. The purchase order is immediately visible in IFS Cloud, already created and released. The entire process, from retrieving the 10 lines to creating the purchase order, takes under a minute. #### Exception Handling The 7 invalid lines are not silently discarded. The Digital Worker sends a notification via Microsoft Teams with the details of each invalid line and the specific reason it could not be processed. Planners can then address each issue, whether that means updating supplier information, negotiating a minimum order quantity waiver, or deferring the line, and re-run the process once the issues are resolved. ### What This Scenario Illustrates **The system evaluates every line against every rule simultaneously.** Rather than a planner working through lines one by one, the Digital Worker assesses the full batch in seconds and classifies each line as valid or invalid with clear reasoning. **Business rules are enforced consistently.** The same conditions apply to every line in every run, regardless of volume or which team member would otherwise have handled it. There is no variation in how rules are interpreted. **Valid and invalid lines are handled separately.** Valid lines proceed to purchase order creation immediately. Invalid lines are flagged with specific reasons and held for planner review, the two paths are handled in parallel without one blocking the other. **Planners see the decisions before they're executed.** When using manual trigger mode, planners can review the full evaluation report before any purchase orders are created. This transparency gives teams confidence in the system's logic and makes it easy to identify configuration adjustments if needed. **Grouping logic reduces unnecessary purchase orders.** The system intelligently decides whether to add lines to an existing purchase order or create a new one, applying freight load optimization to consolidate where possible, reducing transportation costs and administrative overhead. **The background mode removes the process entirely from planner workload.** Once configured, the Digital Worker runs on schedule without requiring any planner initiation, monitoring, or follow-up for clean lines. Planners only engage when exceptions require their judgment. # FAQ ### Capabilities & functionality **Q: What does Inventory Replenisher do for me?** A: It automates stock management by monitoring inventory levels, validating supplier data, and triggering replenishment orders automatically. It ensures products are available when and where they're needed, without manual tracking or intervention. **Q: How does Inventory Replenisher decide when to create a purchase order?** A: It continuously compares on-hand quantities, reorder points, and forecasted demand. When stock drops below a defined threshold, it automatically generates and validates purchase requisitions. **Q: Can it work across multiple locations or warehouses?** A: Yes. Inventory Replenisher supports multi-site operations and can independently assess stock positions for each location to maintain balanced inventory across the network. **Q: Does it handle supplier and pricing validation?** A: Absolutely. It verifies each supplier's status, pricing terms, and lead times before generating orders, ensuring every replenishment aligns with approved vendor policies. **Q: Can it adapt to changes in demand patterns?** A: Yes. It continuously learns from actual consumption and can factor in seasonal trends or forecast updates, adjusting order timing and quantities dynamically. **Q: What happens if stock levels change while replenishment is in progress?** A: The digital worker recalculates requirements in real time before finalizing purchase orders, ensuring over-ordering or duplication doesn't occur. ### Control & collaboration **Q: How can users monitor or trigger replenishment runs?** A: Users can view progress and initiate runs directly through Microsoft Teams, Slack, or the ERP interface. Real-time updates show which items are replenished and which are awaiting approval. **Q: Can planners intervene during the replenishment cycle?** A: Yes. You can define control points where the system pauses for human approval — such as when order value, supplier, or delivery timelines fall outside normal parameters. **Q: What if I need to pause or reschedule automatic replenishment?** A: Runs can be paused, delayed, or manually restarted at any time. Scheduling parameters are configurable, allowing daily, weekly, or event-based triggers. **Q: Will Inventory Replenisher notify me of exceptions?** A: Yes. If validation fails — such as an inactive supplier, pricing mismatch, or unavailable lead time — the system sends notifications in Teams, Slack, or email for quick review and correction. **Q: How does it handle collaboration between teams?** A: It shares replenishment reports, alerts, and audit logs in real time, so planners, procurement, and warehouse teams stay aligned without needing manual follow-ups. **Q: Can managers approve orders directly within chat tools?** A: Yes. Approvals and overrides can be executed directly within Teams or Slack messages, streamlining communication while maintaining oversight. ### Integration & technology **Q: How does Inventory Replenisher connect to ERP systems?** A: It integrates via secure APIs with platforms like IFS Cloud to read requisition lines, validate supplier details, and create purchase orders directly in the system. **Q: Can it pull data from forecasting or planning modules?** A: Yes. It can ingest signals from demand planning, MRP, or AI forecasting tools to refine replenishment timing and quantities. **Q: Does it integrate with communication platforms?** A: Absolutely. Teams, Slack, Gmail, and Outlook integrations allow the digital worker to send status updates, request approvals, and provide summaries without leaving your workspace. **Q: How does it handle large-scale data processing?** A: It's built for scalability, capable of evaluating thousands of requisition lines per run, grouping them by supplier, and generating POs efficiently. **Q: What happens if the ERP system or API connection fails mid-run?** A: The process automatically queues pending actions and retries when the system becomes available, ensuring no data or transaction loss. **Q: Can it support hybrid ERP environments?** A: Yes. Inventory Replenisher can work across multiple ERP instances or versions, maintaining data consistency through a unified integration layer. ### Security & reliability **Q: How are replenishment actions tracked?** A: Every action — validation, exception, and purchase order creation — is logged in the ERP audit trail and tagged with a digital worker ID for traceability. **Q: Is sensitive supplier and inventory data secure?** A: Yes. Data remains within your ERP and communication environments. The digital worker communicates via encrypted APIs and never stores sensitive data externally. **Q: How does it ensure process reliability?** A: It includes built-in retry mechanisms, queue management, and exception alerts to maintain process continuity even during temporary disruptions. **Q: Can we audit its decisions or view a history of changes?** A: Yes. A full audit trail is available, detailing every decision, timestamp, and user interaction to support compliance and continuous improvement. **Q: What happens if a scheduled run encounters unexpected input data?** A: The digital worker isolates invalid lines, logs the issue, and continues processing valid ones, avoiding total run failure. **Q: How does it ensure consistency between automated and manual actions?** A: All automated and manual transactions share the same audit trail and data source, eliminating duplication or data mismatches. ### Customization & performance **Q: Can Inventory Replenisher be configured for our business rules?** A: Yes. You can define reorder points, approval thresholds, and supplier selection logic based on your company's unique policies. **Q: Can it handle industry-specific replenishment models?** A: Absolutely. It supports sector-specific approaches like make-to-stock, just-in-time, or vendor-managed inventory. **Q: How do we measure its impact?** A: Key performance indicators include replenishment accuracy, automation rate, time saved per cycle, and reduction in manual purchase order creation. **Q: How are adjustments to parameters managed?** A: Parameters such as reorder points, approval rules, and scheduling frequencies can be updated directly through configuration settings — no coding required. **Q: Can it evolve with changing business priorities?** A: Yes. Rules and thresholds can be continuously refined as your operations, demand patterns, or supplier landscape evolve. **Q: What results can teams expect after deployment?** A: Most organizations see faster order cycles, fewer stockouts, and measurable reductions in manual administrative time within weeks of activation. # WIP - Case studies See how our customers are using this Digital Worker to transform their operations. # Material Replenisher The Material Replenisher simplifies how technicians find parts and create material requisitions, removing unnecessary system complexity from field work. By automating part searches and requests in IFS, it helps technicians focus on repairs and planners focus on keeping materials available where they’re needed most. ### Jump right in

		Cover image
Watch & learn	See this Digital Worker in action.	create an image for watch and learn.png	Watch & learn
Core concepts	Essential context for understanding how it all works.	create an image for core concepts_.png	Core concepts
FAQ	Quick answers to common questions.	create an image for frequently asked questions_.png	FAQ
Case studies	Learn from real world examples of success.	create an image for case studies_ (1).png	Case studies
How-to guides	Practical, step-by-step guidance across a range of tasks	create a tile image representing digital worker gu (2).png	How-to guides

		Cover image
Fundamentals	Learn the full scope of what's possible	ChatGPT Image Apr 20, 2026, 06_56_23 PM.png	Fundamentals
Architecture & capabilities	Discover the components and integrations	ChatGPT Image Apr 20, 2026, 07_00_55 PM.png	Architecture & capabilities
Real-world scenarios	Practical examples of the platform in action across common business use cases.	ChatGPT Image Apr 20, 2026, 07_04_03 PM.png	Real-world scenarios

# Fundamentals ## Overview The Material Replenisher is an AI-powered Digital Worker designed to free field technicians from administrative work so they can focus on the repair work they were hired to do. It streamlines the process of finding parts and creating maintenance material requisitions (MMRs) within the IFS platform, enabling technicians to search for parts using natural language, check inventory availability across connected warehouses, and automatically generate requisitions, all without navigating complex system interfaces. By transforming manual, fragmented part requests into an intelligent, automated process, the Material Replenisher gives technicians their time back for hands-on field work and gives planners time for supply chain optimization. This is work that requires human expertise, problem-solving skills, and equipment knowledge. ## Key Benefits The Material Replenisher delivers value by automating part request workflows across the full replenishment cycle: **Instant part intelligence:** Natural language queries return availability, location, and compatibility information in seconds, keeping technicians focused on equipment repairs, not system navigation. **Zero back-office churn:** Eliminates phone calls and emails between technicians and planners, standardizing processes across all locations and reducing delays. **Error prevention built-in:** Intelligent validation catches duplicate orders and incorrect reservations before they create problems, while historical intelligence suggests proven parts. **Reduced equipment downtime:** Faster part availability gets technicians back to productive work quickly, minimizing costly equipment idle time. **Human expertise elevated:** Skilled field technicians focus on hands-on repairs while planners optimize supply chains and improve inventory planning. ### The Challenge It Solves Material replenishment is often manual and fragmented. Technicians and planners must identify parts, validate availability, and raise requisitions across multiple systems, leading to delays in part fulfilllment, incorrect part selection, excess or missing inventory, and heavy dependency on planners for routine requests. When technicians need parts, they traditionally must: * Search through extensive part catalogs with complex numbering systems * Verify part availability across multiple warehouse locations * Check inventory at sites connected to their user profile * Create maintenance material requisitions with proper documentation * Link parts to specific work orders and work tasks through multiple system screens High request volume combined with site-by-site variations leads to duplicate orders, incorrect reservations, and constant back-and-forth between technicians, planners, and procurement teams. ## Before and After ### Before Before the Material Replenisher, the replenishment process requires significant manual effort at every step: {% stepper %} {% step %} Receive technician request for part {% endstep %} {% step %} Search parts catalogs manually {% endstep %} {% step %} Identify correct parts or alternatives {% endstep %} {% step %} Check inventory availability {% endstep %} {% step %} Validate part details {% endstep %} {% step %} Create requisitions (MMR/MPR) {% endstep %} {% step %} Update ERP and follow up on fulfilllment {% endstep %} {% endstepper %} This manual process introduces high error rates, delayed technician support, and heavy planner dependency. #### After With the Material Replenisher, the same process is streamlined to three automated steps: {% stepper %} {% step %} Receive request from technician and understand the context {% endstep %} {% step %} Search for part by categories and sub-categories {% endstep %} {% step %} Create requisitions (MMR/MPR) {% endstep %} {% endstepper %} Routine requests flow through automatically. Exceptions are routed to the right person with full context already attached. ## How It Works The Material Replenisher operates through an automated workflow that handles the complete part request and requisition cycle. **User Identification:** The Digital Worker identifies the technician making the request using their email ID, retrieving the corresponding user ID from IFS Cloud. This determines which warehouse sites are connected to the technician, associates the correct user with created requisitions, and ensures proper authorization and access controls. **Information Extraction:** The system analyzes natural language queries to extract key information: part description, functional unit ID for the specific equipment, unit type classification, and product family category. This transforms unstructured queries like "I need air filters for functional unit XYZ" into structured search parameters. **Intelligent Part Catalog Search:** The system performs targeted searches using multiple strategies: by unit type to find parts designed for that specific equipment, by product family to find relevant parts within a category, and by searching historical work tasks associated with the functional unit ID to identify parts previously used for that equipment. **Verification and Validation:** Before proceeding, the system verifies that parts have been extracted correctly. If no valid information can be extracted from the query, it requests clarification from the technician rather than proceeding with incomplete data. **Availability Check:** When technicians request to check part availability, the Digital Worker identifies all warehouse sites connected to their user profile, checks inventory levels at each connected site, and reports back with specific locations where the part is in stock, including site ID and warehouse location details. **Maintenance Material Requisition Creation:** When technicians request to reserve a part or create a new MMR, the system automatically generates a maintenance material requisition using the technician's user ID, site ID associated with the selected warehouse, work order information, confirmed part number, and work task details. All records are properly documented and linked to the appropriate work orders. # Architecture & capabilities ## Overview The Material Replenisher is built on a set of integrated agentic skills that work together to handle the complete part request and requisition cycle. This article covers the core capabilities of the Digital Worker, how its components are structured, how it connects to your existing systems, and how it determines when to proceed independently versus when to involve a human. ## Agentic Skills The Material Replenisher operates through five core skills. Each handles a distinct stage of the replenishment process. #### Request Interpretation Understands technician requests by extracting the part need, unit context, description, and urgency from the message or form submission. This skill transforms unstructured natural language, such as "I need air filters for functional unit XYZ", into structured search parameters the system can act on. If the request lacks sufficient information to proceed, the system asks a targeted clarifying question rather than making the technician start over. #### Part Identification & Validation Identifies the correct inventory part and validates it against unit data and historical usage to prevent incorrect or duplicate selections. The system searches by unit type, product family, and historical work task data associated with the specific equipment. When multiple candidate parts with similar names or part numbers are found, all options are presented to the technician for selection rather than the system guessing. #### Multi-Site Inventory Lookup Checks inventory availability across multiple sites, warehouses, and locations to find usable stock and match it with the technician's location. The Digital Worker identifies all warehouse sites connected to the technician's user profile and checks inventory levels at each one, returning specific site IDs and warehouse location details. Before reporting a part as unavailable, it conducts a global search across all locations to make sure no stock has been missed. #### Fulfillment Decision Logic Determines the optimal fulfilllment path based on stock availability. When stock exists at a connected site, the system creates an internal transfer. When stock is not available anywhere, it initiates a purchase requisition (MPR). This decision is made automatically for clear cases, with the full context passed to a planner when human judgment is needed. #### Context-Aware Escalation Requests human confirmation only when information is missing, ambiguous, or requires judgment before proceeding. Rather than failing silently or making assumptions, the system pauses at the right moments, presenting options, asking for confirmation, and routing exceptions to planners with complete supporting context for fast resolution. ## Component Structure The Material Replenisher is built using a combination of tools and sub-agents coordinated by a Supervisor Agent: * User identity resolution tools * Part catalog search capabilities with multiple search strategies * Warehouse connectivity checks * Historical work task query engines * MMR and MPR creation and management automation The Supervisor Agent receives technician requests, orchestrates the appropriate skills in sequence, and determines when to proceed automatically versus when to surface a decision to the technician or planner. ## Replenishment Workflow The following table outlines the full replenishment workflow, from initial request intake through to fulfilllment actions. | **Stage** | **What the System Does** | **Action / Output** | **Channel** | | ------------------------------------------ | ------------------------------------------------------------------------- | ------------------------------------------------------------------------- | --------------- | | **Request Intake & Context Understanding** | Captures technician request and understands job/work order context | Structures request data, triggers material lookup | FSM / IFS / MWO | | **Part Identification & Validation** | Matches descriptions to parts, validates part numbers, detects duplicates | Identifies correct part, reduces misidentification, ensures data accuracy | IFS | | **Alternative Part Suggestion** | Identifies substitutes or equivalents, evaluates compatibility | Suggests alternative parts, improves fulfilllment success | IFS | | **Inventory Check & Availability** | Checks stock across locations, identifies availability constraints | Confirms availability, recommends sourcing or transfer | IFS | | **Requisition Creation (MMR/MPR)** | Validates part and request data, prepares ERP inputs | Creates MMR or MPR, reduces manual workload | IFS | | **Exception Handling** | Detects unclear or missing data, identifies part conflicts | Triggers human-in-the-loop review, provides resolution options | Teams | ## Integration Points The Material Replenisher connects with your existing technology ecosystem across several categories. **Collaboration Platforms:** Integrates directly with Microsoft Teams and Slack through widget configuration, allowing technicians to interact using natural language messages. Technicians can mention the IFS bot and issue commands directly through the channel interface, no separate system login required. **ERP Platforms:** Connects directly with IFS Cloud FSM/ERP modules to access work orders, work tasks, part catalogs, and warehouse inventory, and to create maintenance material requisitions automatically. **Field Service Management:** Monitors mobile work orders, work tasks, IoT fault alerts, and customer calls/portals to capture part requests from multiple sources. **Email:** Integrates with Outlook and Gmail to support request intake and communication. **Enterprise Applications:** Connects with enterprise platforms including IFS, Salesforce, and others for cross-system data access. **Documents:** Integrates with IFS Loops and Google Drive for document-based context and knowledge base updates. **Communication Channels:** Updates work orders, creates MPRs/MMRs, notifies customers, and updates knowledge bases automatically across all integrated systems. ### Human-in-the-Loop Design The Material Replenisher is designed around the principle that humans make strategic decisions while the Digital Worker handles administrative execution. The system proceeds independently when: * The part description is clear and unambiguous * The part is available in connected warehouse inventory * The request includes complete information including functional unit ID and work order * The technician has valid credentials with proper warehouse site connections Human input is required when: * Requests are vague or incomplete and need clarification * Multiple candidate parts with similar names require technician selection * Parts are not available in inventory and a planner decision on alternatives is needed * Conflicts or exceptions require manual resolution When clarification is needed, the system asks targeted questions, presents multiple options when similar parts are found, conducts global searches before reporting unavailability, and routes complex cases to planners with complete supporting context already attached. ## Testing and Validation The platform includes a comprehensive evaluation environment accessible through the Loops platform, allowing users to: * Input test queries directly and observe the Digital Worker's response in real time * Use Plan Flow visualization to see execution steps as they happen * Enable debug mode for granular visibility into input/output tracking, step-by-step execution, search results, and API call details * Review historical records of all interactions with processing time metrics and visual usage graphs This environment supports ongoing testing, optimization, and validation before deploying changes to live workflows.
# Real-world scenarios ## Overview This article walks through two practical scenarios that illustrate how the Knowledge Manager supports field engineers in the flow of work. The first follows a technician resolving a fault using the Knowledge Manager through Microsoft Teams, covering the full interaction from initial question through to job closure and knowledge capture. The second illustrates what happens when a question cannot be fully answered, showing how the system handles gaps rather than returning unreliable guidance. ### Scenario 1: Field Fault Resolution via Teams This scenario follows a field service engineer encountering a fault code on site and using the Knowledge Manager to resolve it, without searching across multiple systems, calling a senior colleague, or leaving the issue partially resolved. #### Start of Day The engineer opens their job in the mobile app. Before they arrive on site, the Knowledge Manager has already assembled a contextual knowledge pack based on the asset configuration, service history, and any relevant manuals, so the engineer arrives with relevant context already available rather than starting from scratch on site. #### Fault Encountered A fault code appears that the engineer hasn't seen recently on this configuration. Rather than opening multiple systems to search for relevant procedures, the engineer submits a question in natural language through Microsoft Teams, describing the scenario they're dealing with. #### Knowledge Manager Responds The Knowledge Manager interprets the intent behind the question, identifies the asset type and configuration from the job context, and searches all connected knowledge sources simultaneously: manuals, historical service records, prior case resolutions, and engineering bulletins. Within seconds, a response comes back directly in Teams with: * The most relevant diagnostic steps for that specific asset configuration * Citations showing exactly which sources the guidance came from * Links to supporting documentation for reference The engineer does not need to open any other system. The guidance is specific to the asset they are working on, not a generic procedure that requires interpretation. #### Follow-Up and Clarification The engineer follows the diagnostic steps and adds some additional context about what they're observing. The Knowledge Manager responds with further detail, continuing the conversation naturally and maintaining the context of the original question throughout. Each response can be rated with a thumbs up or thumbs down. This feedback is captured automatically and contributes to improving future responses for similar queries. #### Issue Resolved The engineer follows the recommended steps and resolves the issue on the first visit. The interaction has replaced what would previously have been 15 to 20 minutes of searching across multiple systems, a phone call to a senior technician, and a potential follow-up visit due to incomplete or generic guidance. #### Job Notes Generated When the job is closed, the Knowledge Manager can generate a set of job notes from the interaction, structured from the conversation, the guidance used, and the outcome. The engineer reviews and submits them. These notes contribute to the knowledge base, ensuring that the resolution is captured in a reusable form rather than buried in free-text. ### Scenario 2: Handling a Knowledge Gap This scenario covers what happens when a question arrives that the Knowledge Manager cannot answer with high confidence, for example, a query about a non-standard configuration for which documentation is incomplete or missing. #### Question Submitted An engineer submits a question about safety or configuration steps for a non-standard installation. The Knowledge Manager interprets the query and begins searching connected sources. #### Low Confidence Detected The system finds some relevant content but identifies that the available guidance has low confidence for this specific configuration, perhaps because documentation is partial, conflicting, or has not been updated to reflect recent equipment changes. Rather than returning the low-confidence guidance as if it were reliable, the Knowledge Manager does two things: 1. Requests additional context from the engineer, asking a targeted follow-up question to narrow the scenario before returning guidance. This ensures that if a reliable answer exists, it can be retrieved more precisely. 2. Flags the gap in the background, registering that this configuration has been queried and that the available knowledge is insufficient to answer it with confidence. #### Guidance Returned with Appropriate Signals If a high-confidence answer can be assembled after clarification, it is returned with citations and confidence indicators. If the gap is genuine and cannot be resolved from current sources, the Knowledge Manager communicates this clearly rather than returning unreliable guidance, and escalation paths are available for cases that require senior review. #### Gap Triggers Content Action The flagged gap is logged automatically. If the same configuration is queried repeatedly without a satisfactory answer, the Knowledge Manager surfaces this pattern for review, identifying it as a knowledge gap that needs to be addressed. It can generate a draft knowledge article based on the interaction context, which is routed through a human approval process before being published back into the knowledge base. Over time, this means the knowledge base evolves based on what engineers are actually encountering in the field, not just what was documented when the system was first set up. ## What These Scenarios Illustrate **Knowledge is delivered in the flow of work.** Engineers don't leave Teams to find answers. The entire interaction, question, guidance, follow-up, job notes, happens in the same interface they're already using. **Guidance is specific, not generic.** The Knowledge Manager uses asset ID, configuration, service history, and job context to return steps that apply to the exact situation. Generic documentation that might not apply is filtered out. **Citations make trust explicit.** Every response includes sources, so engineers can see where the guidance comes from and assess its authority. Confidence indicators make the reliability of each answer visible. **The system asks rather than guesses.** When context is missing or confidence is low, the Knowledge Manager asks a targeted follow-up question rather than returning uncertain guidance. This is particularly important in safety-sensitive environments where acting on incorrect information carries real risk. **Gaps are captured, not ignored.** When knowledge doesn't exist or is insufficient, the system flags it automatically rather than letting the gap persist. Over time this drives continuous improvement of the knowledge base from real field demand. **Resolved jobs feed future answers.** Knowledge generated through interactions, job notes, resolution steps, workarounds, is structured and routed for review rather than left in free-text notes. This turns individual resolutions into reusable organizational knowledge. # FAQ ## Capabilities & Functionality **Q: What does the Material Replenisher do?** A: The Material Replenisher is a Digital Worker that handles part requests from field technicians and maintenance teams. It interprets incoming requests from multiple channels, identifies and validates the correct part, checks inventory across connected sites, and either reserves the part, creates a material requisition, or routes the request to a planner depending on what the inventory check finds. The ERP and relevant stakeholders are updated automatically throughout the process. **Q: What types of requests can it interpret and act on?** A: The Digital Worker can interpret requests submitted via Microsoft Teams, email, work orders, IoT fault alerts, and customer calls or portals. It extracts part needs, urgency, and equipment context from the request, including from minimal or informal descriptions, and determines the appropriate action without requiring technicians to fill in forms or log into systems. **Q: How does it handle incomplete or vague part requests?** A: When a request does not contain enough information to identify a part with confidence, the Digital Worker asks a targeted clarifying question to gather what it needs. It does not reject the request or require the technician to start over. If multiple candidate parts match the description, it presents the options and asks the technician to confirm the correct one before proceeding. **Q: What happens when a part is in stock versus out of stock?** A: When a part is confirmed in stock at an accessible location, the Digital Worker reserves it and notifies the technician with the part details and location. When a part is not available locally, it conducts a multi-site inventory search across all connected locations. If the part cannot be found anywhere in inventory, the Digital Worker initiates a material purchase requisition (MPR) or material movement requisition (MMR) and guides the technician through the details needed to complete it. **Q: Can it identify and recommend similar parts?** A: Yes. The Digital Worker can suggest similar or equivalent parts based on minimal descriptions, historical usage data, and situational context. This reduces the risk of a request stalling because a technician does not have an exact part number. ## Control & Collaboration **Q: Does a human need to be involved in every request?** A: No. Requests with a clear part identification and available stock are handled automatically without planner involvement. The Digital Worker reserves the part, updates the ERP, and notifies the technician. Human input is required only when information is missing or ambiguous, when stock is unavailable and a requisition needs to be created, or when a request involves a judgment call that falls outside automated resolution. **Q: How does the Digital Worker involve planners when exceptions occur?** A: When a request cannot be resolved automatically, the Digital Worker routes it to a planner with the full context of the request, including the part details, equipment information, site, and the reason it requires review. Planners receive enough information to act quickly without having to investigate from scratch. **Q: How do technicians interact with the Digital Worker?** A: Technicians interact through natural conversation in Microsoft Teams. They can submit a request using plain language, respond to clarifying questions, confirm part selections, and provide requisition details, all within the same channel. No forms, no system logins, and no separate tools are required. **Q: What happens after a requisition is created?** A: Once a material requisition is created, the Digital Worker provides the technician with confirmation and next steps. It can also notify additional stakeholders if needed. The requisition details, decisions, and any approvals are recorded in full for audit purposes. ## Integration & Technology **Q: What systems does the Material Replenisher integrate with?** A: The Material Replenisher integrates with ERP and FSM systems for inventory checks, reservations, and work order updates. It connects to email platforms, collaboration tools including Microsoft Teams and Slack, and document platforms. This allows it to receive requests from existing channels and update records in the systems your teams already use. **Q: What channels can technicians use to submit requests?** A: Requests can be submitted via Microsoft Teams, email, work orders or work tasks in FSM and ERP systems, IoT fault alerts, and customer calls or portals. The Digital Worker monitors all of these simultaneously and processes requests in real time regardless of which channel they arrive through. **Q: How does it interact with the ERP?** A: The Digital Worker reads inventory data, validates parts against the catalog, creates or updates reservations, initiates MPRs or MMRs, and updates work order and work task records directly in the ERP and FSM. All updates are written back automatically without manual data entry. **Q: What is an MPR or MMR and how does the Digital Worker handle them?** A: An MPR (material purchase requisition) is created when a part needs to be sourced externally because it is not available in any connected inventory location. An MMR (material movement requisition) is created when stock needs to be transferred between sites. The Digital Worker initiates the appropriate document type based on the inventory check outcome, collects the required details from the technician, and creates the record in the ERP automatically. ## Security & Reliability **Q: How does the Digital Worker prevent duplicate orders or incorrect part selection?** A: Parts de-duplication is a core agentic skill. The Digital Worker checks whether a request duplicates an existing reservation or order before creating anything new. When multiple parts match a description, it presents all candidates for technician confirmation rather than selecting one automatically, preventing incorrect reservations from entering the system. **Q: How is traceability maintained across requests?** A: Every request, part validation, inventory check, reservation, MPR or MMR, and approval is recorded with full traceability. This means planners and auditors can review the complete history of any request, including what information was provided, what decisions were made, and what actions were taken. **Q: How are exceptions handled consistently across sites?** A: Exception routing follows the same logic regardless of which site a request originates from. When a request cannot be resolved automatically, it is escalated to a planner with standardized context. This means all sites operate on the same intake process with no local variations in how exceptions are handled. ## Customization & Performance **Q: Can it operate across multiple sites?** A: Yes. The Material Replenisher checks inventory across all connected sites simultaneously and applies the same intake and validation logic at every location. Organizations managing replenishment across many sites benefit from consistent processes and consolidated visibility without additional configuration per site. **Q: What agentic skills does the Material Replenisher use?** A: The Material Replenisher is built on five agentic skills: Request Interpretation, Part Identification & Validation, Multi-Site Inventory Lookup, Fulfilment Decision Logic, Parts De-duplication, and Requisition Creation. Together these skills cover the full path from an incoming technician request through to ERP update or requisition creation. **Q: Can it be configured to reflect our specific parts catalog and business rules?** A: Yes. The Digital Worker validates parts against your catalog in the connected ERP and applies fulfillment logic based on your inventory structure and site configuration. This means part identification and requisition creation reflect your organization's actual data rather than generic rules. # Case studies See how our customers are using this Digital Worker to transform their operations. {% embed url="" %} # Reconciliation Manager Reconciling accounts takes precision, but repetitive matching work shouldn't slow teams down. This knowledge base guides you through using the Reconciliation Manager, from initial setup to handling account reconciliation efficiently in daily operations. ### Jump right in

		Cover image
Watch & learn	See this Digital Worker in action.	create an image for watch and learn.png	Watch & learn
Core concepts	Essential context for understanding how it all works.	create an image for core concepts_.png	Core concepts
FAQ	Quick answers to common questions.	create an image for frequently asked questions_.png	FAQ
How-to guides	Practical, step-by-step guidance across a range of tasks	create a tile image representing digital worker gu (2).png	How-to guides

		Cover image
Fundamentals	Learn the full scope of what's possible	ChatGPT Image Apr 20, 2026, 06_56_23 PM.png	Fundamentals
Architecture & capabilities	Discover the components and integrations	ChatGPT Image Apr 20, 2026, 07_00_55 PM.png	Architecture & capabilities
Real-world scenarios	Practical examples of the platform in action across common business use cases.	ChatGPT Image Apr 20, 2026, 07_04_03 PM.png	Real-world scenarios

# Fundamentals ## Overview The Reconciliation Manager is an AI-powered Digital Worker that matches, substantiates and certifies balance sheet accounts, producing the audit evidence as it works rather than after the close. At launch, it covers two account types: general ledger control and clearing accounts, and bank accounts reconciled against the cash book. Matching is deterministic: rules decide what matches, so the same inputs always give the same result and every match can be explained. Clean, unambiguous matches clear automatically. Items that do not match cleanly are scored, and the ones needing judgement go to a person with the reasoning shown, not a number to accept. Substantiation goes further than matching alone: each balance is proved against its supporting record, and the evidence is captured at the moment the work is done. Match records are held in the platform, and nothing is written back to IFS Cloud until a person approves it. ## Key Benefits **Evidence produced at source:** The audit pack is created by the work itself, not assembled from files and mail threads after the close. By the time an auditor asks, the evidence already exists. **Explanations that hold up:** Matching is deterministic, so the same inputs give the same result every time and every match can be defended, rather than depending on who happened to review it. **Close effort released:** Accountants move from matching lines in spreadsheets to resolving the items that genuinely need judgement, since the routine volume clears unattended. **Proves the hard accounts:** Accounts with no subledger behind them, accruals, provisions, suspense and clearing, get the same rigor as accounts payable and receivable, which tie out on their own. **Nothing posts without sign-off:** Match records are held in the platform. The Reconciliation Manager prepares; a person approves before anything reaches IFS Cloud. ## The Challenge It Solves Not every balance sheet account is equally hard to prove. Payables and receivables have a subledger behind them, an itemized list that can be reported and tied, so that work is largely automated already. Accruals, provisions, suspense and clearing accounts, and contract balances have no such list. The balance is a bare number, and proving what it is made of means reconstructing it from free-text journal entries, month after month. Today, that work happens outside the ledger. Statements are downloaded, pasted into spreadsheets, and matched by hand. Differences are chased by email, so the reason a balance moved ends up in an inbox rather than against the account. The cost is not only the matching itself: the close runs long because the same accounts block it every period, and the audit pack is rebuilt afterward from files and mail threads, at the point when the evidence is hardest to find. ## Before and After #### Before Before the Reconciliation Manager, closing out a balance sheet account requires manual effort at every stage: {% stepper %} {% step %} Download bank and supplier statements, or export ledger transactions, into a spreadsheet outside the ledger {% endstep %} {% step %} Match transactions or statement lines by hand, line by line {% endstep %} {% step %} Chase differences by email, with the reason for any gap living in an inbox rather than against the account {% endstep %} {% step %} Agree a balance once the number ties, with the supporting proof held in separate files {% endstep %} {% step %} Rebuild the audit pack after the close from files and mail threads, when the evidence is hardest to find {% endstep %} {% endstepper %} #### After With the Reconciliation Manager, the same process runs automatically: {% stepper %} {% step %} Every balance sheet account due for the period is scoped at once, across entities and currencies {% endstep %} {% step %} Ledger transactions and incoming bank statements are matched by deterministic rule, so the same inputs always give the same result {% endstep %} {% step %} Unambiguous matches clear automatically; what doesn’t clear is scored, with the reason travelling with it {% endstep %} {% step %} Items needing judgement are sent to a person, with the reasoning already shown {% endstep %} {% step %} Once a reviewer approves a match, the record is written and the balance is substantiated against its supporting evidence {% endstep %} {% step %} The audit pack already exists, because the evidence was produced by the work itself {% endstep %} {% endstepper %} ## How It Works The Reconciliation Manager follows the same core sequence for every account: scope, match, score, review, substantiate. **Scope the period:** At the start of the period, every balance sheet account due is scoped at once, across entities and currencies. **Match by rule:** For general ledger accounts, the Reconciliation Manager reads ledger transactions and compares them field by field, grouping the ones that belong together and pairing a debit against a credit. For bank accounts, statements arrive by email; the worker reads each format and matches statement lines against cash book transactions. **Clear by rule, score the rest:** Unambiguous, rule-based matches clear automatically. Everything else is scored, and the reason for the score travels with it, whether that is a timing difference, a fee, or something that needs a closer look. **Review and approve:** Every group that did not clear automatically is marked for review, so the Reconciliation Manager proposes and the finance user decides. Nothing is written back to IFS Cloud until a person approves it. **Substantiate:** Once a match is approved, the worker moves on to substantiating the balance, proving it against its supporting evidence rather than only confirming that the total ties. ## What Triggers the Reconciliation Manager **Period open:** At the start of an accounting period, the Reconciliation Manager scopes every balance sheet account due across entities and currencies. **Bank statements arriving by email:** A finance user can hand over a statement with a plain-language instruction, one account, one period, with no form to fill in and no rules to configure. The worker loads the statement into IFS Cloud and runs automatic matching against cash transactions. **Unmatched ledger transactions:** On a general ledger account, a list of unmatched transactions triggers the matching process, grouping debits against credits and showing the evidence, transfer identifier, amount, voucher number, voucher date, currency and transaction code, for why each group belongs together. **Items that do not match cleanly:** Anything that cannot be cleared by rule is scored and routed for review, with the reasoning shown alongside it. # Architecture & capabilities ## Overview The Reconciliation Manager is built on two account-matching skills, General Ledger Account Reconciliation and Bank Statement Reconciliation, supported by a shared substantiation and evidence capability that runs underneath both. This article covers those skills, the period-close workflow they share, integration points, and how the system separates automatic clearing from the judgement calls that reach a person. Supplier Statement Reconciliation, Intercompany Reconciliation and Operational Account Reconciliation are on the roadmap as fast-follow skills and are not covered here, since they are not part of the current release. ## Agentic Skills #### General Ledger Account Reconciliation Matches general ledger transactions on control and clearing accounts by rule, so the same inputs always give the same result. Reads ledger transactions and compares them field by field, grouping the ones that belong together and pairing each debit against a credit. Every group carries the evidence for why it was matched: transfer identifier, amount, voucher number, voucher date, currency and transaction code. Items that do not match cleanly are scored, and the ones needing judgement are sent to a person with the reasoning shown. #### Bank Statement Reconciliation Reads bank statements as they arrive by email and parses each bank’s format, matching statement lines to cash book transactions, including the splits and duplicates that typically stall a person. Where a line does not match automatically, the worker explains the remainder as timing, a fee, or an error rather than leaving it unexplained. A finance user can hand over a statement with a one-line, plain-language instruction, one account, one period, with no form to fill in and no rules to configure. #### Balance Substantiation & Audit Evidence Runs underneath both matching skills. Substantiation goes further than matching: each balance is proved against its supporting record, not only that the total ties, and the evidence is captured at the moment the work is done rather than assembled afterward. This skill also enforces certification with segregation of duties, so the preparer and the approver cannot be the same person, and it holds match records in the platform, writing nothing back to IFS Cloud without a person’s approval. #### Reconciliation Workflow The following table outlines the period-close process shared by both matching skills. | **Stage** | **What the System Does** | **Action / Output** | **Channel** | | --------------------- | ----------------------------------------------------------------- | --------------------------------------------------------- | -------------------- | | Period Opens | Scopes every account due for the period across entities | Accounts scoped and queued for the period | IFS Cloud | | Statements Arrive | Bank and supplier statements land through the email channel | Statement content parsed and staged for matching | Email | | Cleared by Rule | Deterministic rules clear the unambiguous, net-zero matches | Matches cleared automatically, no human touch | Platform | | Scored & Escalated | The remainder is scored, with a reason recorded on every proposal | Judgement items routed to a reviewer with reasoning shown | Platform | | Reviewed & Approved | A reviewer approves the matches and settles the judgement calls | Approval recorded; nothing yet written to IFS Cloud | Platform | | Matches Recorded | Approved matches are written back | Match record created in IFS Cloud, reversible | IFS Cloud | | Balance Substantiated | Each balance is proved against its supporting record | Substantiated balance with full evidence trail | IFS Cloud / Platform | ## Integration Points **IFS Cloud:** The ledger of record. The Reconciliation Manager reads ledger transactions and open balances, and writes back only once a match has been approved, recording the reconciliation with its own identifier. **Email:** The intake channel for bank statements. A statement can be sent as an email attachment with a plain-language instruction, and the worker picks it up, loads it, and begins matching without further configuration. **Collaboration (Microsoft Teams):** Used for review and exception handling, surfacing items scored for judgement to the finance user responsible for approving them. **Platform (Agent Studio):** The system of record for match proposals, scores, reasoning, approvals and the audit evidence trail. Match records are held here and only promoted to IFS Cloud once approved. ## Human-in-the-Loop Design The Reconciliation Manager is designed so that unambiguous matches clear without anyone touching them, and human judgement is reserved for the items that genuinely need it. **The system clears automatically when:** * A match is exact and net-zero, a debit against a credit that ties field by field * The rule that governs the account type produces an unambiguous result, so the same inputs give the same result every time **A person reviews and approves when:** * An item does not match cleanly and has been scored rather than cleared, with the reason for the score shown alongside it * A balance is ready to be substantiated against its supporting record and requires sign-off before the record is written * Certification is required, and segregation of duties means the preparer and the approver must be different people In every case, the Reconciliation Manager proposes and the finance user decides. Nothing is written back to IFS Cloud until a person approves it, and every proposal carries the evidence behind it rather than a bare score to accept on faith. ## Feedback and Continuous Improvement Because matching runs on deterministic rules, the same inputs always produce the same result, and every match can be explained and defended the same way each time, rather than depending on who reviewed it. The evidence trail behind every match, score, and approval is captured at the point the work happens, giving finance teams a consistent basis for reviewing decisions and preparing for audit, rather than reconstructing the reasoning after the fact. Certification with segregation of duties, preparer and approver kept apart, is enforced on every reconciliation, reinforcing governance across every close decision. # Real-world scenarios ## Overview This article walks through two scenarios drawn from real reconciliation work: a general ledger reconciliation on a single cash account, and a bank statement reconciliation handed to the worker with nothing more than a one-line email instruction. ### Scenario: General Ledger Account Reconciliation A finance user hands the Reconciliation Manager one cash account, one accounting period, and a list of unmatched transactions. The instruction is plain language: one account, one year, one period. There is no form to fill in and no rules to configure. #### Step 1: Ledger Transactions Read and Compared The Reconciliation Manager reads the ledger transactions for the account and compares them field by field. #### Step 2: Transactions Grouped Transactions that belong together are grouped. Each group pairs a debit against a credit. #### Step 3: Evidence Shown for Every Group The last column of every group shows exactly why the transactions were matched: transfer identifier, amount, voucher number, voucher date, currency, and transaction code. The evidence sits on the screen, so a reviewer does not have to trust a score on its own. #### Step 4: Unmatched Items Listed with a Reason The Reconciliation Manager also lists what it could not match, and why. #### Step 5: Every Group Marked for Review Every group, matched and unmatched, is marked for review. The Reconciliation Manager proposes; the finance user decides. **Result:** A cash account that would otherwise require a person to work through every transaction by hand is grouped, evidenced, and ready for review, with the reasoning behind every group already shown. ### Scenario: Bank Statement Reconciliation Every period, someone has to prove that the bank statement and the cashbook agree, line by line. It is necessary, it is repeatable, and normally it is slow. #### Step 1: Statement Emailed with a One-Line Instruction The finance user emails the statement to the worker’s mailbox with a one-line instruction. No form, no configuration. #### Step 2: Statement Loaded into IFS Cloud The Reconciliation Manager picks up the mail and loads the statement into IFS Cloud. #### Step 3: Automatic Matching Runs The worker runs automatic matching against the cash transactions on the account. #### Step 4: Result Reported Back Under a minute later, it reports back: the statement loaded without errors, and every bank transaction matched a cash transaction. #### Step 5: Reconciliation Created with a Direct Link A reconciliation is created with its own identifier, and the Reconciliation Manager hands over a direct link rather than leaving the finance user to go find it. **Result:** A task that normally takes a person a meaningful chunk of the close, downloading the statement, matching it line by line, and tracking down the record afterward, is completed and handed back with a direct link in under a minute. ## What These Scenarios Illustrate Plain language is enough to start. Neither scenario requires a form or a rules configuration step. One account, one period, and an instruction in ordinary language is sufficient for the Reconciliation Manager to begin work. Evidence sits with the match, not behind it. In both scenarios, the reason a group of transactions was matched, or a statement line was cleared, is shown directly rather than left for a reviewer to take on trust. The worker proposes; the person decides. Every group in the general ledger scenario is marked for review. The Reconciliation Manager does not close anything on its own judgement; it presents its groupings and its reasoning, and the finance user makes the call. Clean results are reported plainly. In the bank statement scenario, a fully matched statement produces a short, direct report and a link, not a lengthy walkthrough. The system scales its output to the complexity of the result. The same underlying process handles both account types. Whether the input is a list of ledger transactions or an emailed bank statement, the worker follows the same shape: read, compare, group or match, evidence, and hand off for review. # FAQ ## Capabilities & functionality **Q: What does the Reconciliation Manager do?** A: The Reconciliation Manager is a Digital Worker that matches, substantiates and certifies balance sheet accounts, producing audit evidence as it works. At launch, it covers general ledger control and clearing accounts, matched by rule, and bank accounts, matched against statements arriving by email. Clean matches clear automatically; anything that doesn’t is scored and sent to a person with the reasoning shown. **Q: Does the Reconciliation Manager reconcile supplier statements or intercompany transactions?** A: Not yet. Supplier Statement Reconciliation, Intercompany Reconciliation and Operational Account Reconciliation are on the roadmap as fast-follow skills. The current release covers General Ledger Account Reconciliation and Bank Statement Reconciliation. **Q: What accounts is the Reconciliation Manager built for?** A: It is built for the balance sheet accounts that are hardest to prove: accruals, provisions, suspense and clearing accounts, and contract balances, which have no subledger behind them. Accounts payable and receivable already tie out through their own subledger and are not the primary target. **Q: How does the Reconciliation Manager handle a bank statement?** A: A finance user can email the statement to the worker’s mailbox with a one-line instruction, one account, one period, no form or configuration required. The Reconciliation Manager loads the statement into IFS Cloud, parses the bank’s specific format, and runs automatic matching against the cash transactions on that account. **Q: What happens to transactions that don’t match automatically?** A: They are scored rather than guessed at, and the reason for the score travels with the item, whether that’s a timing difference, a fee, or something needing closer review. Every scored item is routed to a person along with the reasoning behind it. ## Control & Collaboration **Q: Does the Reconciliation Manager post anything to IFS Cloud on its own?** A: No. Match records are held in the platform, and nothing is written back to IFS Cloud until a person approves it. The Reconciliation Manager proposes; the finance user decides. **Q: What does a finance user see when reviewing a proposed match?** A: The evidence behind the match, not just a score to accept. For a general ledger group, that means the transfer identifier, amount, voucher number, voucher date, currency and transaction code. For a bank statement line, it means the reason the worker scored the match the way it did. **Q: How is segregation of duties enforced?** A: Certification records sign-off with the preparer and the approver kept apart, so the same person cannot both prepare a reconciliation and approve it. **Q: What happens once a match is approved?** A: The Reconciliation Manager writes the match record and moves on to substantiating the balance, proving it against its supporting evidence rather than only confirming the total ties. ## Integration & Technology **Q: What systems does the Reconciliation Manager integrate with?** A: It integrates with IFS Cloud as the ledger of record, reading ledger transactions and open balances and writing back only on approval. It receives bank statements through email, and uses Microsoft Teams for review and exception handling. Match proposals, scores, and the audit evidence trail are held in the platform. **Q: How does the Reconciliation Manager receive bank statements?** A: They’re sent by email to the worker’s mailbox, as an attachment with a plain-language instruction. No separate upload step or configuration is required. **Q: Does the Reconciliation Manager create the reconciliation record automatically?** A: Once a statement is fully matched, yes, a reconciliation is created with its own identifier, and a direct link is handed back to the finance user rather than leaving them to locate the record themselves. ## Security & Reliability **Q: How does matching stay consistent and explainable?** A: Matching is deterministic. Rules decide what matches, so the same inputs always give the same result, and every match can be explained the same way each time rather than depending on who reviewed it. **Q: Can the Reconciliation Manager write an incorrect match to IFS Cloud?** A: Nothing reaches IFS Cloud without a person’s approval first. The worker prepares the match and the evidence behind it; a person reviews and approves before anything is written. **Q: How is the audit trail maintained?** A: Evidence is captured at the point the work happens, not assembled afterward. Every match, score, and approval carries its reasoning, so the audit pack already exists by the time it’s needed rather than being rebuilt from files and email threads under deadline. ## Customization & Performance **Q: Does a finance user need to configure matching rules before using the Reconciliation Manager?** A: No. For a bank statement, a plain-language instruction naming the account and period is enough to begin. There is no form to fill in and no rules to configure up front. **Q: How fast is bank statement reconciliation?** A: In a fully matched scenario, the Reconciliation Manager reports back in under a minute: the statement loaded without errors, every bank transaction matched, and the reconciliation created with a direct link. **Q: What are the two skills available today?** A: General Ledger Account Reconciliation, which matches ledger transactions on control and clearing accounts by rule and evidences every group, and Bank Statement Reconciliation, which parses incoming bank statements and matches them against cash book transactions. Both are supported by a shared substantiation and evidence capability that proves each balance against its supporting record. # Case studies See how our customers are using this Digital Worker to transform their operations. # Supplier Invoicing Manager Invoice processing is detail-intensive work — and the time your team spends chasing approvals, matching POs, and resolving discrepancies is time better spent elsewhere. This knowledge base covers everything you need to get the most out of the Supplier Invoicing Manager, from setup and configuration to day-to-day use. ### Jump right in

		Cover image
Watch & learn	See this Digital Worker in action.	create an image for watch and learn.png	Watch & learn
Core concepts	Essential context for understanding how it all works.	create an image for core concepts_.png	Core concepts
FAQ	Quick answers to common questions.	create an image for frequently asked questions_.png	FAQ
How-to guides	Practical, step-by-step guidance across a range of tasks	create a tile image representing digital worker gu (2).png	How-to guides

		Cover image
Fundamentals	Learn the full scope of what's possible	ChatGPT Image Apr 20, 2026, 06_56_23 PM.png	Fundamentals
Architecture & capabilities	Discover the components and integrations	ChatGPT Image Apr 20, 2026, 07_00_55 PM.png	Architecture & capabilities
Real-world scenarios	Practical examples of the platform in action across common business use cases.	ChatGPT Image Apr 20, 2026, 07_04_03 PM.png	Real-world scenarios

# Fundamentals ## Overview The Supplier Invoicing Manager is an AI-powered Digital Worker designed to free Accounts Payable teams from the manual, repetitive work of processing supplier invoices so they can focus on exceptions and strategic priorities. It automates invoice intake, data extraction, three-way matching against purchase orders and receipts, and exception routing, ensuring invoices are validated accurately and approved quickly, with full audit traceability throughout. By transforming manual, fragmented invoice processing into a structured, automated workflow, the Supplier Invoicing Manager gives AP teams time back for the decisions that require human judgment, while reducing errors, preventing duplicate payments, and improving compliance. ## Key Benefits **Automated invoice intake:** Supplier invoices arriving via email are ingested and parsed automatically, no manual opening of attachments, no re-entering of data, no routing decisions required for clean invoices. **Three-way matching:** Every invoice is validated against the corresponding purchase order and goods receipt note before approval, catching discrepancies in price, quantity, and totals before they reach the ERP. **Intelligent variance interpretation:** The system interprets service charges, taxes, freight, and price or quantity variances, even when part numbers are missing or invoice formats differ across suppliers, rather than simply flagging a mismatch and stopping. **Auto-approval for valid invoices:** Invoices that pass all matching checks within configured tolerance thresholds are approved automatically and the ERP is updated instantly, with the invoice copy attached. No human touchpoint required. **Exception routing with full context:** When a discrepancy is identified, the invoice is routed to the right approver with a clear explanation of the issue, so resolution takes seconds rather than requiring manual investigation. **Audit-ready traceability:** Every decision, action, and communication is recorded with full traceability, ensuring discrepancies and resolutions are documented consistently for compliance and audit purposes. ### The Challenge It Solves Supplier invoicing is often manual, fragmented, and exception-heavy. AP teams must extract invoice data from emails and documents, perform two-way or three-way matching across systems, interpret variances, and resolve discrepancies through back-and-forth communication with suppliers. When invoice lines don't match what was ordered or received, or when service charges and variances are unclear, approvals slow down and exceptions pile up. The result is delayed payment processing, avoidable rework, duplicate invoicing risk, and increased exposure to late payment penalties or missed early payment discounts. Teams spend significant time on tasks that are rules-based and repetitive rather than on the financial analysis and supplier relationship work that requires their expertise. ## Before and After ### Before Before the Supplier Invoicing Manager, processing a supplier invoice requires manual effort at every stage: {% stepper %} {% step %} Process inbox and review invoice PDFs and attachments {% endstep %} {% step %} Manually match the invoice against the purchase order {% endstep %} {% step %} Validate against the goods receipt note {% endstep %} {% step %} Validate pricing and tolerance thresholds {% endstep %} {% step %} Update the ERP {% endstep %} {% step %} Manage exceptions through email back-and-forth {% endstep %} {% step %} Track and follow up on outstanding resolutions {% endstep %} {% endstepper %} This process is slow, inconsistent across team members, and difficult to audit when discrepancies occur. ### After With the Supplier Invoicing Manager, the same cycle runs in three automated steps:
{% stepper %} {% step %} Monitor the AP inbox continuously and extract invoice data {% endstep %} {% step %} Match the invoice against the PO and receipt using three-way matching, validate pricing and tolerances {% endstep %} {% step %} Match the invoice against the PO and receipt using three-way matching, validate pricing and tolerances {% endstep %} {% endstepper %} Clean invoices are processed without any human involvement. Exceptions reach the right person immediately, with everything they need to resolve the issue quickly. ## How It Works The Supplier Invoicing Manager executes a structured automated workflow that handles the complete invoice processing lifecycle. **Invoice Intake and Parsing:** The Digital Worker monitors the AP inbox continuously, capturing supplier invoices as they arrive via email. It ingests the invoice, extracts header and line-level details, invoice number, supplier, amounts, dates, PO references, and line items, and converts unstructured document content into structured financial fields ready for validation. **Three-Way Matching:** The system validates the invoice by comparing it line by line against the corresponding purchase order and goods receipt note. It checks for accuracy in quantity, price, and totals, and identifies any mismatches that fall outside configured tolerance thresholds. **Charge and Variance Interpretation:** When variances are detected, the system interprets them in context, classifying service charges, freight, taxes, and line-level discrepancies, and determining what can be resolved automatically versus what requires human review. This goes beyond simple flag-and-stop logic to provide meaningful context about what the variance represents. **Auto-Approval and ERP Update:** Invoices that pass all checks within tolerance thresholds are approved automatically. The ERP is updated instantly with the invoice status, and the invoice copy is attached to the record. No manual step is required. **Exception Routing:** Invoices with unresolvable discrepancies are routed to the appropriate AP team member with a clear explanation of the issue and the decision options available. Once the reviewer provides their decision, the Digital Worker handles the follow-up, including contacting the supplier directly to flag the discrepancy and request a correction. # Architecture & capabilities ## Overview The Supplier Invoicing Manager is built on four integrated agentic skills coordinated by a Supervisor Agent (AP & Invoice Processing Manager). This article covers the core skills, the full invoice processing workflow, integration points, and how the system determines when to auto-approve versus when to route for human review. ## Agentic Skills The Supplier Invoicing Manager operates through four core skills, each handling a distinct stage of the invoice processing lifecycle. #### Invoice Intake & Parsing Automatically receives supplier invoices from inbound channels and extracts header and line-level details such as invoice number, amounts, dates, PO references, and line items. This skill handles variability in invoice formats across suppliers, PDFs, scanned images, email body content, and converts unstructured input into structured financial fields that can be validated against ERP records. Invoices arriving from multiple channels are captured and prepared for processing without any manual data entry. #### 3-Way Match Validates invoices by matching them against the corresponding purchase order and goods receipt note to ensure accuracy in quantity, price, and totals. The match is performed line by line, using configurable tolerance logic to determine whether a variance falls within acceptable bounds or requires escalation. Where all three records align within tolerance, the invoice is cleared for auto-approval. Where they do not, the mismatch is passed to the Charge & Variance Interpretation skill before any escalation decision is made. #### Charge & Variance Interpretation Identifies service charges, taxes, freight, and any price or quantity variances, even when part numbers are missing or invoice formats differ from what the system expects. Rather than treating all variances as equivalent exceptions, this skill classifies each one: determining what the charge represents, whether it has a legitimate basis, and whether it can be resolved automatically or requires human review. This context-aware interpretation reduces the volume of exceptions that reach AP teams by resolving variances that are explainable within the invoice's context. #### Exception Handling Routes mismatches or unclear cases to the right approver with a clear explanation of the issue, enabling fast resolution without manual investigation. When an exception is escalated, the reviewer receives the invoice details, the specific discrepancy, and the decision options available. Once a decision is made, the Digital Worker executes the follow-up automatically, including contacting the supplier directly to flag the issue and request a correction if needed. All exceptions are routed consistently using defined matching rules and tolerance thresholds, ensuring no discrepancy is handled ad hoc or inconsistently. ### Invoice Processing Workflow The following table outlines the full invoice processing workflow from initial intake through to ERP update and supplier communication. | **Stage** | **What the System Does** | **Action / Output** | **Channel** | | ---------------------------------------- | ----------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | ----------------- | | **Invoice Intake & Parsing** | Parses invoices from email and PDF; extracts supplier, PO reference, amounts, and line items | Structures invoice data, validates completeness, triggers processing workflow | Email / OCR / IFS | | **3-Way Matching** | Compares invoice against PO and goods receipt; identifies mismatches in price, quantity, and delivery | Validates invoice accuracy, auto-matches where possible, flags discrepancies | IFS | | **Exception Detection & Classification** | Identifies mismatches and tolerance breaches; classifies severity and type of issue | Triggers exception workflows, prioritizes by impact, prevents incorrect posting | IFS / Teams | | **Invoice Posting & ERP Update** | Validates final data against rules; ensures readiness for posting | Posts invoice to IFS Cloud, maintains audit trail, ensures financial accuracy | IFS | | **Supplier Communication & Resolution** | Detects need for clarification; identifies missing or incorrect invoice details | Drafts supplier emails, requests corrections, tracks responses | Email | | **Human-in-the-Loop Decision Support** | Identifies ambiguous scenarios; provides context for decisions | Surfaces decision options to reviewer, captures approvals or rejections, resumes automated flow after decision | Teams | ## Integration Points **Email Systems:** Monitors Microsoft Outlook and Gmail inboxes continuously, capturing supplier invoices with PDF and document attachments in real time. **ERP Platforms:** Integrates directly with IFS Cloud to read purchase order and goods receipt records, validate invoice data, post approved invoices, and update invoice status automatically. **Collaboration Platforms:** Uses Microsoft Teams and Slack for exception notifications, approval workflows, and human-in-the-loop decision support. **Documents:** Integrates with IFS Loops and Google Drive for document storage and invoice record management. **Enterprise Applications:** Connects with IFS and other enterprise platforms for cross-system data access and financial record management. ## Human-in-the-Loop Design The Supplier Invoicing Manager is designed so that clean invoices are processed without any human touchpoint, and human judgment is applied only where genuine decisions are required. The system proceeds independently when: * Invoice details match the purchase order and goods receipt within configured tolerance thresholds * Variances are interpretable as legitimate charges (freight, tax, service fees) within tolerance * The invoice has not been processed before (idempotency check passes) * All required fields are present and valid Human review is required when: * Price, quantity, or total mismatches exceed configured tolerance thresholds * Variances cannot be classified or resolved automatically * Invoice references are missing, ambiguous, or cannot be matched to a PO * Duplicate invoice risk is detected * The discrepancy requires a business decision before the supplier can be contacted When an exception is routed for review, the system sends a notification with the invoice details, the specific issue, and the rationale, so the reviewer has everything needed to make a decision without further investigation. Once approved or rejected, the Digital Worker immediately executes the appropriate next step, including any required supplier communication. ## Audit Traceability Every invoice processed by the Supplier Invoicing Manager generates a complete record of the decisions, validations, and actions taken. This includes the matching outcome for each line item, any variances detected and how they were classified, whether the invoice was auto-approved or escalated, the decision made by the human reviewer if applicable, and any supplier communications sent. This structure ensures that AP operations are fully auditable and that discrepancies are resolved with documented rationale rather than informal resolution. # Real-world scenarios ## Overview This article walks through two practical scenarios that illustrate how the Supplier Invoicing Manager handles incoming supplier invoices. The first covers a clean invoice that passes all matching checks and is approved without any human involvement. The second covers an invoice where a discrepancy is detected, a human reviewer is brought in to make a decision, and the Digital Worker handles the supplier follow-up automatically. ### Scenario 1: Clean Invoice, Auto-Approval This scenario covers the most common type of interaction: a supplier submits an invoice that matches the corresponding purchase order and goods receipt note within configured tolerance thresholds. **What triggers it:** A supplier invoice arrives via email to the AP team's monitored inbox, with the invoice attached as a PDF. **What the Digital Worker does:** 1. The Invoice Intake & Parsing skill captures the email, extracts the invoice document, and converts the header and line-level details, invoice number, supplier, amounts, dates, PO reference, and line items, into structured financial fields. 2. The 3-Way Match skill retrieves the corresponding purchase order and goods receipt note from IFS Cloud and compares them against the invoice line by line, checking quantities, prices, and totals. 3. No discrepancies are found. All values fall within configured tolerance thresholds. 4. The invoice is auto-approved. The ERP is updated instantly with the invoice status, and the invoice copy is attached to the record. **Result:** The invoice is fully processed, from email receipt to ERP update, without any manual intervention. The AP team receives visibility into what was processed without needing to touch the invoice themselves. What would have previously required opening the attachment, locating the PO, performing the match manually, and updating the system is handled entirely in the background. ### Scenario 2: Invoice with a Discrepancy, Exception Routing and Supplier Follow-Up This scenario covers an invoice where the amount on the supplier's invoice does not match the corresponding purchase order. The Digital Worker detects the mismatch, routes it to a human reviewer with full context, and handles the supplier communication once a decision is made. #### Step 1: Invoice Received and Parsed A supplier invoice arrives via email. The Digital Worker picks it up immediately, extracts the invoice data, and begins the three-way matching process, comparing the invoice against the purchase order and goods receipt records in IFS Cloud. #### Step 2: Discrepancy Detected During matching, the system identifies that the invoice amount does not match the purchase order. Rather than letting the discrepancy move forward unchecked, or rejecting the invoice outright, the Digital Worker flags the specific mismatch and classifies it for review. The Charge & Variance Interpretation skill assesses the variance in context. If the discrepancy is explainable as a legitimate charge within tolerance (such as a freight fee or tax variance), it may be resolved automatically. In this case, the numbers don't reconcile, and the issue is passed to Exception Handling for human review. #### Step 3: Exception Routed to Reviewer The AP team receives a notification, via Microsoft Teams or the configured channel, with the invoice details and a clear explanation of what doesn't match. The reviewer can see the original PO amount, the invoiced amount, and the specific line items involved. Everything needed to make a decision is surfaced in the notification; no additional investigation is required. #### Step 4: Reviewer Provides Decision The reviewer assesses the situation and provides their decision. This takes seconds rather than the time it would have taken to locate the relevant records, investigate the discrepancy, and compose an email to the supplier manually. #### Step 5: Supplier Communication Handled Automatically Once the reviewer's decision is captured, the Digital Worker takes over. It emails the supplier directly to flag the discrepancy and request a correction, no manual inbox monitoring, no composing of emails from scratch. The communication is generated based on the invoice context and the reviewer's decision, sent immediately, and tracked. **Result:** The discrepancy was caught before it reached the ERP. The reviewer made a fast, informed decision with full context in front of them. The supplier was contacted automatically with a clear, professional message. The entire chain of events, detection, escalation, decision, and supplier communication, is recorded for audit purposes. #### What These Scenarios Illustrate **Clean invoices require no human involvement.** When an invoice matches the PO and receipt within tolerance, the Digital Worker handles extraction, matching, approval, and ERP update end to end. AP teams are informed without needing to act. **Discrepancies are caught before they reach the ERP.** The three-way match happens during the validation stage, before any data is posted. This prevents incorrect financial records from being created and avoids the rework that would follow an incorrect posting. **Variance interpretation reduces unnecessary escalations.** Not every mismatch becomes an exception. The system interprets charges in context, classifying freight, taxes, and service fees, and resolves what it can within configured tolerance before routing anything to a human. **Reviewers get decisions, not investigations.** When an exception does reach a human, it arrives with the relevant details, the specific discrepancy, and the decision options already laid out. Reviewers focus on the judgment call, not on finding the information needed to make it. **Supplier follow-up is handled automatically.** Once a decision is made, the Digital Worker manages the supplier communication, drafting and sending the message based on the invoice context and the decision provided. Teams stay focused on decisions, not admin. **Every action is auditable.** The full chain, intake, matching, variance classification, escalation, decision, and communication, is recorded consistently for every invoice processed. There is no gap in the audit trail regardless of whether the invoice was auto-approved or required human review. # FAQ ## Capabilities & Functionality **Q: What does the Supplier Invoicing Manager do?** A: The Supplier Invoicing Manager is a Digital Worker that automates supplier invoice intake, validation, and exception routing for accounts payable teams. It ingests invoices received by email, parses and extracts the invoice data, validates each invoice against the corresponding purchase order and goods receipt, and either auto-approves the invoice or routes it for human review based on the outcome of that validation. ERP records are updated automatically once an invoice is approved. **Q: What is three-way matching and how does the Digital Worker perform it?** A: Three-way matching is the process of comparing an invoice against both the originating purchase order and the goods receipt to confirm that what was invoiced matches what was ordered and received. The Supplier Invoicing Manager executes this comparison automatically for every invoice it processes. It applies configurable tolerance logic to determine whether any differences fall within acceptable thresholds or require escalation. **Q: How does the Digital Worker handle invoices that do not match the PO or receipt?** A: When the Digital Worker detects a discrepancy that falls outside the defined tolerance thresholds, it flags the mismatch and routes the invoice to an AP team member for review. The reviewer receives the relevant details and context needed to assess the situation. Once they provide a decision, the Digital Worker takes follow-up action, including emailing the supplier to request a correction if needed. **Q: What happens after a valid invoice is approved?** A: Valid invoices are auto-approved without requiring manual touchpoints. The ERP is updated immediately to reflect the approval, and a copy of the invoice is attached to the record. The entire process runs without human intervention for invoices that match within tolerance. **Q: Can the Digital Worker handle service charges and line-item variances?** A: Yes. Charge and variance interpretation is one of the Digital Worker's core capabilities. It classifies variances across line items and determines whether each can be resolved within configured thresholds or requires escalation for review. This prevents unclear charges from stalling the approval process or slipping through unchecked. ### Control & Collaboration **Q: Does a human review every invoice?** A: No. Invoices that match within configured tolerance thresholds are auto-approved without any manual review. Human involvement is reserved for genuine exceptions, specifically invoices where discrepancies, unclear charges, or variances cannot be resolved automatically. This keeps your AP team focused on decisions that require judgment rather than routine processing. **Q: How does the Digital Worker involve AP team members when an exception occurs?** A: When an invoice requires human review, the Digital Worker routes it to the appropriate team member with the relevant details surfaced so they can act quickly and with full context. The reviewer assesses the situation and provides their feedback, after which the Digital Worker handles any required follow-up. **Q: What information does the reviewer receive when an invoice is escalated?** A: Escalated invoices are accompanied by the details needed to understand the discrepancy, including the invoice data, the relevant purchase order and receipt records, and the nature of the mismatch or variance. Reviewers can make informed decisions without having to manually locate supporting documents. **Q: How does the Digital Worker communicate with suppliers?** A: After a reviewer assesses a discrepancy and provides feedback, the Digital Worker sends an email directly to the supplier to flag the issue and request a correction. This removes the need for manual inbox monitoring or back-and-forth coordination by the AP team. ## Integration & Technology **Q: What systems does the Supplier Invoicing Manager integrate with?** A: The Supplier Invoicing Manager integrates with email platforms, enterprise applications including ERP and CRM systems, collaboration tools, and document platforms. This allows it to receive invoices from existing inbound channels and update records in the systems your team already uses. **Q: How does the Digital Worker receive invoices?** A: Invoices are captured from inbound email channels. The Digital Worker monitors these channels, ingests invoices as they arrive, and prepares them for processing automatically. No manual upload or intervention is required to initiate the process. **Q: How does it update the ERP after processing?** A: Once an invoice is approved, the Supplier Invoicing Manager updates the invoice status in the ERP directly. This keeps invoice progress and outcomes visible in your system of record without requiring manual data entry by the AP team. **Q: What collaboration and document platforms are supported?** A: The Digital Worker supports integration with collaboration platforms including Slack and Microsoft Teams, and document platforms including IFS and Google Drive. Refer to your implementation documentation for the full list of supported connectors available in your environment. ## Security & Reliability **Q: How is audit traceability maintained?** A: Every decision the Digital Worker makes is traceable. Discrepancies, the context in which they were detected, and how they were resolved are all recorded with full traceability. This means AP teams and auditors can review the rationale behind any approval or escalation after the fact. **Q: What prevents duplicate payments or overpayment?** A: The Digital Worker enforces consistent matching rules and applies idempotency controls to prevent invoices from being processed more than once. Combined with three-way matching against PO and receipt records, this significantly reduces the risk of duplicate payments and overpayment. **Q: How are exceptions handled consistently?** A: Exception routing follows defined tolerance and matching rules configured for your environment. Every invoice is evaluated against the same criteria, regardless of volume or who is processing the queue. Consistent rules also make it easier to audit exception decisions and identify patterns over time. ## Customization & Performance **Q: Can matching rules and tolerance thresholds be configured?** A: Yes. The Supplier Invoicing Manager uses configurable tolerance logic for three-way matching and auto-approval decisions. This allows organizations to define the thresholds that reflect their own procurement and finance policies, rather than applying fixed rules that may not suit their business. **Q: Can the Digital Worker be adjusted to route specific exception types differently?** A: Exception routing is governed by the rules configured in your environment. Invoices that fall outside tolerance thresholds are escalated with decision rationale, allowing your team to define how different types of discrepancies should be handled and by whom. **Q: What agentic skills does the Supplier Invoicing Manager use?** A: The Supplier Invoicing Manager is built on four agentic skills: Invoice Intake & Parsing, 3-Way Match, Charge & Variance Interpretation, and Exception Handling. Each skill handles a distinct part of the invoice processing lifecycle, and together they cover the full path from invoice receipt through to ERP update or supplier follow-up.
# Case studies See how our customers are using this Digital Worker to transform their operations. {% embed url="" %} # Supplier Order Manager Supplier order coordination is complex work — and most of it shouldn't require human effort. This knowledge base covers everything you need to get the most out of the Supplier Order Manager, from setup and configuration to day-to-day use. ### Jump right in

		Cover image
Watch & learn	See this Digital Worker in action.	create an image for watch and learn.png	Watch & learn
Core concepts	Essential context for understanding how it all works.	create an image for core concepts_.png	Core concepts
FAQ	Quick answers to common questions.	create an image for frequently asked questions_.png	FAQ
Case studies	Learn from real world examples of success.	create an image for case studies_ (1).png	Case studies
How-to guides	Practical, step-by-step guidance across a range of tasks	create a tile image representing digital worker gu (2).png	How-to guides

		Cover image
Fundamentals	Learn the full scope of what's possible	ChatGPT Image Apr 20, 2026, 06_56_23 PM.png	Fundamentals
Architecture & capabilities	Discover the components and integrations	ChatGPT Image Apr 20, 2026, 07_00_55 PM.png	Architecture & capabilities
Real-world scenarios	Practical examples of the platform in action across common business use cases.	ChatGPT Image Apr 20, 2026, 07_04_03 PM.png	Real-world scenarios

# Fundamentals ## Overview The Supplier Order Manager is an AI-powered Digital Worker designed to free procurement teams from the administrative work of managing supplier confirmations so they can focus on strategic sourcing, category management, and the relationship building that drives competitive advantage. This intelligent solution handles the complex workflow of confirming purchase orders from suppliers, detecting discrepancies, and updating system records with minimal manual intervention. By converting reactive, manual supplier management into a proactive, exception-driven process, the Supplier Order Manager gives procurement professionals time back for the work that requires human judgment, negotiation skills, and strategic thinking. ## Key Benefits **Automated confirmation handling:** Supplier confirmations are parsed, validated against purchase orders, and processed without manual review for clean matches, eliminating the need to open every email and compare it against the system manually. **Proactive exception detection:** Discrepancies in price, quantity, or delivery dates are caught automatically and surfaced to the right person with full context, rather than being discovered late or missed entirely. **Consistent supplier communication:** All outbound communications, confirmations, reminders, clarifications, are drafted and sent through a standardized, professional process rather than relying on individual team members to manage their own inboxes. **Real-time visibility:** Teams have an up-to-date view of confirmation status across all open purchase orders without manually chasing responses or checking system records. **Effortless scalability:** The automated process handles growing confirmation volume without additional manual effort, eliminating bottlenecks during periods of high order activity. ## The Challenge It Solves Managing supplier orders is highly manual, fragmented, and reactive. Procurement teams spend significant time tracking confirmations, validating changes to price, quantity, and delivery dates, and following up with suppliers across emails and ERP systems. This leads to delays, missed discrepancies, and limited visibility into order status, ultimately impacting supply continuity and operational efficiency. In practice, teams are doing tasks like opening supplier emails, reviewing attached PDFs, comparing details against purchase orders in IFS Cloud, identifying any differences, sending clarification or follow-up emails, and then manually updating the ERP once changes are agreed. When suppliers propose modified terms, the process involves even more back-and-forth before anything gets resolved. Multiply this across dozens or hundreds of confirmations per day and the administrative burden becomes a significant drain on procurement capacity. ## Before and After ### Before Before the Supplier Order Manager, processing a supplier confirmation requires manual effort at every step: {% stepper %} {% step %} Process inbox and review purchase order confirmation emails and attachments {% endstep %} {% step %} Compare confirmation against the purchase order in IFS Cloud {% endstep %} {% step %} Identify any discrepancies {% endstep %} {% step %} Send follow-ups or clarifications to the supplier {% endstep %} {% step %} Track supplier responses {% endstep %} {% step %} Update the ERP with any approved changes {% endstep %} {% step %} Send confirmation back to the supplier {% endstep %} {% endstepper %} This manual process leads to delayed confirmations, frequent back-and-forth emails, poor visibility into open order status, and error-prone ERP updates. ### After With the Supplier Order Manager, the same cycle is handled in three automated steps: {% stepper %} {% step %} Monitor inbox continuously and extract purchase order-related data {% endstep %} {% step %} Match confirmations with ERP records, detect and flag any changes to a human for review {% endstep %} {% step %} Handle supplier communication and update the ERP with confirmed changes {% endstep %} {% endstepper %} Exact-match confirmations require no human involvement at all. Exceptions are routed immediately with all the context needed to make a fast, informed decision. ## How It Works The Supplier Order Manager executes a six-step automated workflow that covers the complete purchase order confirmation cycle. **Information Extraction:** The Digital Worker extracts all relevant information from the supplier's purchase order confirmation, whether it arrives as a PDF, image, or through EDI. An AI-powered extraction tool converts unstructured document data into structured format with key-value pairs. **Details Retrieval:** A specialized Purchase Order Details sub-agent retrieves the original purchase order from IFS Cloud, including site information, line items for each part number, quantities, prices, delivery dates, and all relevant metadata. **Intelligent Comparison:** The system performs a line-by-line comparison between the supplier's confirmation and the original purchase order. It checks for duplicate requests, uses LLM-based comparison to identify any differences, and determines whether to confirm as-is or flag discrepancies for review. **Exception Routing:** When discrepancies are detected, the system triggers a human approval workflow. A detailed notification is sent via Microsoft Teams or the configured channel, outlining exactly what changed and waiting for explicit approval before proceeding. **System Update:** Once approved, the Digital Worker automatically updates all relevant purchase order line items in IFS Cloud to reflect the confirmed changes. **Supplier Communication:** The system drafts and sends confirmation back to the supplier, maintaining consistent, professional communication throughout. ## Purchase Order States When a purchase order is created in IFS Cloud, it begins in a planned state. Once sent to the supplier, it moves to a released state. The Supplier Order Manager monitors continuously for incoming supplier responses and processes them as they arrive, handling both types of supplier response: * **Full acknowledgment:** The supplier agrees with all terms and confirms as submitted * **Modified acknowledgment:** The supplier proposes changes such as reduced quantities, adjusted prices, or revised delivery dates
# Architecture & capabilities ## Overview The Supplier Order Manager is built on a hierarchical AI agent architecture with a set of integrated agentic skills coordinated by a Supervisor Agent. This article covers the core skills, the agent architecture, the full supplier order management workflow, integration points, and how the system determines when to proceed independently versus when to involve a human. ## Agentic Skills The Supplier Order Manager operates through five core skills, each handling a distinct part of the supplier order management process. #### Email Parsing Reads and understands supplier emails and attachments to extract confirmations, changes, and intent without manual review. This skill processes incoming messages regardless of format, plain text, PDF attachments, images, and converts unstructured supplier communication into structured data that can be compared against purchase order records in IFS Cloud. #### Supplier Coordination Keeps suppliers aligned by tracking responses, follow-ups, and next steps across ongoing purchase orders. This skill maintains visibility into which confirmations are outstanding, which have been received, and which require further action, ensuring nothing falls through the cracks across a high volume of open orders. #### Supplier Communication Manages structured, consistent communication with suppliers to prevent delays, ambiguity, and missed information. This skill ensures all supplier-facing messages follow a standardized approach, reducing the variability that comes from individual team members managing their own inboxes and writing their own emails. #### Email Composition Drafts clear, professional emails for confirmations, reminders, and clarifications based on the current purchase order context. Rather than starting from a blank page, this skill generates contextually appropriate messages ready for review and sending, whether acknowledging a clean confirmation, requesting clarification on a discrepancy, or following up on an overdue response. #### Supplier Negotiation Supports back-and-forth discussions on dates, quantities, or commercial terms by capturing proposed changes, highlighting trade-offs, and escalating when approval is needed. This skill handles the structured aspects of negotiation, documenting what's been proposed, what the impact is, and what decision is required, so that human reviewers can focus on the judgment call rather than the administrative tracking. ## Agent Architecture The Supplier Order Manager uses a hierarchical agent structure designed for reliability, scalability, and transparency. **Main Agent (Supervisor):** The Supplier Order Manager serves as the orchestration layer, overseeing the entire process from email receipt through system update and supplier confirmation. It directs the appropriate skills based on what each incoming communication requires. **Instruction Handlers:** Specialized language models handle specific tasks such as data extraction from documents and intelligent comparison of parts and pricing. These handlers provide the AI reasoning capability that makes the system adaptable to various document formats and supplier communication styles. **Sub-Agents:** Dedicated AI skills focus on purchase order details retrieval and confirmation management. These sub-agents have deep expertise in their specific domains, ensuring accurate execution of critical workflow steps. ## Tools and Integration Layer The Supplier Order Manager uses three core configurable tools: * **Extract Order Confirmation Details:** an instruction handler that extracts structured data from supplier purchase order confirmations * **Compare Parts Tool:** an LLM-based tool that compares extracted parts with system records, identifying mismatches in quantities, prices, and attributes * **Teams Integration:** configurable channels for agent communication and human-in-the-loop approval workflows ### Supplier Order Management Workflow The following table outlines the full workflow from initial confirmation receipt through to ERP update and supplier communication. | **Stage** | **What the System Does** | **Action / Output** | **Channel** | | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | ----------------- | | **Supplier Confirmation Parsing & Intent Detection** | Parses supplier confirmations from PDF or email; extracts PO, line items, quantities, dates, and pricing; detects whether the response is a full confirmation, partial confirmation, or rejection | Structures confirmation data against PO, classifies confirmation type, triggers next workflow step | Email / OCR / IFS | | **PO Matching & Change Detection** | Compares confirmation against PO line-by-line; detects changes in price, quantity, and delivery date; identifies missing or extra lines | Highlights discrepancies automatically, classifies changes as acceptable or exception, routes to appropriate workflow | IFS / Teams | | **Exception Detection & Prioritization** | Identifies critical vs. non-critical mismatches; applies tolerance rules for price, date, and quantity; evaluates fulfilllment impact | Triggers exception workflows, notifies buyers for decision, prevents incorrect confirmations from posting | Teams / Email | | **Supplier Communication & Follow-ups** | Detects missing confirmations or delayed responses; identifies need for clarification or negotiation | Sends automated follow-ups and reminders, drafts clarification emails, initiates negotiation flows | Email | | **Confirmation Posting & ERP Updates** | Validates confirmed data against business rules; ensures readiness for ERP update | Posts confirmed updates to IFS Cloud, maintains audit trail of changes, ensures data consistency | IFS | | **Human-in-the-Loop Decision Support** | Identifies ambiguous or conflicting scenarios; provides context for decision-making | Surfaces clear options to reviewer, highlights risks and impact, captures decision and resumes automated flow | Teams / IFS | ## Integration Points **Email Systems:** Monitors Microsoft Outlook and Gmail inboxes continuously, processing incoming supplier communications in real time. **ERP/SCM Platforms:** Integrates directly with IFS Cloud and other enterprise resource planning systems to read purchase order details and write updates automatically. **Collaboration Platforms:** Uses Microsoft Teams, Slack, OneNote, and Google Drive for notifications, approvals, and documentation. **CRM Systems:** Connects with Salesforce, HubSpot, and Qoncierge to maintain supplier relationship context and history. **Document Processing:** Handles PDFs, images (JPG, PNG), and text-based confirmations with high extraction accuracy. ## Human-in-the-Loop Design The Supplier Order Manager is designed so that routine confirmation processing happens automatically and human judgment is applied to decisions that genuinely require it. The system proceeds independently when: * Supplier confirmations match purchase orders exactly across all line items * Communications follow established patterns and require no exception handling * Transactions are low-risk and fall within approved parameters Human approval is required when: * Any discrepancy exists in dates, quantities, or pricing * High-value or high-impact purchase orders are involved * Cases require business judgment that falls outside defined rules * Outbound supplier communications are ready to be sent When an exception is detected, the system sends a detailed notification via Microsoft Teams with complete context, presents a clear comparison showing exactly what changed and why it matters, waits for explicit approval before taking any action, and executes the approved changes immediately once confirmation is received. ## Testing and Validation The platform includes an agent playground for testing and development. Teams can simulate incoming emails with PDF attachments, test responses to various scenarios, review detailed debug logs, and validate extraction accuracy and comparison logic before deploying to production.
# Real-world scenarios ## Overview This article walks through two practical scenarios that illustrate how the Supplier Order Manager handles incoming supplier confirmations. The first covers a clean confirmation where all details match the purchase order exactly. The second covers a confirmation where the supplier has proposed a change to the delivery date, requiring human review before the system can proceed. ### Scenario 1: Exact Match Confirmation This scenario covers the most common type of interaction, a supplier confirms they can fulfilll all line items at the agreed quantities, prices, and delivery date. Everything aligns with the purchase order on record. **What triggers it:** A supplier sends a purchase order confirmation via email to the order manager's monitored inbox. **What the Digital Worker does:** 1. The Email Parsing skill detects the incoming message, reads the email and any attached documents, and extracts all relevant confirmation details. 2. The system retrieves the original purchase order from IFS Cloud, line items, quantities, prices, delivery dates, and all associated metadata. 3. A line-by-line comparison is performed between the supplier's confirmation and the purchase order. No discrepancies are found. 4. The order is confirmed automatically in IFS Cloud without any manual intervention. 5. The procurement team receives a notification via Microsoft Teams that the purchase order has been confirmed. **Result:** The entire confirmation process, email receipt, data extraction, PO comparison, ERP update, and team notification, happens automatically. The procurement team is informed without having to open the email, locate the purchase order, or make a single manual update. What would typically take 10 to 15 minutes of manual processing is completed in seconds. ### Scenario 2: Confirmation with a Delivery Date Change This scenario covers a confirmation where the supplier cannot meet the original delivery date and is proposing a revised schedule. The details are otherwise correct, quantities and pricing match, but the date change needs to be reviewed before the order can be updated. #### Step 1: Confirmation Received and Parsed The supplier sends their purchase order confirmation via email. The Digital Worker picks it up immediately, reads through the email and attached document, and begins extracting and comparing all details against the purchase order in IFS Cloud. #### Step 2: Discrepancy Detected During the line-by-line comparison, the system identifies that the supplier has proposed a delivery date that differs from the original purchase order. Rather than posting the change automatically or ignoring it, the Digital Worker flags it as an exception requiring human review. A notification is sent to the procurement team via Microsoft Teams. The message includes full context: the original delivery date, the supplier's proposed date, and all other order details, so the reviewer has everything they need to make a decision without doing any additional investigation. #### Step 3: Human Decision Made The team member reviews the notification in Teams and approves the revised delivery date. This decision takes seconds rather than the time it would have taken to manually process the email, identify the discrepancy, determine the impact, update the system, and communicate back to the supplier. #### Step 4: ERP Updated and Supplier Notified The Digital Worker executes the approved change immediately. The purchase order in IFS Cloud is updated with the revised delivery date, with all other line item details unchanged. A confirmation is sent back to the supplier, and the team receives confirmation that the order has been updated. **Result:** The Digital Worker caught the delivery date change during validation, surfaced it to the right person with complete context, and updated the system the moment a decision was made. The procurement team stayed informed and in control without being buried in the processing work surrounding the decision. ## What These Scenarios Illustrate **Clean confirmations are fully automated.** When a supplier's confirmation matches the purchase order exactly, no human involvement is needed at any stage. The system handles extraction, comparison, ERP update, and team notification end to end. **Changes are caught before they reach the ERP.** Discrepancies in delivery dates, quantities, or pricing are identified during the comparison stage, before anything is written to IFS Cloud. This prevents incorrect data from entering the system and avoids the rework that would follow. **Exceptions come with full context attached.** When the system routes something for human review, it includes everything the reviewer needs to make a fast, informed decision: what changed, what the original value was, and what the impact is. Reviewers are making decisions, not investigating. **Approval triggers immediate action.** Once a decision is made in Teams, the Digital Worker executes it without delay. There is no separate step to update the system or notify the supplier, those happen automatically as part of the approval flow. **Outbound supplier communication is handled consistently.** Rather than individual team members drafting their own emails, confirmations and responses are generated by the system based on the purchase order context, ensuring professional, consistent communication at every touchpoint. # FAQ ### Capabilities & functionality **Q: What does Supplier Order Manager do for me?** A: It automatically manages supplier communications, updates purchase orders, handles delays & sends confirmations, saving you from repetitive email & data entry tasks. **Q: How quickly does Supplier Order Manager process supplier emails?** A: Updates are processed in near real-time. As soon as a supplier email arrives, Supplier Order Manager scans it, extracts key data & updates your ERP, often before you even see the message. **Q: How does Supplier Order Manager know what to update?** A: It parses supplier messages (emails, PDFs, attachments) to extract order details & cross-checks them with your ERP purchase orders. **Q: What if a supplier sends multiple changes in one email?** A: Supplier Order Manager can handle combined updates, such as a quantity change & a delivery date shift, applying them accurately & leaving a record of the original values. **Q: Does Supplier Order Manager work with international suppliers?** A: Yes. It supports multilingual email parsing & can handle multiple currencies, units of measure & tax configurations based on ERP data. ### Control & collaboration **Q: Will suppliers notice they're dealing with a digital worker?** A: No. Supplier Order Manager uses standard business communication templates, so messages look & feel like they're coming from your procurement team. **Q: Can I override Supplier Order Manager's decisions?** A: Yes. You can configure thresholds for automatic action & set rules for when human approval is required, such as price changes beyond a certain percentage. **Q: What happens if a supplier doesn't reply?** A: Supplier Order Manager automatically follows up with chaser emails. If no response is received after a defined period, it escalates the issue to a human user. **Q: How will this affect my role?** A: Instead of spending time updating spreadsheets & chasing emails, you'll focus more on supplier relationships, negotiations & strategic sourcing. ### Integration & technology **Q: How does Supplier Order Manager connect to ERP systems?** A: It uses standard APIs & projections to validate & update orders. **Q: Which APIs does Supplier Order Manager rely on?** A: Key APIs handle purchase order confirmations, updates with differences & document retrieval to ensure accurate, validated ERP updates. **Q: Can Supplier Order Manager integrate with tools beyond ERP?** A: Yes. It can connect with communication platforms such as Outlook, Gmail, & Teams to centralize supplier interactions. ### Security & reliability **Q: How are audit trails maintained?** A: Every action, including: email sent, order updated & confirmation logged, is written back to ERP history. Entries are stamped with the digital worker's ID, providing transparency & accountability. **Q: How does Supplier Order Manager handle data security?** A: Sensitive supplier & order data remains within your ERP & email environment. Supplier Order Manager uses secure API calls & logs all transactions for compliance. **Q: What happens if ERP is down?** A: Supplier Order Manager queues updates & retries once ERP connectivity is restored. Critical communications can still be drafted & logged, then reconciled once systems are back online. ### Customization & performance **Q: Can Supplier Order Manager adapt to our custom ERP workflows?** A: Yes. The technical design allows for configuration of custom rules, triggers, & validations to align with your ERP instance. **Q: How is performance measured?** A: Typical KPIs include the percentage of automated POs processed, processing time reduction, error rate & hours saved per week. These metrics are tracked through dashboards. # Case studies See how our customers are using this Digital Worker to transform their operations. {% embed url="" %} # Service Closure Manager Closing out service work takes focus, but repetitive validation before invoicing shouldn't slow teams down. This knowledge base guides you through using the Service Closure Manager, from initial setup to handling service work closeout efficiently in daily operations. ### Jump right in

		Cover image
Watch & learn	See this Digital Worker in action.	create an image for watch and learn.png	Watch & learn
Core concepts	Essential context for understanding how it all works.	create an image for core concepts_.png	Core concepts
FAQ	Quick answers to common questions.	create an image for frequently asked questions_.png	FAQ
How-to guides	Practical, step-by-step guidance across a range of tasks	create a tile image representing digital worker gu (2).png	How-to guides

		Cover image
Fundamentals	Learn the full scope of what's possible	ChatGPT Image Apr 20, 2026, 06_56_23 PM.png	Fundamentals
Architecture & capabilities	Discover the components and integrations	ChatGPT Image Apr 20, 2026, 07_00_55 PM.png	Architecture & capabilities
Real-world scenarios	Practical examples of the platform in action across common business use cases.	ChatGPT Image Apr 20, 2026, 07_04_03 PM.png	Real-world scenarios

# Fundamentals ## Overview The Service Closure Manager is an AI-powered Digital Worker that validates completed service work before it progresses to invoicing in IFS Cloud. It reviews the materials, returns, and time reported against a service request task, determines whether that work is ready for invoicing, and supports scope-level invoice preview creation and approval, all while keeping a person in control of the outcome. The worker processes individual service request tasks, running every applicable validation check before determining invoice readiness. At the request scope level, it validates every task within the scope and only creates an invoice preview once every task in that scope has passed the required checks. Validation outcomes, exceptions, invoice previews, and approval decisions are all routed through a configured communication channel for human review. ## Key Benefits **Nothing reaches invoicing unchecked:** Every request task is validated against material, return, and time reporting checks before it can progress toward an invoice. **Consolidated readiness, not a single pass/fail:** Material, return, material usage, and time reporting results are consolidated into one invoice readiness assessment per task, and a successful result on one check never overrides a failure on another. **Nothing invoices with an unresolved task in the scope:** A scope-level invoice preview is only created once every request task within that scope has passed the required validations. One failing task holds the whole scope. **A person always approves the invoice:** The worker creates the invoice preview; explicit user approval is required before the service invoice progresses. **The underlying record is never altered automatically:** Validation failures do not modify or override the reported service information. The person responsible corrects the record where they normally would, in IFS. ## The Challenge It Solves Completed service work commonly reaches invoicing without a consistent check on whether it was reported correctly. Materials used, returns expected, and time reported against a job can go unverified against what was actually planned, and inconsistencies are often only caught after an invoice has already gone out or been disputed. Checking this by hand, one task at a time, doesn’t scale with volume, and a request scope with even one incomplete or inconsistent task can still progress toward invoicing if nobody catches it. The result is unbilled work, inconsistent records, and invoice disputes that trace back to a task record that never should have been considered ready. ## Before and After ### Before Before the Service Closure Manager, validating a completed service request scope requires manual effort at every stage: {% stepper %} {% step %} Review each completed request task by hand, checking the description, performed work, actions, remarks, and service notes {% endstep %} {% step %} Manually compare reported materials and returns against what was planned for the job {% endstep %} {% step %} Manually compare reported personnel time against planned hours and the cost lines they generated {% endstep %} {% step %} Judge, task by task, whether the work is ready to invoice {% endstep %} {% step %} Check every task in the request scope before creating an invoice preview, since one incomplete task can otherwise slip through {% endstep %} {% step %} Review and approve the invoice manually, with no consolidated record of what was checked {% endstep %} {% endstepper %} ### After With the Service Closure Manager, the same process runs automatically: {% stepper %} {% step %} A completed request task is retrieved along with its description, performed work, actions, remarks, and service notes {% endstep %} {% step %} Material and return validation compares reported usage, quantities, and related cost lines against the completed work {% endstep %} {% step %} Time reporting validation compares reported personnel hours against planned hours and the cost lines they generated {% endstep %} {% step %} Material, return, and time reporting results are consolidated into an invoice readiness assessment for the task {% endstep %} {% step %} Every task in the request scope is validated before an invoice preview is created; one failing task holds the whole scope {% endstep %} {% step %} Once every task in scope passes, an invoice preview is created and a person reviews and explicitly approves it {% endstep %} {% endstepper %} ## How It Works The Service Closure Manager follows a consistent sequence for every request task and the scope it belongs to. **Service Task Validation:** A completed request task is retrieved, along with its description, performed work, actions, remarks, and service notes. The worker assesses the task context to determine whether materials and returns are expected, then runs every applicable validation check before determining invoice readiness. **Material & Return Validation:** Planned and reported materials are compared against the completed service work. Material quantities and related cost lines are validated, and return records are checked where a return is expected. Missing or inconsistent material or return information is identified. **Time Reporting Validation:** Planned and reported personnel hours are compared, and reported time is validated against the cost lines it generated. Variances and mismatches are identified, and invoice readiness is prevented where time reporting does not meet the required validation criteria. **Invoice Readiness Validation:** Material, return, material usage, and time reporting results are consolidated into a final readiness assessment for the task. All applicable checks are processed even where an earlier check has already failed, and a task cannot progress to invoicing unless it passes every required validation. **Scope-Level Invoice Validation:** Every request task associated with the scope is retrieved and validated. An invoice preview is only created once every task in the scope has passed its required validations. **Invoice Preview & Approval:** An invoice preview is created at the request scope level for a successfully validated scope. The service invoice does not progress until a person explicitly approves it. **Exception & Human-in-the-Loop Review:** Validation failures are presented with the underlying reason through the configured communication channel, for a person to review and act on. Invoice approval always requires explicit user confirmation. ## What Triggers the Service Closure Manager **A completed request task:** The worker processes individual service request tasks as they are completed, retrieving their details and running the applicable validation checks. **A request scope ready for invoice review:** Once every task in a scope has been validated, the scope is checked to determine whether an invoice preview can be created. **A failed validation:** Missing or inconsistent material, return, or time reporting information prevents a task from being considered ready for invoicing, and routes the outcome to a person for review. **An invoice preview awaiting approval:** Once a scope-level invoice preview has been created, it holds until a person gives explicit approval before the service invoice progresses. # Architecture & capabilities ## Overview The Service Closure Manager is built on five capabilities that together take a completed service request task from initial review through to an approved invoice: Service Task Validation, Material & Return Validation, Time Reporting Validation, Invoice Readiness & Scope-Level Validation, and Invoice Preview & Approval. This article covers those capabilities, the validation workflow they share, integration points, and how the system keeps a person in control of every invoice approval decision. ## Agentic Skills #### Service Task Validation Reviews a completed request task and coordinates the required validation checks before the work can progress to invoicing. Retrieves the task’s description, performed work, actions, remarks, and service notes, and assesses the task context to determine whether materials and returns are expected. Every applicable check is executed before invoice readiness is determined, and detailed validation results are produced for each task processed. #### Material & Return Validation Validates planned and reported material usage against the completed service work, comparing quantities and related cost lines. Return records are validated where a return is expected based on the task context. Missing or inconsistent material or return information is identified, and material and return expectations are evaluated using the available task descriptions, performed work, remarks, service notes, and related transaction data. #### Time Reporting Validation Compares planned and reported personnel time and validates the corresponding cost lines, identifying missing or inconsistent time reporting. Time variances and mismatches are surfaced directly, and invoice readiness is prevented where time reporting does not meet the required validation criteria. #### Invoice Readiness & Scope-Level Validation Consolidates material, return, material usage, and time reporting results into a final readiness assessment for each task. All required validation checks are processed even where an earlier check has already failed, since a successful result from one validation never overrides a failure from another. At the request scope level, every associated task is retrieved and validated, and invoice progression is prevented whenever one or more tasks in the scope do not meet the required criteria. #### Invoice Preview & Approval Creates an invoice preview for a request scope once every task within it has passed validation, at the scope level rather than the individual task level. The service invoice does not progress until a person gives explicit approval following their review. ### Validation Workflow The following table outlines the process from a completed task through to an approved invoice. | Stage | What the System Does | Action / Output | Channel | | ---------------------------- | ---------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | --------------------- | | Task Retrieved | Retrieves the completed task’s description, performed work, actions, remarks and service notes | Task context assessed for material and return expectations | IFS Cloud | | Material & Return Checked | Compares reported material usage and returns against the completed work | Missing or inconsistent material/return information identified | IFS Cloud | | Time Reporting Checked | Compares reported personnel hours against planned hours and cost lines | Time variances and mismatches identified | IFS Cloud | | Invoice Readiness Determined | Consolidates material, return and time reporting results | Task marked ready or not ready for invoicing | IFS Cloud | | Scope Validated | Validates every task associated with the request scope | Invoice preview creation allowed only if every task passed | IFS Cloud | | Invoice Preview Created | Creates a scope-level invoice preview for a fully validated scope | Preview presented for review | Communication Channel | | Approved | A person reviews and explicitly approves the preview | Service invoice progresses | IFS Cloud | **Exception path:** When a task fails one or more required validations, the failure is presented with its underlying reason through the configured communication channel. The worker does not modify or override the reported service information; the person responsible corrects the record in IFS, and the task is validated again. ## Integration Points **IFS Cloud:** The system of record for service requests, request tasks, cost and sales lines, and service invoicing. The Service Closure Manager reads task descriptions, performed work, remarks, service notes, planned and reported material and time data, and cost and sales lines, and supports invoice preview creation and approval within IFS Cloud’s invoicing process. **Configured communication channel:** Used for human-in-the-loop interactions: validation outcomes, exceptions, invoice previews, and approval actions are all routed through it for review. ## Human-in-the-Loop Design The Service Closure Manager is designed so that validation runs automatically across every task and scope, while the decisions that matter, correcting a failed record and approving an invoice, stay with a person. The system flags for review when: * A task fails material, return, or time reporting validation, with the underlying reason shown * One or more tasks in a request scope fail to meet the required validation criteria, holding invoice preview creation for the whole scope A person acts when: * A validation failure needs the underlying service record corrected in IFS, since the worker never modifies or overrides reported information automatically * An invoice preview has been created and is awaiting review, since the service invoice cannot progress without explicit user approval ## Feedback and Continuous Improvement Validation checks are deterministic: the same data produces the same result every time a task is evaluated, so a corrected record produces a consistent, repeatable outcome once it is re-checked. Because the worker never modifies the underlying reported service information itself, the person responsible for the record makes the correction exactly where they normally would in IFS, and the task is evaluated again against the same checks. This keeps the validation logic consistent and predictable across every task and every request scope. # Real-world scenarios ## Overview 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. ### Scenario: Clean Scope, Straight to Approval 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. #### Step 1: Task Context Retrieved 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. #### Step 2: System Records Reconciled Underneath that, the worker reconciles the system records: what was planned, what was actually used and costed, and what came back as a return. #### Step 3: Sales Lines and Hours Checked 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. #### Step 4: Every Task Passes Every task under the scope passes its material, return, and time reporting checks. #### Step 5: Invoice Preview Created With every task in the scope validated, an invoice preview is created and sent for review. #### Step 6: Person Approves A person approves the invoice preview, and it proceeds. 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. ### Scenario: Scope Held for Correction The same process, but this time a check does not clear. #### Step 1: Scope Completed, Validation Runs 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. #### Step 2: A Check Fails One of the checks does not clear. Something is outside the configured tolerance. #### Step 3: Result Delivered in Plain Language 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. #### Step 4: No Invoice Preview Created No invoice preview is created, and that is deliberate. Nothing progresses toward invoicing on a scope that has not reconciled. #### Step 5: Record Corrected in IFS Someone corrects the data in IFS, exactly where they would normally. #### Step 6: Scope Validated Again 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. **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. ## What These Scenarios Illustrate 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. 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. 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. 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. 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. 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. # FAQ ### Capabilities & functionality **Q: What does the Service Closure Manager do?** A: The Service Closure Manager is a Digital Worker that validates completed service work before it progresses to invoicing in IFS Cloud. It reviews reported materials, returns, and time against a service request task, determines whether the work is ready for invoicing, and supports scope-level invoice preview creation and approval. **Q: What does the Service Closure Manager check on a completed task?** A: It checks planned and reported materials and returns, quantities and related cost lines, and planned and reported personnel time against the cost lines it generated. These results are consolidated into a single invoice readiness assessment for the task. **Q: What happens if one check fails but the others pass?** A: A successful result from one validation never overrides a failure from another. All required checks are processed even after an earlier one has failed, and the task is only considered ready for invoicing once every required validation has passed. **Q: Does the Service Closure Manager create invoices itself?** A: It creates an invoice preview once every task in a request scope has passed the required validations. The service invoice does not progress until a person explicitly approves that preview. **Q: What happens to a request task that fails validation?** A: The underlying reason for the failure is presented for review. The Service Closure Manager does not modify or override the reported service information; the person responsible corrects the record in IFS, in the normal place, and the task is validated again. ### Control & Collaboration **Q: Can an invoice preview be approved automatically?** A: No. Invoice approval always requires explicit user confirmation before the service invoice progresses, regardless of how cleanly the underlying scope validated. **Q: What does a reviewer see when a task fails validation?** A: The validation outcome and the underlying reason for the failure, routed through the configured communication channel, so the person responsible can see exactly what needs correcting and why. **Q: How is an invoice preview reviewed?** A: It is presented through the configured communication channel along with the validation results behind it. A person reviews it and gives explicit approval before the invoice progresses. **Q: Can the Service Closure Manager correct a failed record on its own?** A: No. Validation failures do not automatically modify or override the underlying reported service information. Correcting the record is a human action, taken in IFS where it would normally happen. ### Integration & Technology **Q: What does the Service Closure Manager integrate with?** A: It integrates with IFS Cloud, where service requests, request tasks, cost and sales lines, and service invoicing are configured. Human-in-the-loop interactions, validation outcomes, exceptions, invoice previews, and approvals are routed through a configured communication channel. **Q: What IFS Cloud data does the Service Closure Manager use?** A: Service requests and their associated scopes, completed request tasks with their descriptions, performed work, actions, remarks and service notes, planned and reported material information, material usage and return records, planned and reported personnel time, and the request task’s cost and sales lines. **Q: Is invoice preview creation supported at the individual task level?** A: No. Invoice preview creation and approval are performed at the service request scope level, not for individual request tasks. **Q: What has to be in place in IFS Cloud before the Service Closure Manager can be used?** A: IFS Cloud needs to be configured for service request, request task, cost and sales, and service invoicing processes, and a collaboration or communication channel needs to be set up for validation outcomes, exceptions, invoice review, and human-in-the-loop interactions. ### Security & Reliability **Q: Can the Service Closure Manager change the underlying service record?** A: No. Validation failures never automatically modify or override the underlying reported service information. Every correction is a human action taken directly in IFS. **Q: How consistent is validation across tasks?** A: All applicable validation checks are executed for every task, and a task’s readiness is only determined once every required check has run, even where an earlier one has already failed. The same checks apply to every task processed. **Q: What happens if material or time reporting information is missing?** A: Missing or inconsistent material, return, or time reporting information prevents the affected task from being considered ready for invoicing, and is surfaced for review rather than silently passed. **Q: How is visibility maintained into what was checked and why?** A: Human-in-the-loop interactions provide visibility into validation results and control over invoice approval. Validation failures are presented with the underlying reason for review, and invoice approval requires explicit user confirmation. ### Customization & Performance **Q: What triggers validation on a task?** A: A completed service request task triggers the Service Closure Manager’s review, retrieving the task’s details and running the applicable material, return, and time reporting checks. **Q: How does invoice readiness scale from task to scope?** A: Each task is individually validated and assessed for readiness. At the request scope level, every associated task is retrieved and validated, and a scope-level invoice preview is only created once every task in that scope has passed its required validations. **Q: What are the core capabilities that make up the Service Closure Manager?** A: Service Task Validation, Material & Return Validation, Time Reporting Validation, Invoice Readiness & Scope-Level Validation, and Invoice Preview & Approval. Together, they take a completed task from initial review through to an invoice a person has explicitly approved. # Case studies See how our customers are using this Digital Worker to transform their operations. # Sourcing Manager Sourcing suppliers takes judgment, but repetitive RFQ and quote-handling work shouldn't slow teams down. This knowledge base guides you through using the Sourcing Manager, from initial setup to handling sourcing events efficiently in daily operations. ### Jump right in

		Cover image
Watch & learn	See this Digital Worker in action.	create an image for watch and learn.png	Watch & learn
Core concepts	Essential context for understanding how it all works.	create an image for core concepts_.png	Core concepts
FAQ	Quick answers to common questions.	create an image for frequently asked questions_.png	FAQ
How-to guides	Practical, step-by-step guidance across a range of tasks	create a tile image representing digital worker gu (2).png	How-to guides

--- [Next Page](https://kb.theloops.io/llms-full.txt/1)

IFS Loops Digital Worker Knowledge Base

:inboxes:

:pallet-boxes:

:wand-sparkles:

:circle-play:

:head-side-gear:

:circle-question:

:glasses-round:

:hammer: