January 15, 2026
Manufacturers get real automation from Salesforce when the commercial side and the service side write to the same records. A forecast drives a production plan, an order triggers a build, an install creates an asset, and a warranty claim checks itself against terms someone actually sold. Each step hands off to the next without anyone re-keying it.
The products that do this were renamed in late 2025. Sales Cloud is now Agentforce Sales, Service Cloud is now Agentforce Service, and Manufacturing Cloud is now Agentforce Manufacturing. The capabilities did not move; the labels did.
This guide maps which product owns which part of that chain, what the two sides genuinely share, and what has to be clean before any of it runs on its own. Where a step deserves a full walkthrough, it points to one.
If you are comparing notes against documentation written before late 2025, the names will not match. Salesforce reorganized the portfolio under an Agentforce 360 architecture at Dreamforce 2025, formalized in the Spring '26 release.
Salesforce dates one of these precisely. Its own documentation states that as of October 14, 2025, Data Cloud was rebranded to Data 360, and warns that references to the old name still appear in the application during the transition. Expect the same lag in third-party material for some time.
We covered what the Sales Cloud change means in practice in our breakdown of the Sales Cloud to Agentforce Sales rebrand. The short version: existing data, flows, and licences carried forward untouched, and the new agent capabilities sit on top of them rather than replacing anything.
One practical consequence is easy to miss. Salesforce retired a set of certifications during the transition and introduced Agentforce-focused replacements. If credentials feed your partner tier or your hiring criteria, check the retirement list rather than assuming. Platforms such as saasguru track the current certification map.
"Breaking down silos" tells an architect nothing. Here is the concrete version: the records both sides touch, and the specific harm when each side keeps its own copy.
Row five is the one manufacturers feel first, and it carries a real cost. If a service repair and a new sales order both reserve the last unit, somebody's promise breaks. Which side wins should be a written policy encoded in the reservation logic, not an accident of whoever saved the record first.
Row seven is the one that pays best and gets built last. Field failure rates are a demand signal. If a component fails at three times its expected rate, that is spare-parts demand your forecast should already know about, and almost no manufacturer has closed that loop.
This is the map. Read it as routing: what you want to automate, where it is built, and where the detailed walkthrough sits.
The first five rows each have a dedicated walkthrough, because each one is a project rather than a setting. In order: managing manufacturing quotes and negotiation, turning a quote into an activated order, real-time inventory control, automating production execution when stock runs short, and managing installation, field service, and warranty claims.
The last three rows are covered below, because they are the connective tissue rather than a discrete workflow.
Three things in the commercial motion are specific to manufacturing rather than generic CRM, and they are the ones most often missing when a manufacturer says their CRM does not fit them.
Sales agreements hold a long-term volume commitment. A customer contracts to take a stated volume across the year at agreed pricing, and the agreement tracks planned against actual volume period by period. A customer running behind commitment becomes visible while there is still time to act, rather than at the annual review.
Account forecasts aggregate demand at account level rather than opportunity level, which is the unit manufacturers actually plan production against. A forecast assembled only from open opportunities misses committed volume that never appears as an opportunity at all.
Agent-assisted administration is what genuinely changed with the rebrand. Meeting preparation, opportunity field updates, and follow-up drafting can now run as agent work, with a human accepting, editing, or declining each suggestion. The value is not novelty. It is that a rep covering forty accounts can plausibly keep forty accounts current.
Two caveats belong here. Agent output is only as good as the account data behind it, so the data work described further down is a prerequisite rather than an alternative. And any pipeline hygiene automation you already run should be audited before agents start writing to the same fields, or you will have two systems updating one record with different logic. Practitioner threads on Forcetalks are a reasonable place to see how teams are sequencing that in practice.
Service in manufacturing is not a contact center with a different logo on it. It manages physical machines in the field, under commercial terms somebody sold, using parts that have to exist somewhere.
Assets are the spine. The asset record represents the specific machine at the specific site, ideally with a hierarchy underneath it for serviceable components. Every downstream automation keys off it: which entitlement applies, which parts fit, what has failed before.
Entitlements decide claims. When warranty terms are encoded as rules rather than stored as PDFs, a claim can be checked automatically against coverage, dates, and usage limits. That is what turns a multi-day paperwork exercise into a decision, and it protects margin in both directions.
Parts availability decides whether the visit succeeds. A technician arriving without the right part converts one truck roll into two. Linking service demand to the same inventory picture sales works from is what prevents that.
Predictive maintenance deserves precision here, because it is routinely oversold. What is straightforward today is condition-based: a telemetry threshold is crossed, a rule creates a work order, and scheduling assigns a technician with the right skills and the right part. That works, and it is worth building now.
Genuinely predictive maintenance, meaning an estimate of remaining useful life derived from failure patterns, needs a volume and cleanliness of historical failure data that most manufacturers do not yet have. Build the condition-based version first. It delivers most of the operational value, and it generates exactly the dataset the predictive version will eventually require.
The full post-delivery workflow, including work order creation and claim handling, is covered in our guide to Service Cloud implementation and the manufacturing-specific walkthrough linked above.
These two get named in the same breath and do completely different jobs. Conflating them is the most common architectural mistake in this space, and it produces programs that integrate beautifully and still fail.
The last row is the whole point. MuleSoft will move "Widget-A" and "Widget-Alpha" between systems perfectly, faithfully, and on schedule, and your automation will still fail, because those are two names for one part. Reconciling that is a data resolution and governance job. No amount of integration middleware substitutes for it, and no AI agent works around it.
Designing which system owns which field, and how the handoffs behave when one side is unavailable, is integration architecture work rather than configuration.
Every capability above assumes foundations. These are them, in the order they tend to bite.
Row six is worth dwelling on. For every field that exists in both Salesforce and your ERP, one system has to be the source of truth and the other has to accept it. Write that down field by field before anyone builds. Teams who skip this discover it months later when a value changes back overnight and nobody can explain why.
Most of this is ordinary Salesforce administration and governance discipline rather than anything exotic, and it is dramatically cheaper before go-live than after a wrong payout or a missed shipment.
Order matters more than ambition. Programs that stall almost always started with the interesting part.
First, reconcile the part master. Nothing downstream works without it, and it is the least glamorous work in the entire program.
Second, create assets at install. Every service and warranty automation keys off the asset record. If assets get created retroactively, you will be reconstructing history indefinitely.
Third, encode entitlements. Warranty terms sitting in a PDF cannot be evaluated by a rule, and that single gap blocks most claim automation.
Fourth, automate one handoff end to end. Pick order-to-production or claim-to-decision. One handoff, all the way through, running in production before you start the next.
Fifth, integrate with field ownership defined. Per field, name the system of record and write it down.
Sixth, add the agent layer. Once the data underneath is trustworthy, agents amplify it. Before that, they amplify the mess.
Seventh, close the loop from field back to forecast. Let failure rates inform demand, and demand inform production.
That last step is the actual goal, and it is worth naming as one. When field failure rates change the demand forecast, and the demand forecast changes the production plan, the enterprise genuinely self-corrects. Everything before it is plumbing that makes it possible. Configuration-level patterns for the Flow and automation work underneath these handoffs are covered well on SFDC Fanboy.
Manufacturing Cloud, now called Agentforce Manufacturing, is an industry-specific layer on top of the core CRM. Its distinguishing objects are sales agreements for long-term volume commitments, account-level forecasts, and inventory records built for manufacturers. Salesforce describes it as unifying sales, service, and back-office operations on one platform.
Agentforce Sales, formerly Sales Cloud, manages winning revenue: accounts, opportunities, pipeline, and forecasting. Agentforce Service, formerly Service Cloud, manages keeping customers after the sale: cases, entitlements, warranty claims, and support channels. For a manufacturer they overlap heavily on accounts, assets, parts, and inventory, which is exactly why they should share records rather than each keeping a copy.
If you sell one-off orders with no volume commitments, the core products may be enough. If customers commit to volumes over a contract period, or you plan production against account-level demand, you want the manufacturing objects rather than a set of custom fields approximating them.
Yes. Salesforce rebranded Data Cloud to Data 360 as of October 14, 2025. It is the same product, not a replacement, and Salesforce notes that the old name still appears in places during the transition.
Usually yes, because they solve different problems. Data 360 resolves whether records across systems describe the same thing. MuleSoft moves data and triggers operations between those systems. Unifying a part master does not by itself send a work order to your ERP.
No, and treating it as a replacement is a reliable way to fail. Salesforce owns the customer-facing and service-facing processes and orchestrates handoffs. Your ERP still runs finance and materials planning, and your MES still runs the shop floor. The value is in the handoffs being automatic and traceable.
Condition-based maintenance is realistic now: a sensor threshold triggers a work order and a scheduled technician. Truly predictive maintenance, estimating remaining useful life, needs a depth of clean historical failure data most manufacturers have not yet accumulated. Build condition-based first; it produces the data the predictive version will need.
The names on these products changed, and it is worth using the current ones so your documentation does not date. But the rename is not the story. The story is that a manufacturer only gets automation when the commercial side and the service side reference the same account, the same part, the same asset, and the same unit of stock.
Get that right and each handoff becomes a rule instead of a meeting. Skip it and you have bought an expensive set of systems that describe the same factory in incompatible terms, with agents on top confidently acting on whichever version they were handed.
At Minuscule Technologies we start manufacturing programs with the part master, the asset model, and field-level ownership across the ERP boundary, then automate one handoff end to end before expanding. If you want a clear view of which handoffs in your business are ready to automate and which are blocked on data, talk to our team about a manufacturing automation readiness review.
You've seen what's possible. Now, let's make it happen for your business. Whether you need an end-to-end Salesforce solution, a complex integration, or ongoing managed services, our team is ready to deliver.
Schedule a Free Strategic Call
