Assembly Software
One governed account model for Assembly Software, built inside its own data team
Assembly Software sells software to professional firms and wants one scored view of every customer and prospect. We work inside its business systems and data team, in its own Azure, building the governed model that scoring and reporting will run on.
B2B SoftwareGoverned customer and prospect modelForward deployed engineering
- Model
- Datics data engineering inside Assembly's data team
- Sources
- CRM, billing, product usage, calls, firmographics
- Runs in
- Assembly's own Azure SQL and Microsoft Fabric
- Status
- In progress
The challenge
Customer and prospect data sits in five systems that disagree about the same account, so scoring and reporting have no single record to stand on.
What we did
Datics data engineering works inside Assembly's data team and Azure: survivorship rules first, master layers in Azure SQL, Fabric once matching holds.
The outcome
The work is in progress. Assembly's team owns the platform, and every layer is documented so it can run and extend the model itself.
The starting point
Assembly Software is a B2B SaaS company whose customers are professional firms, described by size and practice areas. Its sales and marketing teams work in Salesforce, beside billing, product usage, call and firmographic data.
What had to change
Assembly wants one scored database of every current customer and every target prospect, so sales and marketing can see which accounts look like its best customers. Today the same account appears in several systems with conflicting values.
What could not break
- Everything is built in Assembly's own Azure and Fabric; Assembly owns the platform
- Assembly's IT and business systems lead sets the direction
- Every layer is documented so the internal team can run and extend it
- Scoring and reporting read the governed model, not copies of it
The calls we made
We treated the governed account model as the product: scoring and reporting are only as good as the merged record underneath them, so the model comes first and belongs to Assembly's team.
- 01
Survivorship rules before any pipeline
When two systems disagree, someone has to decide which one wins, and every later layer inherits that call. Our first questions were which sources feed the model first and whether such rules already exist.
- 02
Azure SQL first, Fabric once matching holds
The master account, contact and activity layers are designed in Azure SQL, and Microsoft Fabric comes in after entity resolution is solid, so its lakehouse and semantic models start from resolved records.
- 03
Reports on the governed model
Power BI reporting is planned on the governed semantic model, so every report reads the same merged accounts.
Ruled outSide exports that each describe the accounts differently.
- 04
Scores from Assembly's own history
Scoring is tuned to Assembly's retention, expansion and deal velocity signals, and a language model only fills and checks firmographic attributes on the merged records.
Ruled outA generic fit score.
How the system fits together
What we built
Master data layers
Schema for the master account, contact and activity layers in Azure SQL, with ingestion pipelines from Assembly's internal systems.
Entity resolution
Match, merge and survivorship rules that turn conflicting records into one master record per account.
Documentation for ownership
Each layer documented as it is built, so Assembly's team can run and extend the model after handoff.
A closer look
What changed
The work is in progress. The calls that shape the model, which source wins, Azure SQL before Fabric, reports and scores on the governed model, were made at the start with Assembly's team.
Under the hood
- Datics role
- Forward deployed engineering
- Access
- Assembly's own Azure SQL and Microsoft Fabric environment; Assembly owns the platform.
- Integrations
- Salesforce read and write back, Chargebee billing, Pendo product usage, Gong calls and ZoomInfo firmographics, with Fivetran ingestion.
Data and retrieval
Cloud and infrastructure
Apps and APIs
Also in the stack
How it shipped
Open questions first
Which sources feed the model first, and whether survivorship rules already exist; the answers set the order of work.
Master layers
Schema, ingestion and entity resolution in Azure SQL, now in progress.
Fabric and reporting
Lakehouse, semantic models and Power BI on the governed model once matching holds.
Scores and handoff
Enrichment, tiers written back to Salesforce, and handoff to Assembly's team.
In Assembly's team
We work within its business systems and data team, with direction from its IT and business systems lead.
In Assembly's environment
Every layer is built in Assembly's own Azure SQL and Microsoft Fabric, never on our side.
Built to be owned
Documentation travels with each layer, so the model stays with Assembly's team, not with us.
What this unlocked
Once the master record holds, Fabric, Power BI reporting and account tiers in Salesforce follow on the same governed model.
Related work
Have a product with the same kind of constraints?
Tell us what already exists and what you want it to do. We will tell you what it takes.