Product recalls in Salesforce: service campaigns
A product service campaign in Salesforce bundles a recall, fix or upgrade for a defined set of assets: the campaign describes the activity, and one item per affected machine tracks the status. Since API 65.0 the data model also holds the faulty part, serial ranges, production batches, partners and unsold dealer stock. Whether a campaign over hundreds of machines works depends on traceability. Without serial numbers and production batches in Salesforce, the campaign hits too many machines or misses some. Before anything is built, I would settle who triggers a campaign, who pays and how dealers report each completed machine.
What is a product service campaign?
The object reference describes the product service campaign1 as “a set of activities to be performed on a product service campaign asset”, such as “a product recall for safety issues or product defects”. It is available from API 51.0. The product service campaign item2 “represents a product service campaign’s asset”, so every affected machine gets its own line. The Field Service developer guide lists both objects, plus an item status object, among the Field Service standard objects3.
Manufacturing Cloud builds on that. The Trailhead overview4 lists product service campaigns among its service capabilities: “Launch and manage proactive service campaigns for recalls, upgrades, or maintenance initiatives”. The campaign is not limited to safety recalls. A retrofit kit offered to all machines of one series fits the same model.
Since API 65.0 the data model knows batches and causal parts
The product service campaign data model5 shows the full picture. The objects added in API 65.0 are documented in the Manufacturing Cloud and Automotive Cloud developer guides:
| Object | What it holds |
|---|---|
| Product service campaign | The campaign itself |
| Product service campaign item | One affected asset with its status |
| Group definition | Parent record of definitions, causal parts and partners |
| Campaign definition6 | Affected product, production start date, last affected serial number, number of affected units |
| Definition production batch7 | Links a production batch to the definition |
| Causal item8 | The faulty product that caused the campaign, with remediation type Notation, Repair or Replace |
| Group definition partner9 | A supplier, distributor or dealer, with point of contact and communication channel |
| Definition partner inventory10 | Unsold affected units at a partner, with quantity and inventory status |
The causal item also carries a replacement request type: either a credit from the supplier without returning the part, or a credit against a product return. That links the campaign to supplier recovery, which warranty claims from dealers describes for single claims. The data model diagram also lists work orders, service appointments, return orders and claims.
How do you find the affected machines?
This is where most recalls go wrong, in Salesforce or anywhere else. The definition selects by product, production start date and the last affected serial number, and it can link production batches. That assumes three things:
- Every machine exists as an asset with a serial number. How the installed base gets there is covered in installed base in Manufacturing Cloud.
- Serial numbers run in order within a product, so a range means something.
- The link from component batch to machine is known. If a supplier’s valve batch is faulty, you need to know which machines it went into. That as-built information usually lives in production or PLM, as described in spare parts by serial number.
If one of these is missing, you choose between two bad options. Select too broadly and you pay for work on machines that are fine. Select too narrowly and faulty machines stay in the field. I would test the selection logic against one past quality case before trusting it with a real recall.
Worked example: a faulty valve batch
Assume a machine builder learns that a supplier’s valve batch is faulty. The valve sits in 1,800 machines of two series, sold through 70 dealers. 120 of those machines are still unsold in dealer stock.
In the data model this becomes a campaign and a group definition. The causal item is the valve, remediation type Replace, with a product return against credit so the supplier pays. Two definitions cover the two series, each with production start date, last affected serial number and the linked production batches. The supplier and the 70 dealers are group definition partners. The 120 unsold machines appear as partner inventory, so they are fixed before they reach a customer.
1,680 machines at end customers become campaign items. Dealers contact their customers, book the visit, replace the valve and report each machine as done. The quality team sees per item and per dealer how far the campaign has come. All numbers here are assumptions that show the method.
Who carries out the work?
Usually dealers and service partners, sometimes the manufacturer’s own technicians. Work orders, service appointments and technician scheduling belong to Field Service and need Field Service licences. How partner technicians work in it is covered in Field Service service partners and in the Field Service masterclass chapter on assets and parts.
Dealers without Field Service report through the portal. Which licence that needs is covered in the Manufacturing Cloud customer portal. Whichever path you choose, completion must be reported per machine, not per dealer as a number, or the campaign status in Salesforce is fiction.
When is a list in the quality system enough?
Not every manufacturer needs this data model. For small actions, a list of serial numbers in the quality system plus one work order or case per machine is enough. The overhead of definitions, partners and partner inventory only pays off at scale. I would use product service campaigns when several of the points in their favour apply:
What speaks for service campaigns
- Hundreds of machines per action, spread across many customers
- Dealers or service partners do the work, and you need status per machine from outside your own company
- Unsold stock sits at dealers and has to be fixed before sale
- Supplier recovery matters, because the faulty part was bought in
- Upgrades happen regularly, for example retrofit kits for a whole series
When a list is enough
- One or two field actions a year
- A few dozen machines per action
- Your own technicians do the work
The selection problem stays the same either way: without clean serial numbers and batches, the best list does not help.
Settle trigger, costs and reporting in writing
These are the questions I would answer in writing before building:
- Who triggers a campaign? Usually quality, sometimes product management for upgrades. One role creates it, another approves.
- Who pays? Parts, labour for the dealer and travel. The causal item covers supplier recovery; how dealers get paid for labour, through claims or a flat rate, is your decision.
- How is completion reported? Per machine, with date and who did it, through work order, portal or claim.
Then there is the licence question:
I walk through the reporting route from question 3 with two dealers before the first campaign starts. The full after-sales picture is in the warranty and after-sales chapter of the Manufacturing Cloud masterclass.
Sources10
- 1product service campaign (opens in a new tab)developer.salesforce.com
- 2product service campaign item (opens in a new tab)developer.salesforce.com
- 3Field Service standard objects (opens in a new tab)developer.salesforce.com
- 4Trailhead overview (opens in a new tab)trailhead.salesforce.com
- 5product service campaign data model (opens in a new tab)developer.salesforce.com
- 6Campaign definition (opens in a new tab)developer.salesforce.com
- 7Definition production batch (opens in a new tab)developer.salesforce.com
- 8Causal item (opens in a new tab)developer.salesforce.com
- 9Group definition partner (opens in a new tab)developer.salesforce.com
- 10Definition partner inventory (opens in a new tab)developer.salesforce.com
Frequently asked questions
What is a product service campaign in Salesforce?
A product service campaign represents a set of activities to be performed on a group of assets, for example a recall for safety issues or product defects, a fix or an upgrade. Each affected asset is a product service campaign item with its own status. The object is available from API version 51.0.
How does Salesforce know which machines a recall affects?
Through campaign definitions that name the affected product, the production start date, the last affected serial number and linked production batches. That only works if serial numbers and production batches exist in Salesforce, usually loaded from the ERP or production.
Can dealers carry out recall work in Salesforce?
The data model includes partners with their role and communication channel and the unsold inventory each partner holds. The work itself usually runs as work orders and service appointments, which belong to Field Service, or through the dealer portal.
Are product service campaigns included in Manufacturing Cloud?
Trailhead lists product service campaigns among the Manufacturing Cloud service capabilities, but the pricing page does not mention them. Ask Salesforce in writing which edition includes them before you plan a recall process on them.