AI Agents
AI agents for telecom order fallout: fixing the stuck order-to-activate journey
The broadband order that provisions cleanly never needs an agent. The money is in fallout: the order that stalls between sold and activated, in a system nobody is watching. This is the Communications Cloud object model an agent acts on, the TMF622 change landing in Winter '27, and where the network decision stays with OSS.
A telecom order that flows from sold to activated without a hitch needs no agent. The value sits in the ones that stall. The order that passes billing, hits provisioning, and stops, silently, in a queue nobody checks until the customer calls to ask where their service is.
Order fallout is the most expensive routine failure in telecom fulfillment. An order fallout rate above 10% is treated as a systemic problem worth stopping the line for. An agent earns its place here by watching the fulfillment journey, diagnosing why an order jammed, and clearing the recoverable ones before a human ever sees them. The part it must not touch is the network provisioning decision, which stays with OSS.
This post is the build: what fallout is, the Salesforce Communications Cloud object model the agent acts on, the TMF622 integration change you have to make for Winter ‘27, and where the human and the OSS keep control.
What order fallout actually is
Order-to-activate is a chain: qualify the address and offer, capture the order, decompose it into fulfillment tasks, provision the service, activate it, then bill. The business support systems (BSS) take the order, and the operational support systems (OSS) do the provisioning and network configuration the order asks for.
Fallout is any order that falls out of that flow before activation. A provisioning command fails. An address doesn’t match the network inventory. A partner in a wholesale leg times out. A required field arrives blank from the sales channel. The order isn’t wrong enough to reject and isn’t complete enough to finish, so it sits.
The causes cluster. Inventory shortages, provisioning failures, bad or missing order data, and the orchestration complexity of triple- and quad-play bundles that cross internal and partner boundaries. Each one strands an order in a different place, which is why fallout is hard to staff for: the failures are varied, individually rare, and collectively constant.
The object model the agent reads and writes
Salesforce Communications Cloud implements the TM Forum Open APIs natively, which gives an agent a standard, documented surface instead of a bespoke one. Three of those APIs matter for fallout.
TMF622 Product Ordering Management is the core. It creates and tracks a product order and exposes its state as the order moves through fulfillment, so it is the object the agent watches for trouble. TMF620 Product Catalog Management holds the product offerings an order is built from, and TMF679 Product Offering Qualification answers whether an offer is serviceable at an address before the order is even placed.
Underneath the order sits an orchestration plan: the decomposition of one product order into the sequence of fulfillment tasks that provision it. Fallout is almost always one task in that plan failing, not the whole order, so the diagnostic question is never “did the order fail” but “which task stalled, and why.”
That distinction is what makes the workflow automatable. A stalled task carries a reason, and reasons fall into classes: a data problem the agent can fix and resubmit, a transient failure worth a bounded retry, and a genuine provisioning or inventory problem that belongs with a human or the OSS.
The Winter ‘27 change you have to make
There is a dated integration change here that is easy to miss and expensive to hit late. For the Communications Cloud TM Forum inbound APIs, the MuleSoft gateway option is being deprecated, and from the Winter ‘27 release only Direct Access is supported. Direct Access means reaching the APIs through the Connect and Apex REST endpoints instead of the Mule gateway.
If your order integrations, or the agent actions you are about to build, call TMF622 through the Mule gateway, they need to move to the Connect/Apex REST path before your org takes Winter ‘27. Build any new fallout automation on Direct Access from the start. An agent action that resubmits an order should call the endpoint you will still have next quarter, not the one being retired.
That makes an invocable Apex action the natural home for a remediation step, since it can hold the Connect/Apex REST callout and be governed and tested like any other action:
public with sharing class ResubmitProductOrder {
public class Request {
@InvocableVariable(required=true) public String productOrderId;
}
@InvocableMethod(label='Resubmit stalled product order (TMF622)')
public static void run(List<Request> reqs) {
for (Request r : reqs) {
HttpRequest req = new HttpRequest();
// Direct Access (Connect/Apex REST). Confirm the exact resource
// path against the TMF622 reference for your API version.
req.setEndpoint('callout:CommsCloud/productOrderingManagement/productOrder/'
+ EncodingUtil.urlEncode(r.productOrderId, 'UTF-8'));
req.setMethod('PATCH');
req.setHeader('Content-Type', 'application/json');
req.setHeader('Idempotency-Key', r.productOrderId); // don't double-submit
req.setBody('{ "state": "acknowledged" }');
HttpResponse res = new Http().send(req);
if (res.getStatusCode() >= 300) {
throw new CalloutException('Resubmit failed for '
+ r.productOrderId + ': ' + res.getStatus());
}
}
}
}Treat the resource path and body as things to confirm against the TMF622 reference for your version. The load-bearing choices are the Direct Access endpoint and the idempotency key, which stops a retry from submitting the same order twice.
What the agent does, and what it leaves alone
An event-triggered agent is the right shape. It watches product orders for a stalled or at-risk state rather than waiting to be asked, the same pattern behind any event-triggered agent that fires on record change. When an order or one of its tasks jams, the agent reads the failure reason and classifies it.
For a data-shaped failure, a missing service characteristic, a mismatched address format, a field the channel left blank, the agent can correct the record from the known-good source and resubmit the task. That is the bulk of fallout, and it is exactly the class a grounded agent handles well when it has the full picture.
That picture is a Data 360 job. Unify the order, the subscriber, the service address, and the network inventory into one profile so the agent diagnoses against current data instead of guessing, the same subscriber 360 that service and retention already need. Grounding decides whether the agent fixes the right field or invents a plausible wrong one.
Two things stay out of the agent’s hands. It does not decide whether the network can provision a service: that success-or-failure call is the OSS’s, and the agent’s job is to react to the OSS result, not to make it. And it does not keep retrying a genuine provisioning or inventory failure. A bounded retry for a transient error is fine; past that, the order escalates to a human with the diagnosis attached, which is the human-in-the-loop boundary that keeps an autonomous fulfillment agent safe.
The agent’s job is the recoverable fallout: the order that stalled on a data problem or a transient error. The order that stalled because the network can’t deliver is not an automation problem, and pretending it is just resubmits a failure faster.
Why resubmission has to be safe
Resubmitting orders is where a fulfillment agent gets dangerous. A reasoning loop that retries a call it thinks failed, or an event that fires twice, can push the same order into provisioning twice, and in telecom a double-provision is a real service and a real bill. The remediation action has to be idempotent, so a repeated call updates the same order rather than creating a second one or firing a second provisioning request.
The idempotency key in the snippet matters for that reason, and the safe pattern is to update an existing order by its identifier rather than blindly create. The same discipline applies to any governed action that reaches an external system: assume the call can happen twice and make the second one harmless.
Contrast this with commerce fulfillment, where an agent handles a split shipment or a return. The shape rhymes, watch the exceptions, act on the recoverable ones, but the telecom object model, the OSS handoff, and the provisioning risk are specific to Communications Cloud, and the design has to respect them.
What I would do
Start by measuring where your orders actually fall out. Pull a month of stalled orders, bucket them by failing task and reason, and you will find a short list of causes doing most of the damage. Fallout follows a Pareto curve, and the top two or three reasons are usually data-shaped and automatable.
Automate that recoverable class first, on Direct Access, with an idempotent resubmit action and a Data 360 profile behind it. Leave the provisioning decision with the OSS, and route the genuine failures to a human with the diagnosis already written. Then measure the fallout rate again. An agent that clears the data-shaped stalls before anyone notices is the difference between a fulfillment queue that self-heals and one that grows a backlog every weekend.
Understanding the basics
What is order fallout in telecom?
Order fallout is any order that fails to complete the order-to-activate journey before activation, stalling somewhere between the sale and a working service. Common causes are provisioning command failures, missing or malformed order data, inventory shortages, and the orchestration complexity of multi-play bundles that cross partner boundaries. A fallout rate above roughly 10% is generally treated as a systemic problem rather than normal noise.
How does Salesforce Communications Cloud support order management?
Communications Cloud implements the TM Forum Open APIs natively. TMF622 Product Ordering Management creates and tracks a product order and exposes its state through fulfillment, TMF620 holds the product catalog the order is built from, and TMF679 qualifies whether an offer is serviceable at an address. An orchestration plan decomposes each order into the fulfillment tasks that provision it, which is the layer where fallout usually happens.
What changes for TMF622 in Winter ‘27?
For the Communications Cloud TM Forum inbound APIs, the MuleSoft gateway option is being deprecated, and from the Winter ‘27 release only Direct Access is supported. Direct Access reaches the APIs through the Connect and Apex REST endpoints. Any integration or agent action that currently calls TMF622 through the Mule gateway has to move to the Connect/Apex REST path before the org upgrades.
Should an AI agent make the provisioning decision?
No. Whether the network can provision and activate a service is the operational support system’s decision, and the agent should react to that result rather than make it. The agent’s safe scope is the recoverable fallout: fixing data-shaped failures and resubmitting, retrying transient errors within a bound, and escalating genuine provisioning or inventory failures to a human with the diagnosis attached.
Standing up a fulfillment agent on Communications Cloud, or migrating TMF integrations off the Mule gateway before Winter ‘27? Talk to us. Building agents that clear the recoverable fallout and hand the rest to a human, safely, is the work we do.
