Data Extensions & Queries

Beyond watching automations run, Nimbus inventories the data they touch — every data extension and every SQL query — and uses that inventory to surface stale data and conflicting jobs.

Data Extensions #

The Data page lists every data extension (DE) in the Business Unit. For each DE, Nimbus tracks the name and key, row count, field count, when it was last written, and a staleness grade.

Staleness #

Staleness compares a DE's last write time to per-tenant thresholds:

Adjust the thresholds per Business Unit under Settings → Connection. Stale data extensions are a common cause of campaigns sending against out-of-date audiences — a de.stale or de.aging notification can alert you before that happens.

The DE detail view #

Click a DE to open its detail modal:

• Fields — every column with its type and order.
• Writers — the queries and imports that write to this DE.
• Readers — the automations and journeys that read from it.
• Conflicts — whether a write or read/write conflict was detected.

The writers/readers list makes impact analysis quick: before you change a DE, you can see everything upstream and downstream of it.

Queries #

The Queries page catalogs every SQL Query activity. Each query shows its run count, error count, fail rate, average duration, last run, and the target data extension it writes to.

Query detail and version history #

Open a query to see its full SQL, its run history, and its version history. Nimbus captures a new version whenever the query text changes in SFMC, and renders a line-level diff between versions — removed lines in red, added lines in green. This is invaluable when a query starts failing: you can see exactly what changed and when.

Conflicts #

A conflict happens when two jobs use the same data extension in overlapping time windows. Nimbus detects two kinds:

• Write conflict — two jobs writing the same DE at once. The later write can clobber the earlier one.
• Read/write conflict — one job reading a DE while another writes it. The reader can see half-updated data.

Conflict analysis runs over the last several days of activity. On the Queries page, each query lists the conflicting query, the shared DE, how many times their runs overlapped, and when they last overlapped. Resolving a conflict is usually a scheduling change — move one job to a quiet window from the Schedule page — or a dependency change so one job waits for the other.