> ## Documentation Index > Fetch the complete documentation index at: https://docs.nimbleway.com/llms.txt > Use this file to discover all available pages before exploring further. # Databricks > Connect a Job's input source and destination via Delta Sharing Select **Databricks** in the Inputs and/or Destination strip of the Job form. Both directions use Databricks-to-Databricks (D2D) Delta Sharing and require your workspace to be on **Databricks Unity Catalog**. Databricks Delta Sharing lets a [Job](/nimble-sdk/agentic/jobs) read its input set directly from your Unity Catalog and/or deliver its assembled output back into your Unity Catalog. Each direction is configured independently and uses opposite Delta Sharing roles: | Direction | Your role | Nimble's role | | ---------------------------------------- | --------- | ------------- | | **Input** - share your table with Nimble | Provider | Recipient | | **Destination** - mount Nimble's output | Recipient | Provider | ## Nimble's global metastore ID Both directions reference Nimble's Unity Catalog metastore. Wherever the property tables below mention it, use: ```text theme={"system"} aws:us-east-1:2f3ba1b1-429c-491f-b37d-ebb46f22f3e9 ``` This is a **global** metastore ID in the `::` form required by Databricks D2D sharing. The bare UUID is not enough. ## Prerequisites * Databricks CLI **v0.205+** authenticated against the workspace you want to share from / into. See the [Databricks CLI install guide](https://docs.databricks.com/aws/en/dev-tools/cli/install) and `databricks configure`. * A metastore admin or a user with the `CREATE RECIPIENT`, `CREATE SHARE`, and `CREATE CATALOG` privileges on your UC metastore. *** ## Input: share your table with Nimble In this direction, **you are the provider**: you publish a Delta Sharing share whose recipient is Nimble's metastore. On each Job run, the Job reads the current contents of the shared table. ### Job form fields Set these in the Job form under **Inputs → Databricks**: | Field | Description | | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Provider` | Delta Sharing provider name **as it appears in Nimble's metastore** - Databricks D2D derives this on Nimble's receiving side from your metastore identity. Your Nimble account contact can confirm the exact string if you're unsure. | | `Share` | Share name on your side (the value you pass to `databricks shares create --name <...>`). | | `Schema` | Schema (database) inside the share that holds the table you want Nimble to read. | | `Table` | Table name inside that schema. | ### One-time setup The recipient is the Databricks-side object that grants Nimble permission to receive your shares. ```bash theme={"system"} databricks recipients create --json '{ "name": "nimble", "authentication_type": "DATABRICKS", "data_recipient_global_metastore_id": "aws:us-east-1:2f3ba1b1-429c-491f-b37d-ebb46f22f3e9", "comment": "Nimble Delta Sharing recipient" }' ``` You only do this once - re-use the same recipient for every additional table you share with Nimble. Pick any name you like (e.g., `nimble_inbox`). The Job form's `Share` field will use this value. ```bash theme={"system"} databricks shares create \ --name nimble_inbox \ --comment "Tables shared with Nimble" ``` Replace `main.inbox.products` with the fully-qualified UC name of the source table (`..`). The `shared_as` value sets how the table appears on Nimble's side - it **must match** the `Schema` and `Table` values in the Job form. ```bash theme={"system"} databricks shares update nimble_inbox --json '{ "updates": [{ "action": "ADD", "data_object": { "name": "main.inbox.products", "data_object_type": "TABLE", "shared_as": "inbox.products" } }] }' ``` For partitioned tables or history sharing options, see the full [`SharedDataObject` reference](https://docs.databricks.com/api/workspace/shares/update). ```bash theme={"system"} databricks grants update share nimble_inbox --json '{ "changes": [{ "principal": "nimble", "add": ["SELECT"] }] }' ``` Once this grant lands, the share becomes visible on Nimble's metastore. No support ticket, no manual coordination - the next Job run picks up the share **automatically**. Every Job run reads the **latest** contents of the shared table; you do not need to re-publish the share unless you change the table name or schema. ### Adding more tables later Only **steps 3 and 4** need to repeat for each additional table. The recipient (step 1) and the share (step 2) are reused across tables - just `ADD` a new `data_object` and re-grant `SELECT` if you create a new share instead of extending the existing one. *** ## Destination: deliver Job output to your Unity Catalog In this direction, **Nimble is the provider** and **you are the recipient**. On the first Job run, Nimble makes the share available to your metastore (creating both the share and the recipient on demand, bound to your `Metastore ID`). You mount the share locally as a Unity Catalog catalog and query it like any other UC table. **Data retention: 14 days.** Nimble guarantees the shared table stays queryable for **at least two weeks** after each successful Job run, but **not longer**. Beyond that window, the shared table is not guaranteed to remain available. If you need the data to persist - or want a frozen snapshot of every run - materialize it into a UC table you own. See [Persisting the data](#persisting-the-data). ### Job form fields Set these in the Job form under **Destination → Databricks**: | Field | Description | | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Share name` | Share name **on Nimble's side** that the output table will be published to. Created on demand if it doesn't already exist. Pick any value - it's only visible to your account. | | `Recipient name` | Recipient name **on Nimble's side** that represents your workspace. Created on demand and bound to `Metastore ID`. Use one recipient per consuming metastore. | | `Metastore ID` | **Your** UC global metastore ID, in the form `::` (e.g. `aws:us-east-1:a9e65c72-c515-45bc-a600-3048a46bd6a8`). See "Finding your metastore ID" below. | | `Shared as` | `.
` alias for the shared table - the **only** name visible on your side. Pick a clean, stable value; renaming it later invalidates the catalog mount on your side. | ### Finding your metastore ID Run **one** of the following inside the Databricks workspace that will consume the share: ```sql SQL (any UC-enabled cluster or SQL warehouse) theme={"system"} SELECT current_metastore(); ``` ```bash CLI theme={"system"} databricks metastores summary | jq -r .global_metastore_id ``` The output is the value to enter in the `Metastore ID` field. The format is always `::` - the bare UUID returned by older Databricks endpoints is **not** accepted. ### One-time setup (after the first Job run) The share becomes available to your metastore after the Job's first successful run. After that first run completes, run the following on your Databricks workspace: Once Nimble has bound the recipient to your metastore, the share becomes visible in your UC metastore as a **provider**. List providers to find the exact name Databricks assigned it on your side: ```bash theme={"system"} databricks providers list --output json \ | jq '.providers[] | select(.authentication_type=="DATABRICKS") | {name, recipient_profile_str}' ``` You can also do this in the UI: **Catalog → Delta Sharing → Shared with me → Providers**. Replace `` with the name from the previous step. Confirm the share you configured in the Job form is listed and contains a table named after your `Shared as` value. ```bash theme={"system"} databricks providers list-shares ``` Pick any local catalog name (e.g., `nimble`). Once mounted, the Job's output table is queryable as `.`. ```sql SQL theme={"system"} CREATE CATALOG IF NOT EXISTS nimble USING SHARE ``.``; ``` ```bash CLI theme={"system"} databricks catalogs create --json '{ "name": "nimble", "provider_name": "", "share_name": "" }' ``` `` is the value entered in the Job form's `Share name` field. `` is the value from step 1. The mount itself only grants access to the metastore admin who created it. Open it up to consumers with UC grants: ```bash theme={"system"} databricks grants update catalog nimble --json '{ "changes": [{ "principal": "account users", "add": ["USE_CATALOG", "USE_SCHEMA", "SELECT"] }] }' ``` Replace `account users` with whichever UC group / service principal should have read access. The fully-qualified path is `.`. For `Shared as = data.products` and a catalog mounted as `nimble`: ```sql theme={"system"} SELECT * FROM nimble.data.products LIMIT 100; ``` ### Subsequent runs Once mounted, every subsequent Job run refreshes the shared table - the catalog mount itself is permanent. Each successful run also **resets the 14-day retention clock** on the shared table; if a Job stops running (or runs less frequently than every two weeks), the table will eventually age out of the share. Re-run the `CREATE CATALOG` step only if you delete the catalog, rename `Shared as` on the Job, or Nimble changes the share name (which won't happen except on your explicit request). Changing `Shared as` after the first run changes the **path** consumers query against (e.g., from `nimble.data.products` to `nimble.curated.products`). Plan downstream queries and views accordingly - and prefer keeping `Shared as` stable. ### Persisting the data The shared table is only guaranteed to be queryable for **14 days** after each Job run. To hold the data longer - or to keep a frozen per-run snapshot for audit / historical analysis - materialize it into a UC table you own. Two common patterns: ```sql Overwrite (latest snapshot) theme={"system"} CREATE OR REPLACE TABLE my_catalog.my_schema.products AS SELECT * FROM nimble.data.products; ``` ```sql Append (run history) theme={"system"} INSERT INTO my_catalog.my_schema.products_history SELECT *, current_timestamp() AS snapshot_at FROM nimble.data.products; ``` Wire this as a Databricks Job, a [Lakeflow Declarative Pipeline](https://docs.databricks.com/aws/en/delta-live-tables), or any other UC-aware orchestrator, scheduled to run shortly after Nimble's Job cadence. Once materialized, the data is fully under your control and survives Nimble's retention window. Schedule the materialization a few minutes **after** Nimble's Job is expected to finish, not at the same time. If you run too early you'll snapshot the previous run; if you run too late you stay within the 14-day window with plenty of buffer either way. ### Reference summary | What | Value | | -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | | Nimble's global metastore ID (used when **you** create a recipient pointing to Nimble) | `aws:us-east-1:2f3ba1b1-429c-491f-b37d-ebb46f22f3e9` | | Input direction - your role | Provider (you run `databricks recipients create` + `shares create` + `shares update` + `grants update share`) | | Destination direction - your role | Recipient (you run `databricks providers list` + `catalogs create` + `grants update catalog`) | | Where to find your global metastore ID | `SELECT current_metastore()` or `databricks metastores summary` | | Destination data retention | **14 days** from each successful Job run. Materialize into a UC table you own to retain longer. | ## Related Browse every Job storage connector. Connect a Job via an S3 bucket policy instead.