BluLogix CIS: Telecom Billing Meets Salesforce via ETL

There is a specific category of integration problem that looks straightforward on a whiteboard and then teaches you something every week for a year. The CIS-to-Salesforce integration at BluLogix was that problem.

BluLogix builds the Cloud Innovation Suite (CIS) — a cloud billing platform for telecom operators. Not generic SaaS billing. Telecom billing specifically: usage-based charges, plan hierarchies, promotional pricing, bundle management, mid-cycle adjustments, prorated invoices. The kind of billing complexity that only people who have been in it can fully appreciate. I was team lead and developer on the front-end side and led the Salesforce integration work from 2013 to 2014.

Why telecom billing is its own domain

Telecom billing is not a simplified version of general billing. It is a distinct discipline with distinct data models.

A telecom operator’s billing system tracks usage — calls, data, SMS — at the event level, aggregates those events against plan entitlements, applies tiered and promotional rates, generates invoices, handles credits and adjustments, manages payment cycles, and produces the regulatory reporting that telecom operators are required to file. All of this happens at scale, continuously, for every subscriber on the network.

The data model reflects that complexity. A subscriber has a service profile. The service profile has one or more plans. Each plan has entitlements, overages, and promotional modifiers. Usage events arrive continuously and have to be rated against the correct plan version for the period in which they occurred — because the subscriber may have changed plans mid-cycle, or the operator may have changed the plan’s terms, and the historical rating has to be correct.

This is CIS’s domain. It knows this domain deeply. The problem is that CRM systems — Salesforce specifically — know a different domain entirely.

The incompatible data models problem

Salesforce is built around the CRM object model: Accounts, Contacts, Opportunities, Leads, Cases. It knows about customers and deals and support tickets. It does not know about subscribers and service profiles and usage events and rating cycles.

The integration requirement was real: the telecom operators using CIS also used Salesforce for their sales and support operations. A subscriber in CIS had a corresponding Account in Salesforce. A CIS plan change that the support team initiated in Salesforce needed to flow to CIS without the support agent needing to log into CIS separately. Billing history needed to be visible from within the Salesforce interface without requiring a separate login.

These are reasonable product requirements. They are also, in practice, a data-model translation problem in both directions simultaneously.

Talend ETL: the integration layer that actually shipped

The approach was Talend ETL — an enterprise ETL platform — as the integration layer between CIS and Salesforce. Not a direct API integration, not a custom middleware service, but a dedicated ETL job orchestration layer that owned the translation responsibility explicitly.

This was the right call for several reasons that only became fully clear in retrospect.

The transformation is stateful. Mapping a CIS subscriber to a Salesforce Account is not a one-time translation. It is an ongoing synchronization. Changes flow in both directions. The ETL layer tracks synchronization state, handles conflicts, and manages the history of what has been synced — which is a different job than the CIS billing engine or the Salesforce org should be doing.

The failure modes are different. A direct API integration between two production systems couples their failure modes: if Salesforce’s API is slow, does that slow down CIS? If a CIS event fails to push, does the support agent in Salesforce see stale data or an error? The ETL layer decouples those failure domains. CIS runs, Salesforce runs, the ETL layer handles the gap.

The business rules live in one place. The mapping from CIS service profile to Salesforce Account fields is a business rule. So is the mapping of plan status to opportunity stage. Having those rules live in the ETL job configuration rather than scattered across both systems made them auditable, testable, and changeable without touching either production system.

BPMN workflow design

The billing workflows and the integration workflows were modeled in BPMN — Business Process Model and Notation. Not as documentation after the fact, but as the specification that the workflow engine executed.

This distinction matters. BPMN-as-documentation is a diagram that is accurate on the day it is drawn and then drifts from reality. BPMN-as-execution is the authoritative definition of what the system does. When the telecom operator’s sales team wanted to understand why a plan change had not propagated to Salesforce yet, the answer was a BPMN diagram that showed exactly where in the workflow the job was, what condition it was waiting for, and what the next step would be.

I led the BPMN workflow design for the integration side. The challenge was that telecom billing workflows have natural timing dependencies — you cannot update Salesforce with invoice data before the invoice cycle closes — that had to be expressed as explicit wait conditions in the workflow model, not as sleep timers or cron schedules. The difference is that the BPMN workflow knows why it is waiting and can respond correctly when the condition resolves, instead of polling until a timer fires.

Front-end: GWT in 2013

The CIS front-end was built on GWT — Google Web Toolkit — which compiles Java to JavaScript. In 2013 this was a reasonable architectural choice for a complex enterprise data application. The type safety that Java provides across a large codebase with many contributors is not trivial. The component model was mature. The debugging tooling was better than the JavaScript ecosystem’s alternatives at the time.

It is also, in 2026, a technology choice that has been decisively superseded. The web platform has moved. JavaScript frameworks have converged on patterns that make the GWT trade-offs unnecessary. I mention it plainly because it is part of the honest accounting of the work: I built significant UI in GWT, I led a team doing GWT development, and I can tell you exactly why that choice made sense in 2013 and exactly why I wouldn’t make it today.

The I supervised and led the front-end development team — code review, architecture decisions, the kind of task-level coordination that makes the difference between a team that ships and a team that produces pull requests that never merge. This was my first experience in a genuine team-lead role, and the lessons from it (about technical decisions at the team level, about the gap between knowing how to do something and knowing how to explain it to someone who is learning) have stayed with me through every subsequent role.

What I’d tell myself going into it

The incompatible data model problem between two enterprise systems is almost never solved by making either system more flexible. It is solved by owning the translation layer explicitly, giving it the right responsibilities, and not letting either side pretend the other’s model doesn’t exist.

The Talend ETL layer worked because it took the translation job seriously as a job — not as a thin adapter bolted onto an existing API. It had its own state. It had its own failure handling. It was responsible for the gap between CIS’s world and Salesforce’s world, and it knew that responsibility clearly.

That model — own the boundary, don’t pretend it’s thinner than it is — is the thing I’ve reached for in every integration problem since. Different tools, same insight.