What it does

The Status tab under Settings > System is the single place that shows what ran, what it depends on, and what state it ended in. For anything beyond that — retention of run history, alerting, correlating a failure with who changed what — you forward logs out to Azure Monitor from the Diagnostics tab.

Key facts

• Settings > System has an About tab (environment display name, ID, region, type, session ID), a General tab (language and regional formatting), a Status tab and a Diagnostics tab.
• Status lists every task with the outcome of its most recent run and when it last updated. Selecting the task name shows the last several runs; selecting the status opens a Progress details pane, and Entire workflow shows progress across all tasks at once.
• The documented statuses are Successful, Processing, Refreshing, Queued, Skipped, Canceled, Failure and Failed (permanent). The last one means it timed out or exhausted its retries and needs a human.
• Queued means upstream work has not finished. Skipped means something upstream failed or was itself skipped. Both are symptoms, not causes.
• Not started appears where nothing has been ingested yet or the task is still in draft — it is common on a half-built environment and is not a failure.
• A run showing Refreshing can be cancelled from the status pane with Cancel job, which returns the environment to the last refreshed state.
• Diagnostics forwards two log categories to Azure Monitor: Audit (APIEvent for configuration changes made through the UI — POST, PUT, DELETE, PATCH) and Operational (WorkflowEvent for ingestion, unification, enrichment and export, plus APIEvent for all calls including GET).
• Destinations are Azure Storage, Log Analytics or Event Hubs. The service creates the targets itself: containers insight-logs-audit and insight-logs-operational, event hubs of the same names, or Log Analytics tables CIEventsAudit and CIEventsOperational.
• Setting Diagnostics up needs an Azure subscription, Contributor plus User Access Administrator on the destination resource, Reader on the resource group, and rights to Microsoft.Insights/register/action on the subscription. Logs start appearing roughly 15 minutes after events occur.
• WorkflowEvent carries the fields that make failure triage tractable: operationType, workflowJobId, workflowType (full or incremental) and workflowSubmissionKind (OnDemand or Scheduled).

When to use / skip

Everyone uses the Status tab; it is not optional and it is where 90% of triage happens. Diagnostics is a different question. It is worth doing when the client already runs Azure Monitor or Sentinel and expects this workload to appear alongside everything else, when there is an audit obligation to show who changed a configuration, or when the environment is large enough that "was this run scheduled or did someone press the button" is a real question.

Skip it on a small deployment with one admin and a weekly refresh. The setup needs Azure roles that a Customer Insights admin often does not hold, it costs money in the destination resource, and nobody will build the queries. Deferring it is fine as long as you say so rather than leaving it silently unconfigured.

Configuration decisions

• Whether to forward logs at all, and if so to Storage, Log Analytics or Event Hubs — Log Analytics if anyone will actually query it, Storage if this is purely a retention obligation.
• Which subscription and resource group the destination sits in, and who holds the Azure roles needed to wire it up.
• Whether both categories are forwarded or only Audit, given Operational includes every GET and is much chattier.
• Retention on the destination, which is an Azure-side decision the Customer Insights admin does not control.
• Who receives alerts, and on what — permanent failures are the sensible first alert, skipped tasks are noise.
• Whether the environment's session ID and environment ID from the About tab are captured somewhere findable for support cases.

Gotchas

• Chasing the wrong task is the standard mistake. A failed export is usually a failed data source three steps upstream, and the export is only Skipped.
• The Status tab keeps a limited run history. If you need to answer questions about last month, Diagnostics had to be on last month.
• Removing a diagnostics destination stops the forwarding but leaves the Azure resource and its data in place, still costing money.
• The Azure permissions for Diagnostics are the blocker in practice — Contributor and User Access Administrator on the destination is more than most Customer Insights admins have, so plan a joint session with whoever owns the subscription.
• Cancelling a refresh reverts to the previous state, so a cancel taken to "stop the bad data" also discards the good part of the run.
• Configuration changes made through the API are captured as APIEvent, but a change made outside the product — in Dataverse, or in the source system — does not show up here at all.

Consultant notes

• Teach the client to read the dependency chain before teaching them anything else on this page. It converts most support tickets into self-service.
• Get the environment ID and region from the About tab into the client's runbook now, because the first support case is the worst time to go looking.
• If Diagnostics is in scope, book the Azure permissions conversation separately and early. It is not a five-minute task at the end of a sprint.
• Demo a deliberate failure in the sandbox — point a source at bad credentials — so the client sees Failed, Skipped and Queued together and remembers what they look like.
• Before go-live, agree what counts as an incident: permanent failure, yes; a single Failure with retries pending, probably not.

---

Worth revisiting if run history retention on the Status tab changes, or if native alerting arrives and removes the need for Azure Monitor.