In Tableau Server, when would you use a data-driven alert instead of a subscription?

## Two delivery mechanisms with different triggers Tableau Server and Tableau Cloud both offer two push mechanisms from a published view. A **subscription** is time-triggered. A user subscribes themselves (or, with the right capability, subscribes others) to a view or a whole workbook, and on the chosen schedule the server renders the view and emails it as an image or PDF with a link back to the live view. It sends on the schedule regardless of whether anything moved, with an option not to send when the view is empty — which is the poor cousin of a real condition. A **data-driven alert** is condition-triggered. It is created from a view that has a **continuous numeric axis**, because the alert needs an axis value to compare against. You define a threshold and a comparison — above, below, equal to — nominate recipients, and Tableau evaluates the condition when the underlying extract refreshes or on the alert's own cadence. Mail goes out only when the condition holds. ## Choosing between them The honest test is: *do you want to hear from this every time, or only when something is wrong?* Subscriptions fit a **rhythm**. The weekly business review pack, the daily sales digest, the month-end summary. People expect them, and their absence is itself a signal. Alerts fit **exceptions**. Stock cover below two weeks, refund rate above a ceiling, a pipeline SLA breached. Sending a daily "everything is fine" email trains people to filter the sender, at which point the one email that mattered goes to the same folder. If you find yourself subscribing people to a dashboard so they can check whether a number went red, you wanted an alert. A practical constraint: because an alert needs a continuous numeric axis, you sometimes have to build a small purpose-made view for it — a single-mark view of the metric you actually want to watch — rather than attaching the alert to a dense dashboard. That is not a workaround; a dedicated monitoring view is usually clearer anyway. ## The thing candidates miss: per-recipient rendering Both mechanisms render **for each recipient individually**, using that recipient's own identity and access. Two consequences follow. First, **permissions apply**. A recipient who lacks permission on the view does not receive a back-door copy of it. Adding someone to a subscription does not grant them access. Second, and more subtly, **data filtering applies**. If the data source uses user-level filtering — a calculation on `USERNAME()` or `ISMEMBEROF()`, or a user filter defined on the data source — each recipient's render is filtered to their own slice. The regional manager for the north and the one for the south receive the same subscription with different totals. That is usually the desired behaviour and it is exactly why you should never assume a subscription email is a shared artefact: quoting "the number in this morning's email" in a meeting can mean four different numbers around the table. It also means rendering cost scales with recipients rather than with subscriptions, which matters when a list grows to hundreds. ## Operational realities **Alerts can be suspended.** If an alert repeatedly fails to evaluate — the view changed shape, the field it watched was removed, the data source broke — the platform stops retrying it and notifies the owner. An alert you assume is armed may have been quietly suspended weeks ago, so treat critical alerts as something to review, not something to set and forget. **Freshness bounds everything.** An alert can only fire as fast as the data updates. On an extract refreshed nightly, a "real-time" alert is a next-morning alert. If a condition needs to be caught in minutes, it belongs in the pipeline or a monitoring system, not in a BI tool's email layer. **Volume management.** Subscriptions expand silently as teams grow; alerts multiply as everyone adds their own threshold. Both deserve periodic review, and both should be owned by a team rather than by whichever analyst set them up before leaving. **Delivery is email.** Neither mechanism is an escalation path with acknowledgement, retries or on-call routing. If somebody must act within an hour, wire the condition into the alerting system that already pages people, and keep Tableau for the human-facing view of it. ## A short answer that lands well "Subscription for a rhythm, alert for a threshold. Both render per recipient with that person's permissions and user filters, so different people can get different numbers from the same subscription. And neither one beats the refresh cadence — if the extract runs nightly, the alert is a nightly alert."