Communications Cloud is the commercial system of record. It does not replace your billing platform or your provisioning stack — it has to negotiate with them, thousands of times a day. Twopir Consulting designs and builds those connections: what is sent, what comes back, in which direction, and what happens when a downstream system is slow, wrong or unavailable. That last question is where order flow-through is won or lost.
Trusted by 500+ organizations — including connectivity and communications providers integrating Salesforce with complex downstream estates through Twopir Consulting.
Systems We Connect
Operators usually describe these as Communications Cloud problems. They are almost always integration design problems, and they are fixable without touching the platform.
An orchestration step fails and the order leaves the system for a queue, an inbox or a spreadsheet. Because the exception is not modelled, nobody can report on it, route it, or say how long it has been sitting there.
An interface that is not idempotent turns a timeout into a second activation, a second charge, or a second work order. The failure looks intermittent because it only shows up when the downstream system is slow.
Qualification happens after the order is placed instead of in the cart, so customers buy services that cannot be delivered at their address. This is the single largest manufactured source of fallout, and it is a sequencing decision.
Self-serve, assisted and partner channels each get their own path to the same downstream system. Three code paths, three sets of edge cases, and a change to the billing interface that has to be made three times.
Care cannot answer "where is my order" because the answer lives across the OSS, the field-service system and someone's memory. Status has to be modelled as state on the order, fed by callbacks, not reconstructed on demand.
Interfaces are built to whatever shape the current billing platform happens to expose. Replacing that platform later becomes a second transformation programme rather than a bounded piece of work.
Communications Cloud integration is the work of connecting the commercial system of record to the systems that actually deliver and charge for the service: billing and charging, OSS provisioning and activation, network and service inventory, field service, and finance. Concretely, an order decomposed into a technical order raises fulfilment requests that are sequenced by an orchestration plan across those systems, and each of them has to answer — with a status, an identifier, a failure, or silence.
The design question is not which connector to use. It is what the contract between the two systems actually is: what is sent, what is guaranteed to come back, how long it may take, what happens on a timeout, whether the same message can safely arrive twice, and who is told when it does not arrive at all. Those decisions determine order flow-through far more than the transport does, and they are the ones most often left implicit until production finds them.
Salesforce supports this with TM Forum Open APIs, the telecom industry's standard interface specifications, and Communications Cloud conforms to them — which lets an integration be built to a published shape rather than a bespoke one, and makes replacing a downstream vendor a bounded change. Twopir Consulting designs the interface contracts, builds and tests the integrations, and designs the failure behaviour: retry, idempotency, compensation, reconciliation and the exception model your operations team will live inside.
Where this page stops. This page covers integration architecture — which systems, what moves, in what sequence, and who owns the failure. The engineering layer beneath it — TM Forum Open API conformance, payload and event design, idempotency keys, security, versioning and observability — is covered on Communications Cloud API & systems integration. If your question is "which systems and in what order", you are on the right page.
Both platforms named, the business purpose, and the direction of travel. A logo wall tells you nothing; this is the content that decides whether the integration works.
So finance bills what was sold and activated. Activated order lines, rated products, contracted prices and discount terms flow out to the charging platform — Amdocs, Netcracker, CSG or Aria. Invoice status, balance, payment and dunning state flow back onto the account. The design decision that matters: whether billing is told at order activation or at service activation, because the gap between them is where disputed first invoices are created.
So a sale becomes a working service. Fulfilment requests from the decomposed technical order go out as orchestration items; activation status, assigned service identifiers, jeopardy signals and completion events come back to advance or fail the plan. Asynchronous by nature, which is why callback handling and timeout behaviour matter more here than anywhere else in the estate.
So you only sell what can actually be delivered. Serviceability and qualification calls go out from the cart at quote time; available technologies, speeds, capacity and lead times come back before the customer commits. Getting this into the cart rather than after the order is the highest-leverage change most operators can make to their fallout rate.
So an install appointment is part of the order rather than a parallel process. Orders needing a truck roll raise work orders out as an orchestration step; appointment windows, technician status and completion come back to release the next step. Because both sit on Salesforce, the integration is closer to configuration than to engineering — one of the few places that is true.
So commercial reality reaches the general ledger. Contracted revenue, order value and cost and commission triggers flow out to SAP, NetSuite or the finance platform of record; cost centre, entity and approval data flow back to keep quoting inside financial policy. Multi-entity operators need this settled before go-live rather than after the first close.
So integrations are reusable instead of rebuilt per project. MuleSoft's API-led pattern puts system APIs over the legacy estate, orchestrates them in process APIs, and exposes them along TM Forum shapes. It earns its place when several systems must be reached, when the estate will change, or when other consumers need the same data — and not much otherwise.
Broader Salesforce connectivity work sits on Salesforce integration services. For the API engineering layer, see Communications Cloud API & systems integration.
Six behaviours that have to be chosen deliberately. Left implicit, each becomes a production incident with a customer attached to it.
The failure decisions, and what each one costs to get wrong
| Behaviour | The decision | What it costs if left implicit |
|---|---|---|
| Timeout | How long we wait before treating silence as failure | Orders hang in an indeterminate state nobody can report on |
| Retry | How many attempts, at what interval, with what backoff | A slow downstream system turns into a self-inflicted flood |
| Idempotency | The key that makes a repeated message safe | Duplicate activations, duplicate charges, duplicate truck rolls |
| Compensation | What is undone when a later step fails | A service activated but never billed, or billed but never activated |
| Exception routing | Who is told, in which queue, with what SLA | Fallout accumulates somewhere invisible until a customer escalates |
| Reconciliation | What is compared between systems, and how often | Drift between commercial and network state, found at audit |
These are operating decisions as much as technical ones, so we take them with the people who will own the consequences — operations and care, not only architecture. The exception model in particular is a staffing decision disguised as a design one.
Integration is the workstream that most often sets the real go-live date, so we start it in discovery rather than after the build.
We inventory the downstream systems, their real interfaces, their owners and their actual behaviour under load — not the behaviour in the documentation. Output: an integration map with a named owner per connection.
For each connection: what is sent, what returns, timing, idempotency, and the failure semantics from the table above. Agreed in writing with the downstream owner, because an interface contract with one signature is a wish.
We build against stubs that model the real failure modes — slow, wrong, silent — from the first sprint, so failure handling is exercised continuously rather than discovered during integration testing.
End-to-end against live endpoints, then at realistic volume. Load is where timeout, retry and idempotency decisions are actually validated; functional testing will not find those defects.
Monitoring, alerting and the exception dashboards operations needs, plus tuning once real traffic shows which assumptions were wrong. Every integration estate has some; the point is finding them in week one rather than quarter three.
Operating changes, described the way the teams who live with them would describe them.
Routine orders stop needing hands
Orders that match known patterns complete without intervention, so the exceptions queue holds genuine exceptions rather than a mixture of real problems and routine work.
Care answers from the system
Order state is modelled on the order and fed by callbacks, so an agent, a self-serve page and an AI agent all read the same answer instead of three different ones.
Fallout is owned and measurable
Failures are modelled, routed to a named queue with an SLA, and reportable — which means they can be reduced deliberately instead of absorbed by whoever notices first.
A retry cannot double-charge
Idempotent interfaces mean a timeout produces a retry rather than a second activation, a second invoice line or a second engineer at the customer's door.
Replacing a vendor is bounded work
Standards-shaped contracts and a documented interface mean swapping a billing or provisioning platform changes one system interface, not every consumer of it.
You stop selling what you cannot deliver
Qualification in the cart rather than after the order removes the largest manufactured source of fallout, and the customer finds out before they commit rather than after.
Related Twopir work
Related: order management & automation for the orchestration side, API & systems integration for the engineering layer, and Salesforce for telecom infrastructure for the wider operator picture.
Any competent team can make two systems talk on a good day. What separates an integration estate that works from one that generates tickets is what it does on a bad one.
Downstream systems rarely behave the way their specification says under load. We measure what they actually do — latency, error shapes, throttling — before designing against them.
An interface agreed with only one team is an assumption. We get the downstream owner's signature on timing, payload and failure semantics, because that conversation surfaces constraints early.
Our stubs are slow, wrong and silent by design. Failure handling gets exercised in every sprint rather than discovered during integration testing, when the schedule has no room left.
Where fallout goes, who owns it and what the SLA is are decisions made with operations and care, not inferred by engineering. It is a staffing decision disguised as a technical one.
Building to standard shapes where they exist, and isolating vendor specifics where they do not, is what keeps the next platform change a bounded project instead of a second transformation.
No, and an integration designed on that assumption will run into trouble early. Communications Cloud is the commercial system of record: it models the catalog, produces the quote and contract, creates the order and orchestrates fulfilment. Rating, charging and invoice production stay in your billing platform, and service activation stays in your OSS. The value comes from the contract between them being explicit — what is sent, what comes back, and what happens when a downstream system fails. That design work is most of the engineering risk in a Communications Cloud programme.
TM Forum Open APIs are the telecom industry's standard interface specifications, maintained by the TM Forum, covering things like product catalog, product ordering and service ordering. Salesforce Communications Cloud conforms to them and its Enterprise Product Catalog is certified against the TM Forum Information Framework, the industry's standard information model. The practical benefit is not that integration becomes automatic — it does not — but that both sides can build to a published shape instead of negotiating a bespoke one, which reduces rework and makes replacing a downstream vendor a bounded change rather than a second transformation programme.
Direct integration is perfectly reasonable when you have a small number of stable downstream systems and no other consumers needing the same data. An API-led layer such as MuleSoft earns its place in three situations: when several systems have to be reached for a single order, when the estate is going to change and you want to isolate consumers from that change, or when other parts of the business need the same underlying data. The pattern puts system APIs over the legacy estate, orchestrates them in process APIs and exposes them along TM Forum shapes. It is worth real money in those cases and is overhead outside them, so we make the call on evidence rather than by default.
Fallout is an order that leaves the automated flow because a step failed, and has to be handled by a person. Reducing it is mostly not about making integrations more reliable. The largest single source is manufactured upstream: selling something that cannot be delivered at that address, because serviceability was checked after the order was placed rather than in the cart. Moving qualification into the cart typically removes more fallout than any downstream change. After that it is about modelling exceptions properly so they are visible, routed and measurable, because fallout you cannot count is fallout you cannot reduce.
Idempotency, designed into the interface contract rather than added later. Each request carries a key that lets the receiving system recognise a repeat and return the original result instead of performing the action again. Without it, a timeout on a slow downstream system produces a retry that becomes a second activation, a second charge or a second engineer visit — and because it only happens under load, it is intermittent and hard to diagnose. We decide the idempotency key per interface during contract design and test it explicitly under volume, because functional testing will not find it.
It scales with the number of connections and, more importantly, with how many organisations have to agree on each one. A small estate — billing, provisioning and one inventory system, with cooperative owners — is a matter of weeks of design and a few sprints of build and test. A large converged operator with a dozen downstream systems, several of them owned by different business units or outsourced to different vendors, is measured in months and is gated by scheduling rather than by engineering. This is usually the workstream that sets the real go-live date, which is why we start it in discovery.
This page covers integration architecture: which systems connect, what data moves in which direction, in what sequence, and who owns the failure. The API and systems integration page covers the engineering layer underneath that: TM Forum Open API conformance in detail, payload and event design, idempotency keys, authentication and security, versioning, and observability. If your question is which systems and in what order, this page answers it. If your question is how the endpoints themselves should be specified, built and operated, that one does.
An integration review looks at your downstream systems, how they really behave, and where order flow-through is being lost. You get a connection map with named owners and a prioritised list of what to fix first.
Speak with a team that designs for the timeout, not the demo
