Request and Change

All changes to the platform are standard changes: you describe what you want, the change is made in the Terraform configuration, reviewed and deployed by the pipeline. You do not change workspaces, connections, gateways or storage in the Azure portal or the Fabric portal, because the next pipeline run would revert it.

Which intake you use depends on your platform (Operating models).

How a change travels

A change always has a ticket (the record) and a pull request on the platform repository (the change).

flowchart TD
    A["You raise a request"] --> B["Ticket in your own Azure DevOps or GitHub"]
    B --> C{"Enough information and in the platform team's scope?"}
    C -->|"yes"| D["Platform team makes the Terraform change and opens a pull request"]
    C -->|"no, it is in your scope"| E["Platform team points to the place in the repository, you open the pull request"]
    D --> F["Review and approval by the platform team"]
    E --> F
    F --> G["Pipeline deploys the change"]
    G --> H["Ticket updated and closed"]

Two routes lead to a ticket:

Route	How it works
Self-service portal	In the managed model you can submit the request in the Xebia self-service portal (Cloud Command). It creates a ticket in your own developer environment (Azure DevOps or GitHub), so the request is visible and auditable in your tooling.
Your own tooling	You create the ticket directly in your Azure DevOps or GitHub. In the managed model it is synchronised to the tooling of the platform team.

Two delivery paths lead from the ticket to a pull request:

Path	When	What happens
Processed by the platform team	The request has enough information	The platform team makes the Terraform change, opens the pull request against the platform repository and links it on the ticket
Implemented by the workload team	The change is within your scope or ownership	The platform team comments on the ticket with the place in the repository where you open the pull request. The platform team reviews and approves it.

Progress is visible on the ticket and the linked pull request. After approval the pipeline deploys the change.

In the self-managed model the intake is your own team's (Operating models); the flow is the same.

No manual changes

The repository is the single source of truth. Manual changes to managed resources are reverted on the next run. What you add yourself inside a workspace (for example extra role assignments by a workspace admin, or your own items) is not managed by Terraform and stays. See Access and roles.

What you can request

Request	Notes
New workspace	Name key, capacity, role groups, optional Git link. See New workspace.
Change role groups	Admins, contributors, members, viewers.
Create or delete a Lakehouse or Warehouse	Names must be unique across Lakehouses and Warehouses of a workspace.
ADLS, SQL or Oracle Cloud Storage connection	See Connectivity.
Workspace-to-workspace connection or managed private endpoint	See Connectivity.
Git link	See Connectivity.
Scale the capacity or change the SKU	Changes the cost. See Cost optimisation.
New storage container	Done by adding an ADLS connection.

For a request, always give: the environment and workspace, what you want changed, and why (it ends up in the ticket as the change record).

New workspace

Field	Required	Notes
Environment	yes	development, test, acceptance or production
Workspace key	yes	Part of the workspace name (<workload>-<env>-<region>-<key>).
Capacity	yes	The capacity key to use. It must be a capacity that the platform has defined for the environment.
Group for each role	no	Contributors, members, viewers and the optional admins group. Give the Object ID of an Entra ID security group, or its display name. The ID wins if both are given.
Outbound network policy	no	Default is the protected setting (outbound deny). Read Workspace network policy before asking for a different value.
Git link	no	Owner, repository, branch and directory. The directory must already exist in the repository, otherwise the deployment fails.
Lakehouses	no	Name, description and whether schemas are enabled
Warehouses	no	Name, description and collation: Latin1_General_100_BIN2_UTF8 or Latin1_General_100_CI_AS_KS_WS_SC_UTF8

One role per group

Fabric allows one role per principal per workspace. The same group cannot be Admin and Contributor. The plan reports duplicates (see Access and roles).

Connections and their secrets

For ADLS, SQL and Oracle Cloud Storage connections you do not give credentials in the request. The credentials are secrets in the Key Vault of the spoke. The configuration refers to them by secret name, and you or your identity team put the secret in the vault. Ask the platform team for the vault and the agreed secret names. Details and fields are on Connectivity.

What the platform team checks

Check	Why
The plan shows only the expected changes	Workspaces must not be recreated by accident
Group IDs are correct and unique per workspace	Fabric rejects duplicates
Secret names exist in the Key Vault	The connection resources read them at plan time
The capacity key exists	Validation fails otherwise
Capacity SKU change fits the budget	Cost impact

After the deployment

You get a message on the ticket. Role assignments are instant, non-disruptive API calls and can be rolled back by removing them from the configuration. The VNet data gateway sleeps when it is not used and wakes on the next request, so the first use after a quiet period can be slower.