How a Salesforce-to-ATPCO automation transformed thousands of corporate fare contracts from a manual filing queue into a one-click process.
Standardized corporate contracts could be prepared and submitted to ATPCO within minutes.
A major North American airline negotiates standardized fare agreements with its corporate customers. The commercial work happens in Salesforce: terms are negotiated, discounts are agreed, and the contract is approved by the account team.
But a fare that exists in a CRM cannot be sold. To become bookable, it has to be filed with ATPCO, the clearinghouse that distributes fare and rule data to global distribution systems, agencies and booking channels. Until that filing lands, the negotiated price is a promise rather than a product.
Between those two systems sat a person. A specialist fare filing team received each approved contract by email, reviewed the terms, chose the applicable rules, and keyed the structure into ATPCO by hand. The work was skilled and the team was good at it — but every contract had to wait its turn.
With thousands of contracts entering that queue each year, the realistic expectation the business set with itself was roughly ten days from approval to filed. Very little of that was the filing. Most of it was the queue.
Sales managers could not tell a corporate buyer when their negotiated fare would be live. Status lived in inboxes rather than in the CRM. And every additional contract signed made the queue a little longer — the process got slower precisely as the business got busier.
Nothing in this chain was broken. Each step made sense on its own. The cost was in the joins — every handoff introduced a wait, and every wait was invisible to the person who had signed the contract.
Fare filing is genuinely hard. Rules interact, geographies overlap, and a mistake is expensive. That reputation for difficulty is exactly why the whole process had stayed manual.
But looking across the queue, a pattern stood out. Standardized corporate contracts — the bulk of the annual volume — followed a predictable shape. Known fare structures. A finite set of rule combinations. Repeatable geography. Filing them took care and attention, but rarely judgement.
So the design question was never “can we automate fare filing?” It was the narrower and far more answerable “which contracts don't need a person, and how do we know that reliably?”
The automation targeted standardized contracts only — not every filing scenario the airline might ever encounter. Chasing full coverage would have produced a fragile system that automated the easy cases badly and the hard cases worse. Narrowing the scope is what made the outcome dependable.
Salesforce owns the business conversation. MuleSoft owns the transformation. ATPCO owns distribution. Each layer does the thing it is genuinely best at, and the boundaries between them are explicit.
The return path matters as much as the outbound one. Because status flows back into Salesforce, the contract record stays the single place anyone has to look — which is what removed the reconciliation work at the end of the old process.
None of the architecture above is visible to the person using it. A sales manager opens an approved contract and submits it. Everything else — validation, rule selection, transformation, submission, monitoring — happens behind that single action.
This is the part that determines whether an integration is actually adopted. The complexity did not disappear — it moved somewhere the business user never has to think about it.
A one-click process is only safe if it is confident about what it is filing. Validation runs before anything leaves Salesforce: completeness of the contract, consistency of the terms, applicability of the selected rules, and whether the contract fits the standardized pattern at all. A contract that fails is never submitted — it is returned with the specific reason it stopped.
Downstream is handled the same way. ATPCO's status APIs are monitored rather than trusted by default, and any rejection or warning is surfaced on the contract record with enough context for a specialist to act on it directly.
| Before | After | |
|---|---|---|
| Trigger | Email to the filing team | One button on the contract |
| Manual handoffs | Four | None for standard contracts |
| Where status lives | Inboxes | The Salesforce contract record |
| Turnaround | ~10 days | Under 4 hours |
| Specialist focus | Every contract | Exceptions only |
| Effect of volume | Longer queue | Absorbed by the automation |
The headline change is turnaround: from roughly ten days to under four hours. Worth being precise about where that time now goes — the automated preparation and submission itself takes between one and ten minutes. The remainder is ATPCO's downstream processing and distribution cycles, which are outside anyone's control and always were. What the automation removed was the part that was never really working time at all.
The second-order effects are the ones the commercial teams noticed. Sales managers can give corporate customers a credible answer about when a fare goes live. Contract status is visible in the CRM instead of reconstructed from email. And because the automation absorbs volume rather than competing for capacity, signing more contracts no longer makes the process slower.
Corporate contracts per year addressed by the automation at launch.
Reachable as the same pattern extends to further regions and contract types.
That headroom was designed in, not discovered later. Regional expansion was treated as a configuration and mapping question from the start, so widening coverage does not mean rebuilding the pipeline.
The hardest part of this system was never the button. It was the distance between how a commercial contract is described in a CRM and how a fare has to be described to a distribution network.
A single corporate contract spanning multiple tariffs and geographic regions can expand into something in the order of 100,000 lines of structured payload. That is not a data mapping exercise that belongs inside a CRM transaction. Salesforce is excellent at business interaction, approval and orchestration; it is the wrong place to assemble and hold a payload of that shape.
So the responsibilities were split deliberately. The Platform Event is the seam: Salesforce says this contract is validated and ready, and then stops. MuleSoft picks it up asynchronously, does the heavy transformation in DataWeave, owns the ATPCO data model, and handles the realities of talking to an external system — retries, partial failures, and status that arrives later than the request.
Middleware here isn't a default choice or a line on a stack diagram. It's there because the transformation is genuinely complex and the payloads are genuinely large — and because keeping that weight out of the CRM is what allows the CRM to stay responsive and understandable.
Business interaction, validation, approval, orchestration and the record of truth the business reads.
Transformation at scale, the ATPCO data model, and the resilience of an asynchronous external integration.
The value wasn't in automating fare filing. It was in recognising which filings never needed a person — and giving the people back the ones that did.
Axiom Gray helps organizations turn complex operational workflows into scalable, automated processes.
This case study describes the problem, architecture and outcome of the engagement at a deliberately general level. The customer is not named, and no internal system names, team structures, API payloads or contract data are disclosed. Figures are rounded and represent the scope and performance of the automation as designed. This engagement was led by Axiom Gray's founder prior to establishing the firm.