Workspaces and roles

By the third hub session, on Thursday, October 22, the trial capacity held one workspace called Nikolai Sandbox, full of half-finished experiments. Nikolai deleted it in front of Ines and Keiko and said the real design started now. A workspace in Fabric is the container where items live: lakehouses, warehouses, notebooks, pipelines, semantic models and reports. It is also the main unit of access, of capacity assignment and of lifecycle management. Getting the workspace layout right early saves a great deal of reorganizing later, because moving items between workspaces is possible but not always simple.

What a workspace holds and controls

Every workspace is assigned to one capacity, belongs to at most one domain, and has a set of people or groups in roles. It can be connected to a Git branch, as lesson 9 describes, and assigned to a stage of a deployment pipeline, as lesson 10 describes. It has its own settings for Spark, such as the default pool and runtime version, and can have a workspace identity. Inside a workspace, folders can organize items, so a workspace with thirty items can group pipelines, notebooks and models without splitting into several workspaces.

Each user also has My workspace, a personal area for experiments. It is fine for trying something out, but content there cannot be shared through workspace roles, cannot be part of a deployment pipeline and leaves with the person. Nikolai's rule for the hub was simple: nothing anyone else depends on lives in My workspace.

The four workspace roles

Access to a workspace is given by adding a user, a Microsoft Entra security group, a Microsoft 365 group or a service principal to one of four roles. The roles are cumulative: each includes what the one below it can do.

Two details trip people up. The first is that Admins, Members and Contributors can read all the data in the workspace's OneLake items, whatever finer rules exist. OneLake security roles, row-level security and column-level security, covered in lesson 7, restrict Viewers and people given access to individual items; they do not restrict the three higher roles. Anyone who must not see some rows of a table should not be a Contributor in its workspace. The second is that a Viewer can run SQL queries through a lakehouse's SQL analytics endpoint and see the results, depending on the endpoint's security settings, even though they cannot open the files in OneLake directly. Viewer means view and query, not see nothing.

Groups, not people

Roles can be given to individual users, but the hub assigns them to groups. With nine workspaces planned, giving each person a role in each workspace by hand would mean dozens of assignments to keep in step every time someone joined or left. With groups, a new analyst is added to one Entra group and immediately has the right access everywhere. Renata's identity team already managed groups through the company's joiner and leaver process, so access would follow employment automatically.

Elena questioned the Viewer role for engineers in production. Would Ines not need to fix a failed load at three in the morning? Nikolai's answer was that changes to production should come only through the deployment pipeline, run by a service principal or by the leads, and that a failed load would be rerun, not edited, in production. If an emergency fix ever needed direct access, a lead could add Ines to the Member role for an hour and remove her afterwards, and the change would show in the audit log. Elena accepted that, with the condition that the emergency process be written down before the pilot.

How many workspaces?

There is no single right number, but a few principles guided the hub's layout. A workspace should hold items that share the same people and the same lifecycle. Because roles apply to the whole workspace, items with very different audiences belong in different workspaces; finance data that only five people may see should not sit beside store sales that two hundred people read. Because a deployment pipeline promotes a workspace's content stage by stage, each stage needs its own workspace: one for development, one for test and one for production. And because domains group workspaces, each workspace should clearly belong to one business area.

That reasoning gave three domains times three stages, nine workspaces in all, named FDH Sales [Dev], FDH Sales [Test], FDH Sales [Prod] and so on. Keiko asked whether the reports should live in the same workspaces as the lakehouses. Many teams separate them, putting data items in one workspace and reports in another, so that report authors can be Contributors to the report workspace without being able to change the data. For the pilot, with one reporting team, Nikolai kept them together and noted it as a decision to revisit once other departments started building their own reports on the hub's semantic models.

Workspace settings worth knowing

The workspace settings pane has many options. Several appear in exam questions.

Workspace identity

Pipelines, shortcuts and semantic models often need to sign in to something outside Fabric, such as a storage account or a database. They can use the credentials of the person who set them up, but that ties the connection to someone who may leave. A workspace identity is an automatically managed service principal that belongs to the workspace. A workspace admin creates it in the workspace settings, and Fabric creates a matching app registration and enterprise application in Microsoft Entra ID, managing its credentials so nobody handles a secret. The identity can then be granted access to an Azure resource, for example the Storage Blob Data Reader role on a storage account, and used by connections and shortcuts in that workspace.

Workspace identity also enables trusted workspace access. A storage account can keep its firewall closed to the internet and still allow specific Fabric workspaces through a resource instance rule, so that shortcuts and pipelines in those workspaces can reach it while nothing else can. A workspace identity needs the workspace to be on an F capacity, not a trial or a Power BI Pro workspace. Nikolai planned to create workspace identities in January, when the hub workspaces moved to the paid capacity, and to grant each one access only to the storage it needs.

Naming, descriptions and contacts

A workspace name is the first thing people see in the OneLake catalog and in lineage, so the hub adopted a pattern from the start: the prefix FDH for Finch Data Hub, the domain, and the stage in square brackets. Every workspace also gets a one-sentence description saying what it is for and who owns it, and a contact list naming the leads group rather than one person. When a store manager in 2028 finds a semantic model and wonders whom to ask about a strange number, the contact list answers the question. Item names follow a similar pattern, with short prefixes such as lh_ for lakehouses, wh_ for warehouses, nb_ for notebooks and pl_ for pipelines, so the type is clear even in places where Fabric does not show an icon.

Deleting and restoring

Deleting a workspace removes every item in it. Fabric keeps a deleted workspace for a retention period, during which a Fabric administrator can restore it from the admin portal; after that it is permanently removed. The length of that period is a tenant setting, and the hub's administrators checked it on day one rather than in the middle of an emergency. Individual items have their own recovery features: Git integration lets a team recreate an item's definition from the repository, and lakehouse and warehouse data have features such as Delta table history and warehouse restore points, covered in lessons 5 and 6. None of these replace thinking about who can delete things. Keeping engineers out of the Admin role in production removes the most likely way an important workspace gets deleted by mistake.

Moving items between workspaces

Items cannot always simply be dragged from one workspace to another. Reports can be copied or rebound to a semantic model in another workspace, and many item types can be exported and imported through Git or deployment pipelines, but data items such as lakehouses carry their OneLake folders with them and are best rebuilt in the right place. That is why Nikolai deleted his sandbox instead of trying to move its contents. The practical lesson is to decide the workspace layout before building anything that matters, and to treat a lakehouse's workspace as its permanent address.

Service principals and automation

People are not the only members of workspaces. A deployment process, a scheduled script or an external orchestration tool signs in as a service principal, an application identity in Microsoft Entra ID. For a service principal to call the Fabric REST APIs at all, a Fabric administrator must allow service principals in the tenant settings, usually for one security group that holds the approved ones. Once allowed, the service principal is added to a workspace role like any user. The hub's deployment service principal is a Member of the test and production workspaces so it can deploy content there, and has no role in development, where people do the building. Keeping automation identities in their own group, with names that say what they are for, makes the audit log readable when something changes at night.

Who can create workspaces

By default, many tenants let any user create a workspace, which is how workspace sprawl begins. A Fabric administrator can restrict workspace creation in the tenant settings to specific security groups. Renata limited it to the hub leads and the IT service desk on October 28, and set up a short request form for anyone else. Capacity assignment is controlled separately: even a person who can create a workspace cannot put it on a paid capacity unless the capacity admin has allowed them. Between the two settings, the company can let people experiment in My workspace while keeping shared, paid compute for planned work.