Manufacturing Cloud: ERP integration, AI and rollout

Once the features are designed, three questions decide a Manufacturing Cloud project: which system owns which data, where Agentforce actually takes work off people, and in which order the countries go live. SAP stays the master for accounts, products, orders and usually prices. Manufacturing Cloud receives actuals daily and sends approved rebates and warranty amounts back as credit memos. Agentforce pays off first in read-only processes with high volume and an API to the ERP. The rollout starts with a large country of reasonable complexity, and all countries work at least 80 percent the same way. Check every interface that logs in with SOAP login() before 1 December 2026.

Which system owns which object?

Before anyone builds an interface, every object needs a leading system and a named owner. Manufacturing Cloud produces few of its numbers itself. A sales agreement from chapter 2 compares plan against actuals, and the actuals come from SAP. Rebates from chapter 3 and warranty from chapter 4 run the other way: Salesforce approves, SAP pays.

This is how I would split ownership at a typical manufacturer running SAP:

Data	Leading system	What Salesforce needs it for
Accounts and account hierarchy	SAP	Sales agreements, forecasts, portal
Products and product hierarchy	SAP	Sales agreements, rebates, warranty
Prices and conditions	SAP, unless you decide otherwise on purpose	Telesales, dealer quotes
Orders or order totals	SAP	Actuals, order status
Stock	SAP	A figure next to the shortfall
Sales agreements, forecasts, targets	Salesforce	Sales planning
Approved rebates and warranty amounts	Salesforce, paid in SAP	Credit memo to the dealer

For objects inside the org I use the object ownership matrix. For ERP interfaces I add two columns, direction and frequency. The most common gap is the account hierarchy: if the sold-to party in SAP does not sit on the same level as the account that holds the sales agreement, you need a mapping table, and that table needs an owner too.

Data flows between SAP and Manufacturing Cloud

Master data and actuals flow into Salesforce, money flows back. The frequency follows the question the data answers. Sales agreements run for months, so a daily load is enough for their actuals. A dealer asking about an order wants today’s status; I call that live in SAP instead of copying it, as in Agentforce and SAP: order status through MuleSoft. All flows with direction and frequency are in Manufacturing Cloud and SAP: which data flows where.

The MuleSoft Accelerator for Manufacturing (opens in a new tab) provides templates for two of these flows: syncing accounts, products and orders from SAP S/4HANA, and credit memos for approved rebate payouts. It does not create sales agreements and names no warranty flow. Salesforce lists MuleSoft on the add-ons page (opens in a new tab) only with “Request a quote”. If you already run MuleSoft, the templates save design time. Buying it just for these flows rarely pays off.

For late orders and corrections there is the Refresh Actuals Calculation (opens in a new tab) action. It is available from API version 47.0 and recalculates the actuals of a sales agreement for the current, past or future periods. When SAP books a return for last month, the middleware calls it for the affected agreements. Otherwise account managers call customers about a shortfall that no longer exists.

How the same question looks for a B2B store is covered in the ERP integration chapter of the B2B Commerce masterclass. I help design these interfaces under Salesforce integration.

Which login deadlines apply to ERP interfaces?

Many ERP interfaces still log in with a technical user and a password. According to the developer’s guide to Winter ’27 (opens in a new tab), these deadlines apply:

1. 1 Dec 2026 · next dateEvery user who logs in through SOAP API login() needs the Use Any API Auth permission, otherwise they get an error
2. Summer '27SOAP login() in API versions 31.0 to 64.0 is retired
3. Summer '27SOAP, REST and Bulk API versions 31.0 to 40.0 stop getting fixes
4. Summer '28Calls to SOAP, REST and Bulk API versions 31.0 to 40.0 fail

The risk is an actuals load that fails silently: sales sees an old shortfall and believes it. How to find the affected interfaces is in Salesforce password integrations end in 2027.

Who owns prices: SAP or Penny Perfect Pricing?

With Winter ’27, generally available since 12 October 2026 (opens in a new tab), Salesforce offers its own price engine for orders. According to the developer guide (opens in a new tab), Penny Perfect Pricing prices advanced order line items, which is the telesales ordering flow, and describes 19 objects from API version 68.0. Calculation schema, search strategies and condition records with tiers look a lot like the SAP condition technique.

The boundaries stay as in the other chapters: quotes with a configurator belong to Revenue Cloud, see catalog, configurator, pricing, and store prices to B2B Commerce, see prices, cart, checkout.

When does Agentforce pay off for manufacturers?

When a process meets the criteria I describe in Agentforce for manufacturers: start now or wait?: enough volume, data that holds up, API access to the ERP, a cost model that works and an edition that fits. Dealer questions about order status and delivery dates often meet them. A warranty pre-check where the installed base lacks warranty start dates does not.

Two numbers drive the cost. A standard or custom action costs 20 Flex Credits according to the Flex Credits rate card (opens in a new tab), which at $500 per 100,000 credits (opens in a new tab) is $0.10. And the edition sets the pool: according to the Manufacturing Cloud pricing page (opens in a new tab), the Core editions include 500,000 Flex Credits per org and year, the Max editions 2.75 million and, as the only ones, the full Agentforce for Industries suite. For Core there is the Agentforce for Manufacturing Cloud Add-on: the add-ons page says $150 per user and month, the pricing page “from $ 150 login/month”. Get the unit confirmed in writing. How to estimate credits per action is covered in the costs and tokens chapter of the AI masterclass.

20

Flex Credits per standard or custom action, so $0.10

500,000

Flex Credits per org and year in the Core editions

2.75 million

Flex Credits per org and year in the Max editions

The most visible industry reference shows where to start. In the Siemens and Salesforce announcement (opens in a new tab) of 15 September 2026, two agents for inbound leads are live, for 18,000 sellers in 132 countries. Teamcenter answers for service and supplier onboarding in SAP are written in the future tense. In Siemens and Agentforce: lessons for manufacturers I derive an order from it: read-only with high volume first, then reading from the ERP, then answers from PLM and serial numbers, and write steps into the ERP last. Which agents exist today for sales, service and warranty is in the AI agents in manufacturing chapter.

One agent for dealers in many languages

For exporters with dealers in many countries, language is a planning question of its own. Salesforce separates generally available languages from beta languages in Agentforce, and according to its multi-language guide (opens in a new tab) the customer is responsible for quality assurance in beta languages. Check every dealer language against the current list, because Salesforce changes it regularly. Translation itself is cheap: the rate card lists 4,000 Flex Credits per million characters translated, which is $20 at list price.

Knowledge costs more. According to the same guide, the retriever filters out knowledge articles whose language does not match the session language, so an Italian dealer only finds Italian articles. If you do not want that, you build a custom retriever without the language filter. I would maintain knowledge in one or two languages, keep safety and warranty content per country and test every approved language with real dealer questions before go-live. The worked example and the split are in Multilingual Agentforce agents for export dealers. In the rollout, language becomes a column in the country table.

In which order do you roll out Manufacturing Cloud globally?

First the goal is fixed, usually harmonising processes. That leads to a global template with the decisions that are hard to change after the first country: the account level of sales agreements, the rule for when a configuration becomes its own product, and what customers and dealers see in the portal. In Rolling out Manufacturing Cloud globally I describe the rules I derive from that:

Rule	What it means
First country	large, with reasonable complexity. A small pilot country confirms a template that later breaks at the first large country.
Large region early	one of the largest regions joins in the first two phases, so the template is under real load while changes are still cheap.
Order after that	a table with one row per country and columns for processes, business units, IT systems and brands. For Manufacturing Cloud I add two columns: own ERP or shared, and dealer languages.
80 percent the same	legal requirements are given, every other local requirement is justified and decided by one role on the client side.
Change management	key users, communication before go-live and a look at usage afterwards, in every country.

The ERP column carries the most weight. A country with its own SAP system or its own middleware needs new interfaces for actuals, rebates and warranty. If it shares the ERP with a country that is already live, the path is shorter. How I build a roadmap with phases and gates is in the rollout roadmap chapter of the DevOps masterclass, and the work with people in each country under change management for Salesforce programmes.

Retest after every Salesforce release

Salesforce ships three releases a year, and preview sandboxes get each one before production. How to align that with your own release calendar is in the release planning chapter of the DevOps masterclass. In a Manufacturing Cloud org the parts that produce numbers belong in the regression test first:

What	Why it is tested after every release
Forecast sets	They are metadata of type AdvAccountForecastSet (opens in a new tab), available since API version 53.0, and define the forecast configuration per business unit.
Data Processing Engine definitions	They aggregate actuals, forecasts and rebates; Salesforce lists them as BatchCalcJobDefinition (opens in a new tab).
Business Rules Engine expression sets	The metadata type is ExpressionSetDefinition (opens in a new tab); in many orgs they hold warranty and rebate rules.
ERP interfaces	Every new API version is a reason to check the API versions of your interfaces against the deadlines above.

My test per release is deliberately small: one forecast regeneration, one actuals refresh for three sales agreements, one warranty claim through the expression set and one rebate run for a period, each in the preview sandbox and compared with production. If a number differs, you know before your account managers do. For these definitions to move between orgs like any other configuration, they belong in the repository, as described in the data and configuration chapter.

First step: agree the object list with the SAP team

Agree with the SAP team which system owns which object before the first interface is built, and settle the template in the first large country before the second country starts planning. This chapter closes the masterclass. It assumes the decisions from the business case, agreements, dealer channel and warranty, and settles what they need in operation and across many countries. Before it came chapter 4 on warranty and after-sales, and all five chapters are on the overview page.