The technical approach
No proprietary platform, no exotic stack. Meles builds on Microsoft Fabric and Azure using patterns your team can read, run and extend — with logging, error handling and governance treated as part of the build, not an afterthought.
One governed flow, layered deliberately
The default shape: source systems land raw into a Fabric lakehouse, transformations produce cleaned and modelled layers, a semantic model defines the business logic once, and everything downstream — Power BI, exports, data agents — reads from that single model.
How each layer is handled
- Source systemsD365 F&O · APIs · SQL · files
- Dynamics 365 Finance & Operations is sourced into Fabric per environment — Fabric link / Synapse Link where available, entity exports or OData/REST where they fit better — chosen on volume, latency and licensing. Transformations run as PySpark notebooks and Fabric pipelines; downstream consumers read through the lakehouse SQL endpoint and the semantic model. Other sources connect through REST APIs, database connectors or scheduled file ingestion. Every source gets an owner, a refresh contract and a documented scope.
- Pipelines & notebooksFabric pipelines · Spark / Python
- Ingestion and transformation run as Fabric pipelines and notebooks: idempotent, parameterised, and re-runnable without side effects. Transformations are code in version control, not undocumented clicks in a UI.
- Lakehouse layeringraw → cleaned → modelled
- Raw data lands unmodified so there is always a source of truth to reconcile against. Cleaning (types, deduplication, reference data) and business logic are separate, testable steps — so when a number looks wrong, you can see exactly where it changed.
- Semantic modelPower BI / Fabric semantic models
- One model defines measures, relationships and row-level security. Reports connect to the model, not to raw tables — which is what makes "two reports, two answers" structurally impossible rather than just discouraged.
- API & system integrationsREST · OData · SFTP · scheduled sync
- Point-to-point integrations between business systems are built with the same discipline as pipelines: documented contracts, retry and error behaviour defined up front, and logging that tells you what was synced, when, and what failed. That includes document flows over SFTP and JSON/XML message processing — the formats ERP integrations actually speak.
- Logging & monitoringrun logs · alerts · data checks
- Every pipeline writes structured run logs. Failures alert a human. Basic data-quality checks (row counts, reconciliation totals, freshness) run as part of the flow, so silent failure — the worst kind — is designed out.
Agent workflows: scoped, read-only, traceable
A data agent here is not a chatbot pointed at a database. It's a constrained workflow that operates on the governed layer, with explicit boundaries:
What the agent can see
- The semantic model and curated, modelled tables — not raw production systems.
- Metadata first: schemas, definitions, refresh status, documented assumptions. The agent maintains a durable metadata index and workspace memory, so recurring questions reuse validated paths instead of starting from scratch.
- Scoped queries with row limits, aggregations and sanitized outputs by default.
What the agent cannot do
- Write to production finance systems — access is read-only unless a change is explicitly approved.
- Return raw sensitive records (ledger lines, vendor, customer, invoice, payment or security data) without scoping and sanitization.
- Answer from thin air: every response maps back to named sources and documented definitions.
See Albert, the Meles data agent, work step-by-step in the demo →
Access and ownership, made explicit
Workspace & access model
Separate workspaces for development and production, access through your Entra ID groups, least-privilege by default. Meles works inside your controls, not around them.
Definitions with owners
Each business definition in the model has a named owner on your side. Changing what "margin" means is a decision, logged and versioned — not a silent edit.
Everything handed over
Code in your repos, documentation in your wiki, credentials in your key vault. The exit path is part of the architecture from day one.
Talk architecture first, contract later
Happy to look at your current setup — sources, existing reports, pain points — and give a straight technical opinion before anything is scoped.