Agentforce and SAP: order status through MuleSoft

An Agentforce agent answers order status and availability from SAP S/4HANA by calling an API at the moment the dealer asks. The documented route runs through MuleSoft: a Mule API reads S/4HANA, is enabled for agent topics and actions in Topic Center, published to Exchange and synced into API Catalog in Salesforce, where it becomes an agent action. Everything with a right answer stays deterministic: which dealer may see which order, the availability check, the confirmed date. Those live in SAP and in the API. The model understands the question and words the answer.

How does an Agentforce agent get the order status from SAP?

Through a chain of five links, and each link needs an owner. The Salesforce Developers blog1 describes the order: define topics, actions and instructions in Topic Center while you design the API, build it, publish it to Anypoint Exchange and sync it with API Catalog. Named Credentials and External Services are then created automatically, and the agent calls the API as an action. Flow and Apex can call the same API. The opposite direction, an order from Revenue Cloud handed to SAP, is covered in handing orders to SAP.

For a machine builder the chain looks like this:

1. SAP S/4HANA holds sales orders, schedule lines, deliveries and the availability check. The MuleSoft SAP S/4HANA OData Connector2 supports the OData APIs of S/4HANA Cloud and on-premise and can query entities, invoke remote functions and run batch requests. On the SAP side it needs a communication user assigned to the communication arrangements for exactly the APIs you want to expose.
2. A Mule API turns these OData services into a few operations an agent can use.
3. Topic Center marks operations as agent actions in the OpenAPI spec. According to MuleSoft’s documentation3, only OAS 3.0 and 3.1 are supported, and agent metadata cannot sit in a schema defined with $ref.
4. API Catalog in Salesforce can sync only APIs from Exchange that have managed instances, according to MuleSoft4. In Salesforce’s Agentforce workshop5 you then activate the actions and grant them to users through a permission set.
5. The agent gets the topic and its actions in Agent Builder.

I have not found an official Salesforce reference architecture for Agentforce with S/4HANA, only this generic MuleSoft pattern. So your partner’s design is the architecture, and someone on your side should review it.

Without MuleSoft, an External Service action6 on an OpenAPI document and a named credential is the alternative, for example behind another middleware; Salesforce caps the spec upload at 10 MB. MuleSoft adds the SAP connector, governance rulesets and gateway policies. If it already runs in your company, I would use it. Buying it for one agent rarely pays off. Which middleware fits is part of Salesforce integration.

Which API design makes the agent reliable?

The API an agent calls should be narrower than the API a developer calls. A generic sales order service returns far more than a dealer needs, including internal plant data. Give a model all of that and it will talk about it.

I would design three operations for a dealer agent:

• Order status by SAP order number or the dealer’s purchase order number: overall status, items with open quantity, the next confirmed date, a tracking number once shipped.
• Delivery dates per item, with only the confirmed date and partial deliveries listed separately.
• Availability for material, quantity and desired date: yes or no plus the earliest confirmed date from the SAP availability check. No stock figure, because stock levels are commercial information dealers do not need.

The MuleSoft flags in the OpenAPI spec decide what the agent may do with each field. The External Services blog adds that action and parameter descriptions are taken from the spec. Good descriptions in the OpenAPI document are prompt engineering done once, in a reviewed file.

For developers

Which flags steer the agent?

• x-sfdc/agent/action/publishAsAgentAction makes an operation an action.
• isUserInput marks what the agent asks the dealer for.
• isDisplayable marks what it may show.
• x-sfdc/privacy/isPii switches on the PII service for an operation.

Precompute what dealers ask most. “Overall status” and “next confirmed date” should be fields the API calculates, not conclusions the model draws from ten schedule lines.

Business rules belong in the API and in code

MuleSoft’s own Topic Center documentation says instructions “are nondeterministic, so they shouldn’t include sensitive or deterministic business rules”. I would put that sentence on the first page of every agent design. For order status it covers four things.

Who may see which order. This is the biggest risk. A dealer logged into the portal is a contact on an account, and the account carries the SAP sold-to number. That number must reach the API from the session, set by code, never from the chat. The API returns an order only if the sold-to matches and otherwise answers “not found”, exactly as for an order that does not exist. If the model passes order number and customer number, dealer A reads dealer B’s order by typing a number. Email enquiries are weaker still, because a sender address proves little; more in prompt injection through dealer portals.

Availability and dates. SAP runs the availability check. The agent passes on the confirmed date and never estimates one from stock or lead times. If SAP has no confirmed date, the answer is “not confirmed yet”. A B2B store needs the same rule, see chapter 4 of the B2B Commerce masterclass.

Blocks. Credit and delivery blocks are SAP decisions. Whether a dealer hears about a credit block or gets “please contact your sales rep” is a business decision that belongs in the API response, not in the prompt.

Write actions. Changing a delivery date or placing an order is a second phase, with gates as described in Agent Script: rules instead of the LLM. For the first release I would keep the agent read-only.

Worked example: order status for 400 dealers

Assume a machine builder with S/4HANA on-premise, 400 dealers in Europe, a dealer portal on Experience Cloud and MuleSoft already serving the portal’s order list. All numbers here are assumptions.

Assume 2,000 order enquiries a month, each with up to three API calls: order status, delivery dates, availability of one replacement item. That is about 6,000 calls a month, roughly 300 per working day. SAP will not notice. A bug that makes the agent call the API in a loop will. MuleSoft’s Rate-Limiting SLA policy7 sets limits per client application through contracts in API Manager and answers with HTTP 429 once the quota is used up. So the agent gets its own client application with its own limit, assume 60 requests a minute, separate from the portal. A looping agent hits its own ceiling, and dealers in the portal keep working.

In the worked example, the first test week brings three findings. Orders taken by phone carry no dealer purchase order number, so the agent must also search by SAP order number. Some dealers have several sold-to numbers for subsidiaries, so the account needs a mapping that someone maintains, the same problem as with sales agreements and ERP actuals. And one plant does not maintain confirmed dates for spare parts, so for those items the agent can only say “not confirmed yet”. That is a data problem, and no prompt fixes it.

What a conversation costs in Flex Credits is calculated in the dealer service agent cost calculation.

Live call or a copy in Salesforce?

The agent should call SAP live. The dealer asks about today, and a nightly copy shows yesterday.

The price is a dependency: during an SAP maintenance window the action fails. The agent must then say so and offer a callback or a handover, and that case belongs in the test set, as described in testing Agentforce agents before go-live.

A copy still has its place, for example van stock that technicians need offline, as in spare parts between ERP and Field Service. I would not let the agent present dates from such a copy as current.

MuleSoft can also turn the same API into an MCP server: Agent Fabric8 describes an MCP Bridge that does this without custom code and keeps the existing gateway policies. That matters when external agents such as Claude should reach the API. For Agentforce itself the API Catalog action is the documented path. Salesforce announced a native MCP client for Agentforce as a pilot with the July 2025 release9; I would check its current status before building a production agent on it. What MCP means for an IT lead is in MCP explained for IT leads.

Check the existing sales order API

1. Check the API. Is there a Mule API or another REST API for sales orders, and does it return confirmed dates per item?
2. Fix identity first. Every dealer account needs the right sold-to numbers, maintained by a named person.
3. Design the agent API with three operations and precomputed fields, reviewed by sales and IT together.
4. Separate client applications for agent and portal, each with its own rate limit.
5. Test the unhappy paths: someone else’s order number, a missing confirmed date, SAP offline.

If your ERP has no API at all, see legacy ERP without an API. Whether the process is ready for an agent at all is covered in Agentforce for manufacturers: start now or wait.

Sources9

1. 1Salesforce Developers blog (opens in a new tab)developer.salesforce.com
2. 2MuleSoft SAP S/4HANA OData Connector (opens in a new tab)docs.mulesoft.com
3. 3MuleSoft’s documentation (opens in a new tab)docs.mulesoft.com
4. 4MuleSoft (opens in a new tab)docs.mulesoft.com
5. 5Agentforce workshop (opens in a new tab)developer.salesforce.com
6. 6External Service action (opens in a new tab)developer.salesforce.com
7. 7Rate-Limiting SLA policy (opens in a new tab)docs.mulesoft.com
8. 8Agent Fabric (opens in a new tab)docs.mulesoft.com
9. 9pilot with the July 2025 release (opens in a new tab)developer.salesforce.com