arrow_back Back

We built a multi-tenant SaaS on Microsoft Fabric with a workspace for every customer

Oct 02, 2026

Most Microsoft Fabric projects serve one organization. Ours had to serve many. A cloud cost management (FinOps) software provider asked us to build the data platform behind their product: collect each customer's Azure and AI spending, turn it into one standard format, and serve it to dashboards and an AI assistant. Every customer had to see only their own data, onboarding had to be automatic, and the platform had to grow region by region.

We built it entirely on Microsoft Fabric, with a dedicated workspace for every customer. This post walks through the design, the parts that made it work in production, and what we would tell any team building SaaS on Fabric.

We built a multi-tenant SaaS on Microsoft Fabric with a workspace for every customer

The challenge (pain points in real operations)

A single-tenant Fabric design is straightforward. Multi-tenant SaaS raises harder questions, and each one had to be answered before the first customer went live.

  • Isolation that can be proven: Customers trust you with billing data. "We are careful" is not enough. The platform had to show, automatically, that one customer's reports can never read another customer's data.
  • One codebase, many customers: Every customer needed the same pipelines, the same data model and the same app. Hand-built workspaces drift apart within weeks.
  • Onboarding without a project: Each new customer needed groups, storage, pipelines, a semantic model, an app and credentials. Doing that by hand would turn every sale into a mini-project.
  • Capacity cost: Fabric capacity is billed whether it is busy or idle. Sizing it for the heaviest nightly run all day would waste money.
  • Growth by region: Customers in different geographies expect their data to stay in region, and an incident in one region should not affect the others.

What we built (tailored solution, delivered end-to-end)

We designed the platform around three ideas: a regional deployment holds everything a set of customers needs, every customer gets their own workspace, and nothing is created by hand.

1. Regional deployments (growth and blast radius)

Customers are placed on regional deployments, sometimes called deployment stamps. Each deployment has its own Fabric capacity, Azure Key Vault, Azure Function Apps and a core Fabric workspace.

The core workspace holds the shared notebooks and pipelines, plus a Fabric SQL database that acts as the customer registry. The registry lists every customer with their workspace and lakehouse IDs, status and settings. Pipelines never hard-code a customer. They read the registry at run time.

Adding a region means standing up a new deployment from the same templates. An issue in one deployment stays inside it.

2. A workspace per customer (isolation by design)

Every customer gets a dedicated Fabric workspace containing:

  • Bronze, Silver and Gold lakehouses in a Medallion Architecture
  • A Direct Lake semantic model that holds every business measure
  • The customer-facing Fabric App, built with Microsoft's Rayfin SDK
  • A Fabric Data Agent that answers plain-English cost questions from that customer's model only

Access is controlled through Microsoft Entra security groups per customer. Each customer's Azure credentials live in Key Vault and are read at run time, never stored in code.

The important part is that isolation is tested. An automated check confirms that each customer's semantic model is bound only to that customer's own Gold lakehouse, and a read-only smoke test runs across every active customer on a deployment.

We built a multi-tenant SaaS on Microsoft Fabric with a workspace for every customer

3. One pipeline run for every customer (one codebase)

The transformation logic is written once and runs for everyone. A master pipeline reads the active customers from the registry, and a ForEach activity runs the per-customer pipeline for each of them:

  • Converting Azure, OpenAI, Anthropic and Microsoft Copilot spend into FOCUS, the open standard for cloud cost data
  • Cost allocation to teams, budgets, anomaly detection and savings recommendations
  • Reservations, price sheets and Microsoft 365 usage
  • A semantic model refresh at the end

Every notebook and pipeline lives in source control. Processing is incremental: a watermark table records what each customer has already processed, so nightly runs only touch new data.

Ingestion that needs customer credentials stays in Azure. Azure Durable Functions call the Cost Management API, Azure Resource Graph, Microsoft Graph and AI vendor usage APIs, and write Delta tables straight into each customer's OneLake. Azure cost export files reach Fabric through OneLake shortcuts, so raw files are never copied.

4. Onboarding as a workflow (one run instead of a project)

Onboarding a customer is a single automated workflow. It:

  1. Creates the Entra groups
  2. Adds the registry entry
  3. Creates the workspace and the three lakehouses
  4. Stores the customer's credentials in Key Vault
  5. Deploys the semantic model, the app and the Data Agent
  6. Runs the isolation check

Offboarding reverses it.

One detail saved us more than once. A semantic model fails to deploy if it references a table that has no data yet. We generate a skeleton schema listing every table and column the model expects, create empty tables from it at onboarding, and backfill new tables into existing customers. A CI test also checks that every column a notebook writes exists in the model, so a schema change cannot break every customer overnight.

5. Capacity that follows the workload (cost control)

Each deployment has two capacity sizes: a smaller resting size for daytime reading and a larger size for the nightly processing run. The capacity scales up before the run and scales down as soon as the master pipeline finishes, rather than after a fixed duration.

The app also caches semantic model query results against a data-version stamp, which removes repeated identical queries and keeps the capacity free for real work.

6. Customer-hosted delivery (data residency)

Some enterprise customers cannot allow their reporting data to sit in a supplier's tenant. For them, processing stays in the provider's tenant and only the finished Gold data is published into the customer's own Fabric tenant. The semantic model and app run there on the customer's capacity, and no copy is left on the provider's side.

That deserves its own post, and we will cover how we built and tested it separately.

Real-world impact (what changed after rollout)

  • Isolation you can show an auditor: An automated check proves each customer's model reads only their own data, on every deployment.
  • Onboarding in one workflow: A new customer goes from contract to live workspace, model, app and AI assistant without hand-built steps.
  • One codebase for every customer: A fix or feature in a notebook, pipeline or model reaches all customers in the next release.
  • Lower capacity cost: Compute is sized up only while the nightly run is actually running.
  • Room to grow: New regions are new deployments from the same templates, with problems contained to one deployment.

What we would tell any team building SaaS on Fabric

  1. Decide your isolation unit first. For us it was the workspace. Everything else, from access groups to deployment scripts, followed from that choice.
  2. Keep a registry and read it at run time. Pipelines that look up their customer list never need editing when a customer joins or leaves.
  3. Treat every Fabric item as code. Notebooks, pipelines, lakehouses and the semantic model all live in Git and deploy the same way to every workspace.
  4. Test isolation automatically. A check that runs on every release catches a binding mistake before a customer does.

If you are planning a multi-tenant product or a large data platform on Microsoft Fabric, we would be glad to share what we learned. Connect with us to talk through your architecture.

Lakshya Jain

Author

Lakshya Jain

As an AI Engineer, I specialize in architecting and deploying intelligent agent systems that integrate seamlessly with enterprise ecosystems. My work spans multi-agent design, orchestration frameworks, LLM optimization, and production-level AI engineering. I enjoy sharing insights and helping teams navigate the rapidly evolving world of applied AI.

More by Lakshya Jain
Xero Agent that turned hours of finance back-and-forth into minutes
Mar 17, 2026

A professional services client had a clear idea: finance teams and business stakeholders spend too much time finding answers in Xero instead of acting on them. We took ownership of the solution end-to-end - design, development, security model, and go-to-market - delivering a Finance Agent for Xero that works inside Microsoft Teams and can also be used as an extension point for Microsoft 365 Copilot experiences, so users can ask questions where they already work. The challenge (pain points in real operations) As the client scaled, finance operations didn’t just get “busier”—they got noisier and slower, because many business-critical answers lived behind manual steps and finance-team dependency: Hours lost in coordination: Business users (project managers, sales ops, leadership) needed frequent answers—“Which bills are pending?”, “What’s overdue?”, “Did this invoice go out?”, “What’s the latest P&L?”. The only reliable path was messaging the finance team, waiting for someone to check Xero, clarifying filters, and repeating the loop—often consuming hours end-to-end for what should be a quick question. Manual filtering and inconsistent results: Invoices and bills were searched by multiple criteria (date ranges, contacts, status, amounts, references). Different people used different filter combinations, so results could vary, creating rework and follow-up questions. Draft categorization bottleneck: Draft bills required coding/categorization before review and approval. During peak periods, drafts piled up, approvals slowed down, and finance had to spend time fixing categorization inconsistencies. Reporting delays for stakeholders: Leadership wanted near-instant Profit & Loss visibility and “attainment-style” performance views, but reports still required manual pull, formatting, and explanation—creating delays in meetings and decision cycles. Adoption risk from sign-in friction: Any solution that forces frequent reconnects fails in practice. Xero OAuth also has real constraints (refresh tokens can expire if unused, and refresh responses can include a new refresh token that must be stored), so token handling had to be designed for reliability.?   What we built (tailored solution, delivered end-to-end) We designed the agent around actual finance requests and approval behaviors, not around technical endpoints. 1) Secure tenant connection with uninterrupted access Users connect their Xero tenant with OAuth 2.0, which allows an app to access Xero data via permission scopes after user approval (without needing the user’s password).? Because Xero access tokens expire quickly (30 minutes), we designed the agent to refresh access automatically to keep the Teams/Copilot experience uninterrupted.   2) Natural-language finance operations (self-serve answers) Inside Teams (and surfaced through Copilot extensibility patterns), users can ask in plain language and get results in minutes: Invoices & bills retrieval using conversational filters (who, when, status, amount, references). Profit & Loss on demand using Xero’s reporting endpoints (including Profit & Loss support), so stakeholders can pull the view they need without waiting on finance.? Profit and revenue attainment views based on the organization’s tracking logic—delivering “decision-ready” outputs rather than raw tables.   3) Automated draft categorization with human review To remove the biggest operational choke point while keeping governance intact: When a bill is in Draft, the agent applies predefined categorization logic and proposes the coding. It then posts the recommendation back to chat for approve/reject, so finance retains control while eliminating repetitive preparation work.   Real-world impact (what changed after rollout) From hours to minutes: Before the agent, users often spent hours coordinating with finance to get invoice/bill answers and report snapshots. After rollout, many of those requests were completed in minutes through the agent in Teams—reducing finance dependency and speeding decisions. Efficiency gains across the finance workflow: Finance teams spent less time on repetitive lookups and pre-approval preparation, and more time on review, exceptions, and higher-value analysis. Improved consistency and reduced rework: Standardized categorization recommendations plus the approve/reject step reduced variability in coding and cut down on “fix it later” cleanups. Higher satisfaction and adoption: A consistent “ask in Teams / Copilot, get an answer” experience improved trust and usage, while explicit consent ensured the access model stayed enterprise-friendly.? Value beyond one tenant: Publishing to the Teams Store made these workflow improvements accessible to a broader audience of Xero users facing the same operational friction.

We Built Agents using Microsoft Frameworks That Actually Run in Production
Dec 02, 2025

AI has moved past the hype cycle and into a decisive phase. Enterprises are no longer impressed by demos or prototypes. They want solutions that can plug into real systems, support real workflows, and deliver real business outcomes. And this is exactly where the conversation around AI agents has taken a serious turn. Enterprises want AI that works inside real systems, not just in demos, and we have successfully built and deployed agents that operate in Microsoft Teams and Copilot at production scale. Enterprises today are shifting rapidly from AI experimentation to full-scale deployment. Executives are no longer asking, “Can we use AI?” They are asking, “How do we integrate AI into our existing workflows, systems, and teams in a reliable and secure way?” This is where many organizations hit a wall. Building an intelligent agent in a lab is one thing. Deploying it inside Microsoft Teams, Microsoft Copilot, or enterprise applications at scale is an entirely different challenge. And that is exactly the journey our team has been leading. Over the past year, we have moved from early-stage proof of concepts to delivering fully production-ready AI agents that operate inside real enterprise environments. We have built agents using Microsoft Semantic Kernel, Microsoft Agent Framework, LangChain, and other orchestration tools. Through this work, we have seen how these technologies bridge the gap between AI capabilities and real business needs. Semantic Kernel continues to be a critical part of our architecture, providing the orchestration foundation needed for maintainability, scalability, and extensibility. 1. Why Semantic Kernel Is the Backbone of Enterprise AI Agent Development Semantic Kernel enables AI systems to work with enterprise applications without disruption. For agent-based systems, this orchestration layer is essential. Through our implementation work, we have seen how Semantic Kernel supports: Smooth integration with legacy and modern platforms Centralized orchestration logic for multi-agent workflows Plugin-based extensibility that accelerates development Production-ready governance and maintainability This means AI agents do not sit on the side as isolated tools. They become operational digital co-workers embedded in real systems. 2. Our Journey From POCs to Production-Ready AI Agents Most companies stop at experimentation. We continued through to full deployment. Below is a summary of what we have built. A. AI Agents Using Semantic Kernel, Microsoft Agent Framework, and LangChain We have delivered multi-agent ecosystems using: Microsoft Semantic Kernel as the orchestration layer Microsoft Agent Framework for standardized agent structure LangChain for reasoning and tool coordination Azure OpenAI and other LLM services for generative intelligence These agents now support tasks such as: Multi-step planning Task decomposition Enterprise data retrieval Knowledge reasoning API-driven action execution B. Taking AI Agents From Pilot to Production Scaling prototypes into production required addressing challenges such as: Security and identity governance Observability and monitoring Performance optimization Reliability of multi-agent workflows Plugin maintainability Integration with enterprise APIs Human validation checkpoints Today, our agents are supporting real business operations, not just test environments. C. Agents Integrated Directly Into Microsoft Teams and Microsoft Copilot One of our major achievements is building fully operational agents inside Microsoft Teams and Copilot using pro-code solutions. These agents: Support employees directly inside their daily collaboration tools Trigger workflows and gather insights Retrieve knowledge from enterprise repositories Generate summaries, reports, and recommendations Execute system-level tasks through plugins and connectors This approach ensures high adoption because employees do not need to change the way they work. D. Using Semantic Kernel as the Orchestration Layer for Long-Term Scalability To ensure consistent architecture, we use Semantic Kernel as the foundation for: Memory management Skill and plugin organization Planning capabilities Reusable workflows Integration patterns Model-agnostic orchestration This is what allows our solutions to evolve without complete rewrites. 3. The Business Value We Are Delivering With Enterprise AI Agents Based on our production deployments, AI agents are driving value in areas such as: IT Operations Incident classification Automated diagnosis Recommendation and remediation assistance Knowledge Management Conversational search across documents and systems Automated summarization Fast retrieval of organizational knowledge Workflow Automation Streamlining approval processes Triggering ERP and CRM actions Coordinating tasks between departments Employee Productivity Drafting documentation and reports Generating meeting summaries Automating repetitive daily tasks inside Teams These are not theoretical examples. These are use cases we have taken from pilot to production. Actionable Insights: How Enterprises Can Start Their Own Agent Journey 1. Begin With a Focused Use Case Select a workflow that is high-effort and well understood. Examples include knowledge retrieval, IT incident classification, or automated document creation. 2. Invest Early in a Plugin Strategy Plugins become reusable skills for every agent your organization builds. This creates long-term scalability. 3. Standardize on Semantic Kernel for Orchestration This provides consistency across agents and reduces complexity as the ecosystem grows. 4. Work With a Partner Who Has Delivered Production-Ready Agents Enterprise-grade AI requires expertise in: Agent frameworks AI orchestration Microsoft ecosystem integration Security and governance Production deployment disciplines Our team brings this end-to-end capability, from design to deployment to continuous improvement. Conclusion AI agents are quickly becoming a core part of enterprise operations. But real value comes only when these agents move from experimentation into production environments. By leveraging Microsoft Semantic Kernel, Microsoft Agent Framework, and LangChain, we have successfully built and deployed AI agents inside Microsoft Teams and Microsoft Copilot using pro-code, enterprise-ready architectures. These systems are already powering real workflows and supporting real users. The organizations that act now will gain a significant advantage. We are excited to help shape this next chapter in enterprise AI adoption. 4. Call-to-Action If your organization is exploring AI agents or preparing to move from prototypes to production, we would be glad to collaborate. Connect with us for more insights on enterprise AI, agent orchestration, and Microsoft-based digital transformation.