Fabric Desktop for Databricks projects

Fabric Desktop provides a guided interface over the same Fabric Harness project files and fh CLI used by terminal and CI workflows. A project binding stores non-secret workspace defaults, while credentials remain in Desktop's source credential manager and Databricks authorization remains the authority for every workspace operation.

Enable the project workflow

During release certification, start Desktop with the project workflow enabled:

FABRIC_FEATURE_DATABRICKS_PROJECTS=1 bun run electron:dev

The feature flag is a Desktop release control. It does not change Harness CLI behavior or weaken the authentication requirements of a generated App.

Create a bound project

1. Create a project and choose a Databricks recipe.
2. Select one workspace identity. For local development, choose databricks-oauth and Databricks CLI OAuth. Desktop reads profiles with databricks auth profiles --output json, derives the workspace URL from the selected profile, and refreshes tokens every 30 minutes.
3. Use the inline Configure control when the identity is not yet verified. Desktop calls the workspace identity API before displaying Verified. OAuth-app U2M, service-principal M2M, and an explicit PAT source remain available for environments that require them.
4. Choose Discover workspace resources and select the resources requested by the recipe.
5. Create the project. Desktop scaffolds the recipe and writes the selected non-secret identifiers into .env.example and the project binding.

Optional APIs are discovered independently. For example, missing permission to list Apps does not prevent a SQL-only project from selecting its Warehouse. When a required API cannot be listed, the wizard accepts the stable resource identifier directly.

SQL Warehouse, Unity Catalog, and Vector Search tools reuse this verified workspace identity. They do not ask for or store duplicate tokens. Changing the identity updates the linked capability sources to the same normalized workspace origin.

The project binding resembles the following. It contains no access token, client secret, or App API token:

{
  "host": "https://adb-1234567890123456.7.azuredatabricks.net",
  "authSourceId": "databricks-oauth",
  "catalog": "main",
  "schema": "analytics",
  "warehouseId": "0123456789abcdef",
  "profile": "DEFAULT",
  "resources": {
    "servingEndpoint": "databricks-gpt-oss-120b",
    "vectorIndex": "main.analytics.product_docs"
  }
}

Every project session receives this binding as structured context. Installed Databricks skills are attached according to the binding: SQL and Unity Catalog, Genie, Vector Search RAG, Lakeflow, Asset Bundle authoring, and cost optimization. A required source is enabled only when that source exists, is authenticated, and is usable.

Browse the workspace

Open the project's Workspace view to inspect:

• Unity Catalog catalogs, schemas, and tables;
• SQL Warehouses and Model Serving endpoints;
• Databricks Apps and Jobs;
• Genie spaces and Vector Search indexes;
• Lakeflow pipelines.

Catalog nodes load schemas and tables lazily. Selecting a table inserts its fully qualified catalog.schema.table name into the latest session for that project. Other resources insert their stable name or identifier. Resource groups load independently so a permission failure is isolated to the affected group.

Run, build, and deploy

Open Deploy on the project:

1. Mock run exercises the selected job without workspace side effects.
2. Live run shows a confirmation containing the workspace host and bundle target. The approval authorizes that operation only.
3. Build creates the Harness deployment artifact.
4. Preview validates the deployment plan without deploying the App.
5. Deploy requires target-and-host confirmation and streams redacted output.
6. Cancel terminates the active Harness subprocess.
7. Open app uses the URL captured in deployment history.

Desktop serializes operations per project, parses databricks.yml structurally, temporarily selects the requested Asset Bundle target, and restores the source file even when the command fails or is cancelled. Deployment history is stored with the project. The bridge validates the installed fh version and capability contract before invoking it.

The terminal remains intentionally fail-closed. A non-interactive live run still requires the CI or operator to set the live gate explicitly:

export FABRIC_DATABRICKS_TEST=1
fh run analyst --payload '{"question":"Summarize main.analytics.orders"}'

An interactive Desktop confirmation does not set this global environment variable and does not change subsequent terminal commands.

AI Gateway attribution and guardrails

Project settings accept cost attribution tags:

team=analytics, cost_center=finance, environment=prod

They also accept an AI Gateway guardrail JSON object:

{
  "input": { "pii": true, "safety": true },
  "output": { "safety": true, "toxicity": true }
}

For a Databricks Mosaic AI session, Desktop passes these values only to that project's isolated model subprocess. The provider adds X-Cost-Attribution-Tags and X-Guardrail-Config to AI Gateway requests. The project context indicator shows when attribution and guardrails are active.

Desktop, CLI, and server mode

Recipe lookup uses the shared bundled-assets resolver, so the same gallery and scaffolding work in the Electron application and headless Desktop server. The generated Databricks developer resource bundle contains the versioned skill pack and can be imported into another Desktop workspace without copying credentials.

For the authentication boundaries and naming rules, continue with Local naming and authentication. For the release protocol, see the CLI compatibility contract.