More videos on the digital platform

Our JDE Digital Workforce Platform is a real force, and continue to get better.  We own every line of source code.  We have created the MCP servers and we can connect your JDE!  Read more about the functions we are exposing, this is just the beginning

What you're seeing in the demo is a chat interface sitting on top of JD Edwards — built by Fusion5. Instead of navigating menus, running reports, or calling your JDE consultant every time you need a number, you just ask it a question in plain English. The system is broken into expert agents for each module — General Ledger, Accounts Payable, Sales Orders, Procurement, Inventory, Manufacturing, and more — so when you ask about an open purchase order or a supplier's outstanding balance, it knows exactly which JDE application to go to, which tables to query, and what those field names actually mean.

Under the hood it's using Claude to translate your question into real AIS calls — the same Application Interface Services that JDE exposes for programmatic access. When you ask "show me all open vouchers for this supplier," it's not scraping a screen or doing a keyword search. It's constructing a proper data service query against F0411 — the AP ledger — filtering on the right document type, payment status, and supplier address number, then returning those records in a format you can actually read. The same goes for more complex questions. Ask about sales order activity for a branch plant and it'll hit F4211, group by order type, join back to the item master in F4101 if it needs descriptions. It knows the difference between a DD item and a SQL column name, which matters a lot in JDE because the AIS layer only accepts one of them.

For transactional work it goes further than just reading data. The platform uses JDE's Form Service to create, update, and delete records — the same way the JDE web client does. So in the video when you see it entering a journal entry or updating a supplier record, that's a real write operation going through AIS, hitting the same business function validation that a user at their keyboard would hit. Mandatory fields, UDC validation, processing option security — all enforced. And because it authenticates as the logged-in user, your existing JDE security profile applies throughout. Row security, application security, column security — if you can't see it in JDE, the agent can't see it either.

For more complex multi-step workflows — navigating a work order through multiple forms, drilling down from a sales order header into its lines and then into shipment detail — it uses AppStack, which is JDE's stateful form navigation API. That's what lets it behave like someone actually sitting at a JDE session, opening forms, clicking Find, selecting rows, and moving through the form stack. The agent manages the session, knows which form it's on, and can describe what's on screen and what actions are available at each step.

What makes it more than a search tool is that it can aggregate and visualise on the fly. In the video you can see it pulling transaction history, grouping it by period or cost centre or document type, and rendering a bar chart directly in the chat. That's not a canned report — it constructed that aggregation query from scratch based on what you asked, using JDE's aggregation service with the correct column names and grouping logic. No BSVW, no BI tool, no waiting for IT to build a report. You asked, it built it, it showed you.

This part of the demo is showing something a bit different — instead of querying or navigating JDE interactively, it's using orchestrations to do bulk work. Orchestrations in JDE are pre-built workflows that expose a defined input and output contract. They sit on top of business functions and form service calls, and they're designed to be triggered programmatically. What the platform does is give you a conversational way to drive them — so instead of building an integration, writing an BSFN call, or manually entering records one by one, you just describe what you want to do. The spreadsheet mapping example in the video is a good one to focus on. A user drops in a file — maybe a list of new suppliers, a batch of purchase order lines, or a set of price updates — and the agent works out how to get that data into JDE. It reads the column headers, figures out what they map to in the relevant JDE tables, and then calls the appropriate orchestration for each row. That mapping isn't hardcoded. The agent understands that "Supplier Name" maps to Alpha Name in the address book, that "Order Qty" maps to UORG on the purchase order detail, that a date column needs to be in Julian format before it goes anywhere near F4311. It handles the translation so the user doesn't have to think about any of it. Because it's going through orchestrations rather than directly poking tables, it respects all the business rules that are baked into those workflows. Orchestrations run through the AIS layer which means they go through the same processing option security, the same UDC validation, the same approval logic that a normal JDE transaction would. You can't use this to bypass anything — if the orchestration requires a valid branch plant, a valid item number, an authorised user, it'll fail the same way a manual entry would fail. That's intentional. The platform isn't replacing JDE's rules, it's making them accessible through a better interface. For bulk deletions or updates the same principle applies. The agent doesn't run a SQL DELETE against the database — it calls the correct orchestration or form service action for each record, which means soft deletes go through the right logic, audit fields get stamped, and any downstream triggers fire the way they're supposed to. In JDE that matters, because a lot of tables have cascading relationships. Deleting a sales order header without closing its lines correctly will cause problems. The platform handles that by using the same mechanisms JDE itself uses, not by going around them. What this ultimately means for business users is that processes that used to require a developer — writing an interop transaction, building a custom orchestration, setting up a scheduled batch — can now be done conversationally. You describe the task, the agent works out the orchestration to call and the data to pass, and it executes. For IT teams it means less one-off scripting work. For end users it means they can automate their own repetitive tasks without raising a ticket.  

This section of the demo is showing the part of the platform that sits above the individual tools — the agent layer. Not just "ask a question and get an answer," but fully autonomous workers that can be given a task, break it down, and execute it across multiple JDE systems without being hand-held through each step.

The agents themselves are defined as structured markdown documents. Each one has deep knowledge of its module — the relevant tables, the key business objects, the orchestrations it can call, the form service actions it knows how to use, the UBEs it can submit. An AP agent knows the F0411 ledger, the voucher entry process, payment terms, supplier master fields in F0401. A manufacturing agent knows work orders in F4801, bill of material structure in F3002, routing in F3003, how to read job status and move quantities between operations. That knowledge isn't generic AI knowledge — it's embedded directly in the agent definition, tuned specifically for how JDE works and how this business uses it. When you deploy a new agent for a specific team or process, you're giving it a standard operating procedure it will actually follow, written in terms of the JDE objects it will be touching.

The custom agent builder in the web portal is what makes this scalable. Historically, building an agent like this would mean a developer sitting down to write the specification from scratch — mapping out the tables, the orchestrations, the edge cases, the validation rules. What the builder does is take existing material and reverse-engineer a functional specification from it. Feed it a process transcript, a design document, a screen recording transcript, even a set of meeting notes from a requirements session — and it produces a structured agent definition that a developer can review, refine, and deploy. The AI does the heavy lifting of extracting the intent, identifying the relevant JDE objects, and structuring the logic. What would have taken days of analysis takes minutes.

Each agent run is tracked. The platform logs what was executed, what data was touched, how long it took, and whether it succeeded — and you can assign a financial value to each successful execution. If an agent that handles inventory receipting replaces a task that used to take a warehouse user fifteen minutes per GRN, and it processes forty GRNs a day, that's a number. You can see it building over time in the portal. That's not just useful for reporting — it's what makes the conversation with the business about AI adoption concrete. Instead of talking about capability, you're talking about hours saved and cost per transaction.

The inventory receipting example in the video is a good illustration of how this works end to end. A user says in plain English that they've received a shipment — gives a PO number, a quantity, maybe a location. The agent takes that, finds the purchase order in F4311, checks what's outstanding, calls the receipt entry orchestration with the right parameters, and records the GRN against the order. It handles the branch plant, the item number, the receipt date, the unit of measure. If there's a discrepancy — if the quantity received doesn't match what's on the order — it flags it and asks rather than assuming. That's not a scripted workflow. That's an agent reading the context, making decisions, and calling the right JDE processes in the right sequence.

The broader point is that the gap between "we want to automate this process" and "we have an agent running in production" has shrunk significantly. You don't need a six-month integration project. You don't need custom middleware. You need a clear description of what the process does, the right JDE objects mapped out, and an agent definition that puts it all together. The platform handles the authentication, the API calls, the error handling, and the audit trail. The business just needs to describe what it wants done.