Part 1 covered system.lakeflow_pipeline_events_preview.pipeline_events, the recently announced beta table, and the traps to watch for when querying it.

This part is about what to build once you trust the data.

I started with a straightforward question: which pipelines are producing the most errors? That led to repeated failures across flows, a dev pipeline spending money while failing, and pipelines that had stopped running without raising an error.

That last one is easy to miss. If nothing runs, nothing fails. Your error dashboard can look perfectly calm.

One reminder before the SQL: apply the unique-event-ID filtering from Part 1 before trusting these counts. The beta deduplication caveat applies throughout this post.

Start with the fleet error leaderboard

Finding the noisiest pipelines used to mean opening individual logs and piecing the results together. Now there is a single place to start:

SELECT
    pipeline_id,
    origin.pipeline_name AS pipeline_name,
    COUNT(*) AS error_count,
    MIN(event_time) AS first_occurrence,
    MAX(event_time) AS last_occurrence
FROM system.lakeflow_pipeline_events_preview.pipeline_events
WHERE level = 'ERROR'
  AND event_time >= current_timestamp() - INTERVAL 7 DAYS
GROUP BY pipeline_id, origin.pipeline_name
ORDER BY error_count DESC, last_occurrence DESC
LIMIT 20;

A few rows from my workspace:

pipeline_id  pipeline_name      error_count  first_occurrence      last_occurrence
pipeline_a   [dev] pipeline-a   255          2026-09-09 00:16:02   2026-09-15 16:20:11
pipeline_b   [prod] pipeline-b  96           2026-09-09 00:13:09   2026-09-14 14:25:41
pipeline_c   [dev] pipeline-c   50           2026-09-10 15:39:43   2026-09-14 05:20:15

Some ERROR rows have no populated origin.pipeline_name. That currently looks like a platform bug, although I have not confirmed the cause. If you see it, a specific event ID and pipeline ID would make a useful report to Databricks.

The missing name does not stop you from identifying the pipeline. You still have pipeline_id.

Then look at what keeps failing

The leaderboard tells you where to look. Grouping by message tells you what keeps happening.

SELECT
    message,
    COUNT(*) AS error_count,
    COUNT(
        DISTINCT COALESCE(
            origin.flow_id,
            NULLIF(regexp_extract(message, "'([^']+)'", 1), '')
        )
    ) AS distinct_flows_affected
FROM system.lakeflow_pipeline_events_preview.pipeline_events
WHERE level = 'ERROR'
  AND event_time >= current_timestamp() - INTERVAL 7 DAYS
GROUP BY message
ORDER BY error_count DESC
LIMIT 20;

For example:

message                                           error_count  distinct_flows_affected
Failed to resolve flow: 'prod.pipeline_b.flow_1'.  48           1
Flow 'dev.pipeline_a.flow_1' has FAILED.            45           1
Flow 'dev.pipeline_a.flow_2' has FAILED.            45           1

origin.flow_id is frequently null on ERROR rows. This query falls back to the quoted name in message.

There is also a flow-identity detail worth keeping in mind throughout this table: within one pipeline, retain (flow_id, flow_name) together. A full refresh can change flow_id. When comparing flows across pipelines, include pipeline_id as well.

In my results, four flows in the same pipeline each had exactly 45 errors.

That was worth a closer look.

Keep update-level history in the timeline table

Before going further, there is no reason to rebuild everything from event logs.

system.lakeflow.pipeline_update_timeline already gives you update-level pass/fail history. The event table is useful when you need to look inside an update.

This query gives a starting point for that investigation:

SELECT
    update_id,
    MIN(event_time) AS update_start,
    MAX(event_time) AS update_end,
    SUM(CASE WHEN level = 'ERROR' THEN 1 ELSE 0 END) AS error_count
FROM system.lakeflow_pipeline_events_preview.pipeline_events
WHERE event_time >= current_timestamp() - INTERVAL 7 DAYS
GROUP BY update_id
ORDER BY update_start DESC
LIMIT 20;

Use the timeline table for “Did the update succeed?”

Use the event table for “Which flow had a problem, and what kind of error was it?”

Put throughput and compute next to each other

Flow metrics arrive at two levels. Output rows are on INFO events; executor time is on METRICS events.

You can bring both into the same query:

SELECT
    origin.flow_id AS flow_id,
    origin.flow_name AS flow_name,
    SUM(
        CASE WHEN level = 'INFO'
            THEN details:flow_progress:metrics:num_output_rows::BIGINT
        END
    ) AS output_rows,
    SUM(
        CASE WHEN level = 'METRICS'
            THEN details:flow_progress:metrics:executor_time_ms::BIGINT
        END
    ) AS executor_time_ms,
    COUNT(*) AS events
FROM system.lakeflow_pipeline_events_preview.pipeline_events
WHERE event_type = 'flow_progress'
  AND level IN ('INFO', 'METRICS')
  AND event_time >= current_timestamp() - INTERVAL 7 DAYS
GROUP BY origin.flow_id, origin.flow_name
ORDER BY executor_time_ms DESC
LIMIT 20;

In my workspace, a dev bronze feed topped executor time, ahead of every production flow.

That is the sort of result I would probably have missed while checking pipelines one at a time.

Watch for pipelines.flowTimeMetrics.missingFlowName, though. It is a placeholder the platform emits when a METRICS row has no flow name attached. Filter it out or label it clearly. Otherwise, your “biggest flow” might be a bucket of unattributed metrics.

The four flows with 45 errors

Messages are useful for reading an incident, but they make awkward alert keys. Table names and versions can change the text even when the underlying error is the same.

error.exceptions[].error_class gives you a more consistent way to group failures:

SELECT
    error.fatal AS fatal,
    exc.error_class,
    exc.sql_state,
    COUNT(*) AS error_count
FROM system.lakeflow_pipeline_events_preview.pipeline_events
LATERAL VIEW OUTER EXPLODE(error.exceptions) e AS exc
WHERE level = 'ERROR'
  AND event_time >= current_timestamp() - INTERVAL 7 DAYS
GROUP BY error.fatal, exc.error_class, exc.sql_state
ORDER BY error_count DESC;

Back to those four flows.

They shared the same error class across the same 15 updates. Within a single update, all four failed within about 70 seconds of one another.

The 45 events per flow worked out to an average of three error events per update. Those events included repeated failures and summary rows, so 45 error events should not be read as 45 separate attempts.

The useful finding was the shared pattern: one pipeline, one error class, 15 updates, and four flows failing together.

That gave me a reason to investigate one common cause instead of treating the flows as four unrelated incidents. I did not need to open the pipeline UI to see it.

For deeper investigation, Genie’s code-oriented skills — including the system-tables-specific skill — can help work through this kind of query chain without writing every join by hand.

Look for retries, even without a retry field

There is no dedicated retry field here. Repeated failure events within the same update and flow give you somewhere to start:

SELECT
    pipeline_id,
    origin.pipeline_name AS pipeline_name,
    update_id,
    origin.flow_id AS flow_id,
    origin.flow_name AS flow_name,
    COUNT(*) AS failure_events,
    MIN(event_time) AS first_failure,
    MAX(event_time) AS last_failure
FROM system.lakeflow_pipeline_events_preview.pipeline_events
WHERE level = 'ERROR'
  AND event_time >= current_timestamp() - INTERVAL 7 DAYS
GROUP BY
    pipeline_id,
    origin.pipeline_name,
    update_id,
    origin.flow_id,
    origin.flow_name
HAVING COUNT(*) > 1
ORDER BY failure_events DESC;

Treat this as a list of candidates to inspect. Repeated errors can include summary events; the count alone is not an exact retry count.

A pipeline that succeeds only on its third attempt every night still deserves attention. An update-level pass/fail summary can hide that pattern. The events inside the update give you a chance to see it.

Catalog and schema chargeback hits a gap

I also tried grouping events by catalog and schema:

SELECT
    origin.catalog_name,
    origin.schema_name,
    COUNT(*) AS event_count,
    SUM(CASE WHEN level = 'ERROR' THEN 1 ELSE 0 END) AS error_count
FROM system.lakeflow_pipeline_events_preview.pipeline_events
WHERE event_time >= current_timestamp() - INTERVAL 7 DAYS
GROUP BY origin.catalog_name, origin.schema_name
ORDER BY event_count DESC;

The result was mostly empty.

Of roughly 652,000 rows, 644,171 had no catalog or schema, including every ERROR row. origin.catalog_name and origin.schema_name populate only for specific dataset-scoped event types.

There is no clean fallback in the other tables used here. Neither system.lakeflow.pipelines nor pipeline_update_timeline carries a target catalog/schema.

For chargeback by domain, you currently need your own pipeline metadata, joined on pipeline_id.

Join cost to reliability

This was the query I most wanted to run.

Billing can tell you what a pipeline costs. Event logs can tell you how often it fails. Joining them lets you see both at once.

WITH prices AS (
    SELECT
        sku_name,
        usage_unit,
        price_start_time,
        COALESCE(
            price_end_time,
            DATE_ADD(CURRENT_DATE(), 1)
        ) AS price_end_time,
        try_variant_get(
            to_variant_object(pricing),
            '$.effective_list.default',
            'decimal(38,18)'
        ) AS unit_px
    FROM system.billing.list_prices
    WHERE currency_code = 'USD'
      AND cloud = 'AZURE'
),
pipeline_cost AS (
    SELECT
        p.pipeline_id,
        p.name AS pipeline_name,
        SUM(
            COALESCE(pr.unit_px * u.usage_quantity, 0)
        ) AS total_cost
    FROM system.billing.usage u
    LEFT JOIN prices pr
        ON u.sku_name = pr.sku_name
       AND u.usage_unit = pr.usage_unit
       AND u.usage_end_time >= pr.price_start_time
       AND u.usage_end_time < pr.price_end_time
    LEFT JOIN (
        SELECT
            pipeline_id,
            name,
            workspace_id
        FROM system.lakeflow.pipelines
        QUALIFY ROW_NUMBER() OVER (
            PARTITION BY pipeline_id
            ORDER BY change_time DESC
        ) = 1
    ) p
        ON u.usage_metadata.dlt_pipeline_id = p.pipeline_id
       AND u.workspace_id = p.workspace_id
    WHERE u.billing_origin_product = 'DLT'
      AND u.record_type = 'ORIGINAL'
      AND u.usage_date >= current_date() - INTERVAL 7 DAYS
    GROUP BY p.pipeline_id, p.name
)
SELECT
    c.pipeline_name,
    ROUND(c.total_cost, 2) AS total_cost,
    SUM(CASE WHEN e.level = 'ERROR' THEN 1 ELSE 0 END) AS error_events
FROM pipeline_cost c
JOIN system.lakeflow_pipeline_events_preview.pipeline_events e
    ON e.pipeline_id = c.pipeline_id
WHERE e.event_time >= current_timestamp() - INTERVAL 7 DAYS
GROUP BY c.pipeline_name, c.total_cost
ORDER BY c.total_cost DESC
LIMIT 5;

My top five looked like this:

pipeline_name      total_cost  error_events
[prod] pipeline-d  332.33      0
[prod] pipeline-e  303.11      0
[prod] pipeline-f  157.03      0
[prod] pipeline-g  144.00      0
[dev] pipeline-h   98.64       50

The four most expensive pipelines had zero errors.

The fifth was a dev pipeline with $98.64 in list-price compute and 50 error events in a week.

The cost was already in billing. The failures were already in the logs. Putting them together made that dev pipeline much harder to overlook.

Read the state changes inside flow_progress

An error count tells you how much noise a flow produced. Ordering its flow_progress events tells you more about how the run unfolded.

For each update and flow, take the current status and the next status, then count the pairs.

There is an important correction in the query below. My original version partitioned on flow_id alone. Some pipeline types have null flow_id values, which merged unrelated flows into one window and created transitions that never happened.

This version falls back to flow_name. It also excludes pipeline-level events and the missingFlowName placeholder.

WITH s AS (
    SELECT
        update_id,
        COALESCE(origin.flow_id, origin.flow_name) AS flow_key,
        event_time,
        details:flow_progress:status::STRING AS status
    FROM system.lakeflow_pipeline_events_preview.pipeline_events
    WHERE event_type = 'flow_progress'
      AND event_time >= current_timestamp() - INTERVAL 7 DAYS
      AND details:flow_progress:status IS NOT NULL
      AND origin.flow_name IS NOT NULL
      AND origin.flow_name != 'pipelines.flowTimeMetrics.missingFlowName'
),
t AS (
    SELECT
        update_id,
        flow_key,
        status AS from_status,
        LEAD(status) OVER (
            PARTITION BY update_id, flow_key
            ORDER BY event_time
        ) AS to_status
    FROM s
)
SELECT
    from_status,
    to_status,
    COUNT(*) AS transitions
FROM t
WHERE to_status IS NOT NULL
GROUP BY from_status, to_status
ORDER BY transitions DESC;

The exact transition counts are still under re-verification. The original write-up reported 26 distinct edges and specific failure-path counts using the earlier query. Those figures should not be treated as final.

The patterns below are useful directions for investigation, but the corrected query needs to confirm their frequency.

Repeated status is mostly noise

Pairs such as QUEUED → QUEUED and RUNNING → RUNNING mean the flow is announcing the same state again.

Raw event counts therefore reflect repeated reporting and time spent in a state, rather than throughput. To count actual state changes, keep only rows where:

from_status <> to_status

Where a flow fails changes the investigation

In the original results, failures from STARTING substantially outnumbered failures from RUNNING.

That points toward resolution, dependency, or permission problems before execution begins. It is a useful lead, although the exact ratio — and the cause of each failure — still needs confirmation.

A failure followed by activity can reveal a retry

Transitions such as FAILED → STARTING or FAILED → RUNNING make retry behavior visible without a dedicated retry field.

That is a stronger signal to inspect than a raw count of error rows.

Unfamiliar transitions are worth reviewing

Keep a baseline of the transitions your fleet normally produces.

An unseen edge, or one below a low count threshold, gives you a small set of events to review. Something like RUNNING → STOPPED or SKIPPED → PLANNING could reflect unusual behavior or a platform change.

It does not have to mean an incident. It does mean something changed.

What if the pipeline stops showing up?

Everything so far assumes the pipeline ran.

The failure I am more concerned about is the one that produces nothing: no update, no flow event, and no error for an alert to match.

You can look for that by measuring each pipeline’s normal gap between updates, then comparing it with the time since its last update.

WITH e AS (
    SELECT
        pipeline_id,
        event_time,
        LAG(event_time) OVER (
            PARTITION BY pipeline_id
            ORDER BY event_time
        ) AS prev_time
    FROM system.lakeflow_pipeline_events_preview.pipeline_events
    WHERE event_type = 'create_update'
      AND event_time >= current_timestamp() - INTERVAL 7 DAYS
),
gaps AS (
    SELECT
        pipeline_id,
        (
            unix_timestamp(event_time)
            - unix_timestamp(prev_time)
        ) / 3600.0 AS gap_hours
    FROM e
    WHERE prev_time IS NOT NULL
),
cadence AS (
    SELECT
        pipeline_id,
        COUNT(*) + 1 AS update_count,
        percentile_approx(gap_hours, 0.5) AS median_gap_hours
    FROM gaps
    GROUP BY pipeline_id
),
latest AS (
    SELECT
        pipeline_id,
        (
            unix_timestamp(current_timestamp())
            - unix_timestamp(MAX(event_time))
        ) / 3600.0 AS hours_since
    FROM e
    GROUP BY pipeline_id
)
SELECT
    c.pipeline_id,
    c.update_count,
    c.median_gap_hours,
    l.hours_since
FROM cadence c
JOIN latest l
    ON c.pipeline_id = l.pipeline_id
ORDER BY l.hours_since DESC;

In my workspace, 123 pipelines had enough updates within seven days to derive a cadence.

Across the top results, the median gap was 6.0 hours, almost to the second. Yet the pipelines at the top had gone 157 hours since their last update — roughly 26 times their usual gap.

There was no error to alert on.

Nothing had failed because nothing had run.

That is the value of measuring cadence. Each pipeline gives you a starting point for its own normal behavior. You can alert when the time since its last update exceeds a chosen multiple of that gap.

Do not alert on every registered pipeline

I also tried listing registered pipelines in system.lakeflow.pipelines that had no events.

That returned:

• 601 registered pipelines.
• 75 active pipelines.
• 526 apparently “silent” pipelines.

Taken at face value, that would have made a terrible alert.

The table includes pipeline history and entries across workspaces. Before using it to detect silence, filter to your workspace_id and to pipelines your team considers active.

Otherwise, you will flag pipelines that were never part of your operating fleet.

What I would build first

After working through these queries, I would start with three things:

1. Alert when an active pipeline is overdue. Use its median update gap as the baseline, then choose a multiple that fits its schedule.
2. Review new state transitions. Keep a baseline of known edges and flag unfamiliar ones for investigation.
3. Group incidents by update_id. Start with unique event IDs, then use update-level grouping to avoid treating every error row as a separate incident.

The overdue alert would come first for me.

I can investigate an error once I know it happened. A pipeline that quietly stops running is easier to miss — and an empty error dashboard does very little to help.

Lakeflow pipeline events just landed in system.* as a beta. What it fixes, how to turn it on, and a few ways it’ll quietly give you wrong answers if you’re not careful.

If you’ve spent any time digging around a Databricks account, system tables have probably changed how you work. Billing lives in system.billing.usage. Lineage lives in system.access.table_lineage. Every query anyone runs ends up in system.query.history. Jobs have system.lakeflow.jobs and job_run_timeline.

Pipelines were the one thing missing. Not anymore.

What was broken

Every Lakeflow Declarative Pipeline keeps its own event log. You could get at it with the event_log table-valued function or by going to its storage location, but only one pipeline at a time. That's fine for debugging one pipeline and useless for a fleet. If you wanted to know which pipelines failed the most this month, you were building (and babysitting) your own job to union them all together.

There were also gaps you just couldn’t fix from the outside. If a cluster never came up, the startup events were gone, and those are usually the failures you care about most. Delete a pipeline and its history went with it. And since cost was in system.* but reliability wasn't, you couldn't join the two.

One thing I want to call out: if all you need is update-level pass/fail trends, system.lakeflow.pipeline_update_timeline already does that and it's simpler. The new table is about depth. It goes down to individual flows inside an update and has micro-batch metrics the update table never had. Use it when your question is "which flow broke and why," not "did the update succeed."

What the new table gives you

The table is system.lakeflow_pipeline_events_preview.pipeline_events. Per the docs, it:

• Captures every pipeline’s event log in one place, even when the cluster doesn’t start.
• Covers all pipelines and updates you have access to.
• Keeps data after a pipeline is deleted, for 13 months by default (configurable).

What the docs say vs. what I actually checked

Central capture, no per-pipeline setup. Confirmed. 652,368 events across 125 pipelines after seven days, and I didn’t touch a single pipeline.

Cross-workspace coverage. Couldn’t test it. We only have one workspace_id. The schema has account_id and workspace_id though, so the join key is there if you have several.

13 months of retention. Can’t see that yet. The table only fills forward from when you turn it on, and my oldest event is 2026–09–08.

Survives pipeline deletion. Haven’t tested. I didn’t want to delete a pipeline just to find out.

The retention one matters most in practice. History starts the day you enable it, so every week you put it off is a week you won’t get back.

Turning it on

It’s an account-level preview, so you need an account admin:

1. Go to Account settings from any workspace.
2. Click Previews.
3. Search for Lakeflow Pipeline Events System Table and turn it on.

Your pipelines don’t change at all. Events just start showing up from then on.

Heads up: the beta doesn’t fully dedupe events yet. Filter down to unique event IDs before you trust any count.

What’s in it

• Identity: account_id, workspace_id, pipeline_id, update_id, pipeline_event_id
• What happened: event_type, level (INFO, WARN, ERROR, METRICS), message, event_time
• Where it happened: an origin struct with pipeline name, flow name, dataset name, cluster ID, catalog and schema
• Payload: an error struct, plus a details column (VARIANT) whose shape changes with event_type
• Something new: maturity_level (STABLE, EVOLVING, DEPRECATED), basically a per-event promise about how stable the schema is

About half the rows are flow_progress (335,593 in everything I had so far). After that it's flow_definition, dataset_definition, dataset_life_cycle, stream_progress, update_progress, and then a long tail. Errors barely show up by volume, just 419 rows at level = 'ERROR' out of 650K+. That's exactly why having them in something you can GROUP BY is such a big deal.

About flow_id: it’s null for some pipeline types (database table sync pipelines, for one). Inside a single pipeline, identify a flow by (flow_id, flow_name) together. A full refresh can change the flow_id, so flow_name is the thing that sticks. Across pipelines, add pipeline_id too, because flow names get reused.

Two things before you build anything on it:

• The schema name is going to change. It’s lakeflow_pipeline_events_preview in beta and becomes system.lakeflow.pipeline_events at GA. Put a view in front of it now, point everything at the view, and just update the view on GA day.
• Read the docs, not just the announcement. It’s beta, and EVOLVING events can change shape on you.

Querying it without fooling yourself

Everything below ran against a live Azure workspace on 2026–09–15: 125 pipelines, seven days, about 652K rows.

Gotcha #1: details is VARIANT, so a bad path gives you NULL instead of an error.

For flow_progress, the INFO rows have status and, once a flow completes, metrics.num_output_rows / num_upserted_rows / num_deleted_rows. The METRICS rows have executor_time_ms / executor_cpu_time_ms. Those live on different rows, so if you want both in one query you have to handle both levels.

SELECT COUNT(*) AS flow_progress_rows,

COUNT(details:flow_progress:metrics:num_output_rows::BIGINT)  AS num_output_rows_nonnull,

COUNT(details:flow_progress:metrics:num_output_bytes::BIGINT) AS num_output_bytes_nonnull

FROM system.lakeflow_pipeline_events_preview.pipeline_events

WHERE event_type = 'flow_progress'

AND event_time >= current_timestamp() - INTERVAL 7 DAYS

Result:

flow_progress_rows  num_output_rows_nonnull  num_output_bytes_nonnull

335,561             27,766                   0

num_output_rows was filled in on 27,766 rows. I spot-checked three against the Pipeline UI (206,965,340 / 13,222,758 / 1,698,774, which the UI shows as 207M / 13M / 1.7M) and they matched. num_output_bytes was null on every single row in our workspace. Don't take that as a rule though. Which metrics get populated depends on your pipeline type, so check it against your own stuff.

A typo in a VARIANT path also just returns NULL. Same symptom, no warning either way.

So my rule: before anything unattended depends on a VARIANT path, run COUNT(path) against rows you know should have a value.

Gotcha #2: the status values aren’t what you’d expect.

SELECT DISTINCT details:flow_progress:status::STRING AS status

FROM system.lakeflow_pipeline_events_preview.pipeline_events

WHERE event_type = 'flow_progress'

I got ten: blank, COMPLETED, EXCLUDED, FAILED, PLANNING, QUEUED, RUNNING, SKIPPED, STARTING, STOPPED. If you treat "not COMPLETED or FAILED" as "still running," you'll get STOPPED, SKIPPED and EXCLUDED wrong.

Gotcha #3: join on pipeline_id, never on the name.

Pipeline names get reused and renamed mid-month. Join on origin.pipeline_name and you'll double count in one place and drop rows in another, and nothing will error. Use pipeline_id (plus workspace_id once you have more than one workspace) and only pull the name in at the very end for display.

Coming up in Part 2

What to actually build on top of this: fleet-wide error triage, spotting retries, joining cost with reliability, and the state machine hiding inside flow_progress, including an alert that doesn't need a threshold at all.

One small feature in Databricks Genie that makes a real difference for adoption: the Genie One homepage is fully customizable, and it only takes one click to get there. If you're rolling Genie out to a team that's never touched a natural-language analytics tool before, this five-minute setup step is worth doing before you send out the link.

Here's how it works.

# Step 1: Open the homepage settings

From the Genie One homepage, hit Edit next to the homepage settings panel.

Genie One homepage with Edit button

That's the only entry point you need — everything else happens on the page it opens.

# Step 2: Customize brand, logo, and welcome text

Clicking Edit opens the customization page, where three things are editable in one place: brand color, logo, and a markdown welcome message.

Customization page with color picker, logo section, and markdown text area

The markdown block is the part that matters most, and it's easy to underinvest in. A blank chat box is intimidating — most people don't know what a natural-language analytics assistant can actually answer until they've seen a few good examples. A well-written welcome message closes that gap on day one.

The pattern I've landed on for that text:

• Show 2–3 example questions specific to the space — generic examples don't build confidence the way domain-specific ones do

• One question at a time — compound asks get muddled answers, and that's the single biggest cause of "this thing doesn't work" complaints

• Name your dimensions explicitly — "by branch," "by customer segment," "by region," rather than leaving grouping up to the model

• Give a time frame — "trailing 30 days," "this quarter," "FY2026 YTD"

• Filter explicitly — call out the segment, region, product, or category by name rather than assuming context

For a banking-industry space, that might look like:

• Loan approval rate by branch this quarter.

• Average account balance by customer segment.

• Flag transactions over $10,000 by region, trailing 30 days.

Small UX investment, real reduction in "I don't know what to ask it" friction.

# Step 3: Save and verify

Once you hit save, anyone on the team can confirm the change by checking the Admin wiki button in the top bar — it's a quick way to spot-check that your updates went live.

Top bar with Admin wiki button visible in the Genie one main Page.

# Two things I'd love to see next

1. A configurable Admin wiki link. Right now the label and destination are fixed to "Admin wiki." I'd like to point that button at whatever doc or resource actually makes sense for a given space, with whatever label fits.

2. A footer notes area on the main Genie One homepage. A dedicated spot for team-wide links and announcements would round out the customization story — right now there's no equivalent home for content that isn't specific to one space.

Both are small asks, but they'd close the gap between "this space is customizable" and "this whole homepage is customizable."

---

If you're rolling out Databricks Genie to your team, don't skip the homepage setup — it's a five-minute step that changes how confidently people use the tool on day one.

#Databricks #DatabricksGenie #DataEngineering #AnalyticsEngineering #GenAI