Skip to main content
TechExplainedTechExplained
|
How-toLevel: Advanced

How to set up Microsoft Fabric

The setup decisions you make in the first month and carry with you for years: tenant, capacities, workspaces, domains and governance.

TechExplained 3 min readPublished: 25 April 2026Last updated: 25 April 2026
#governance#capacity#workspaces#how-to
Enterprise architect configuring Microsoft Fabric governance, capacities and workspaces.
All how-tos
  1. 01

    Tenant settings and guardrails

    Before the first workspace, go through the tenant settings: who may create Fabric items, what may go out (export, sharing with external users), and which preview features you deliberately turn off. An open tenant "to get started" becomes unmanageable within months.

    And decide Private Link early. Fabric has two levels: tenant-wide and per workspace. The tenant-wide setting can temporarily affect certain features when enabled and rolling it back is disruptive; workspace-level Private Link gives you that same isolation per workspace and requires an F SKU (P SKU and trial do not support it). Test it in a separate tenant before you turn it on.

    Decision
    freedom per persona. Data engineers get more room than casual users, arrange that with security groups, not with individual exceptions.
  2. 02

    Capacity strategy

    Decide how many capacities you need and for what. One large capacity is efficient but makes everyone each other's neighbor; separate capacities for development and production keep an experiment from taking down your monthly reporting.

    Decision
    at minimum a separation between production and non-production. Set up capacity monitoring from day one, otherwise you only discover throttling when users complain. And know that the home region of the capacity determines your data residency: whoever promises EU residency locks that choice in here.
  3. 03

    Workspace topology

    Choose an organizing principle and stick to it. Per data domain (sales, logistics, finance) with separate workspaces per environment (dev, test, prod) is the most durable for most organizations. Avoid organizing per team or per person, organizations reorganize, domains stay.

    Decision
    naming convention before the first workspace, not after. Renaming is possible, but cleaning up all references is tedious work.
  4. 04

    OneLake and domains

    Set up domains that reflect your data landscape and assign domain owners. Use shortcuts to surface existing data without copying. That works internally (Lakehouse, Warehouse, KQL database, SQL database, mirrored database, semantic model) and externally (ADLS Gen2, Azure Blob Storage, Amazon S3 and S3 compatible, Google Cloud Storage, Dataverse, Iceberg, OneDrive and SharePoint), and through the on-premises data gateway to your own datacenter as well. Every copy you avoid is governance you do not have to catch up on.

    Decision
    one domain per business unit with a single designated domain owner, not per team. Document which shortcuts exist and why, a shortcut without an owner is nobody's responsibility a year from now.
  5. 05

    Deployment and version control

    Connect workspaces to Git (GitHub or Azure DevOps) and set up deployment pipelines from dev to test to prod. Do this at the first real project, not "later", adding it afterwards means manually migrating everything that is already there. Not every item type is Git-connected; check per workload what is supported and handle the rest with the Fabric REST APIs, the Fabric CLI (fab), the Terraform provider for Fabric or fabric-cicd.

    Decision
    automate deployments with a service principal, not a personal account or a shared password. Give that principal the least necessary role and expand it where needed, do not start broad "to just get it working".
  6. 06

    Monitoring and cost

    Set up the Microsoft Fabric Capacity Metrics app, configure alerts on sustained high load and make someone the owner of the capacity budget. Discuss monthly which workloads consume the capacity; the biggest consumers are rarely the most important workloads.

    Decision
    a hard alert threshold (for example sustained load above eighty percent) with a single owner who acts on it. Without an owner, "everyone watches capacity" becomes, in practice, "nobody looks at it".

The order matters

Guardrails, capacity and topology first; content after. Every week earlier of "just getting started" you buy back with months of cleanup, the least fun form of data migration there is.

The process at a glance

Click a step for its key decision

Decision

Tenant settings and guardrails

freedom per persona. Data engineers get more room than casual users, arrange that with security groups, not with individual exceptions.

Read next

How to set up Microsoft Fabric | TechExplained