Skip to main content
New: Try our AI Chatbot assistant — click the chat icon in the bottom-right corner to get started.
Solutions

The systems we've built
so you don't have to.

Some problems come up repeatedly — in different organisations, different sectors, different team sizes. These are the approaches we've refined into proven, repeatable solutions. Not bespoke each time. Built once, deployed many.

CI/CD & Automation

Declarative Power BI deployment pipelines

Four environments. Approval gates. Zero babysitting.

A repeatable CI/CD architecture for Power BI that treats workspace deployments the same way software teams treat code releases — version-controlled, automated, and auditable.

How it works

Declarative JSON workspace config

Every workspace is defined in a versioned JSON file — membership, permissions, datasets, reports. The config is the source of truth. The pipeline reads it; humans don't touch workspaces directly.

Azure DevOps YAML pipeline

Each environment (dev, test, UAT, prod) is a separate pipeline stage with its own approval gate. Finance and Actuarial sign off on UAT before anything reaches production. The pipeline handles promotion, not a person.

PowerShell module layer

Custom modules wrap the Power BI REST API and Graph API — workspace creation, dataset binding, RLS assignment, capacity attachment. Idempotent, rerunnable, logged.

Service principal auth throughout

No personal accounts. No expiring tokens. Service principals managed in Azure Key Vault, rotated on schedule, scoped to exactly what each pipeline stage needs.

What you get
Deployments that run unattended across all four environments
Full audit trail — every release, every approver, every change
New workspaces provisioned from config in minutes, not hours
Personal accounts removed from every production process

Stack

Azure DevOps (YAML)PowerShellPower BI REST APIGraph APIAzure Key VaultService PrincipalsEntra ID
Developer Tooling
Live tool

DriftKit — Power BI schema comparison and deployment

Connect two datasets. See exactly what changed. Deploy selectively.

DriftKit solves the problem of not knowing what's different between two versions of a Power BI semantic model — across environments, across time, or between a local BIM file and a live service dataset.

How it works

Connect any two sources

Source and target can be any combination: a .bim file, a TMDL folder (ZIP), or a live Power BI Service dataset via XMLA endpoint. Azure AD authentication handles live service connections with full OAuth flow.

Schema normalisation and diffing

Both schemas are normalised into a comparable object model — tables, columns, measures, relationships, roles, perspectives. The diff engine identifies added, modified, and removed objects at property level, not just object level.

Property-level DAX diff

For measures, calculated columns, and calculated tables, DriftKit renders a token-level diff of the DAX expression — identical to a code review diff. Changed lines are highlighted; unchanged lines are collapsed.

Selective deployment or BIM merge

Choose which changes to apply. Dependency validation runs before deployment — broken references are flagged before a single TMSL command executes. Deploy to service or download a merged .bim file.

What you get
Know exactly what changed between any two model versions before touching production
Deploy only the changes you choose — skip regressions, retain partitions
Review DAX changes like code — line by line, token by token
Session history saved to Firestore — compare, revisit, share

Stack

ReactFirebaseXMLA (SOAP)Power BI REST APIAzure AD / MSALCloud FunctionsTMSLBIM / TMDL
Apply these to your environment

Same system, your stack.
We'll adapt it.

These aren't hypothetical architectures. They run in production today. Tell us your environment and we'll scope what it takes to implement them for your organisation.