The one-time, install-wide admin setup statements for the shared dispatcher, plus this schedule's observed task state — the manual fallback to one-click Activate.

This route answers 404 feature-disabled only when the surface is off. All seven /v1/dashboards/{id}/email-schedules verbs share the editionCapabilities.unattendedSchedules cell, and DVT-4490 ships it TRUE wherever emailSchedule is true — the normal Snowflake native-app case — so a shipped install answers 200 here, not 404. The 404 survives for exactly two operator-facing reasons: DVT_UNATTENDED_SCHEDULES_ENABLED=false set on BOTH dvt-api and dvt-engine (an explicit opt-out, not the shipped default), or an edition where emailSchedule itself is false. Stored rows are unaffected either way — this was always a switch, not a migration. Clients must gate on the capability cell rather than assume a fixed answer from this route's existence. POST /v1/dashboards/{id}/email ("Email me this report now") is unaffected by this cell and works regardless.

Returns the statements an admin runs in THIS account (DVT-4300), plus what dvt has observed about the resulting task. Requires dashboard:write — it is the instruction sheet for pointing a recurring data egress at a recipient list, which is the same bar ADR-0051 §3 sets for managing a schedule at all.

DVT-4796: adminSetupSql is now the install-wide "Admin setup (one time)" dispatcher block — the same text on every schedule's response in this app, not rendered per schedule. It creates and owns the ONE shared dispatcherTaskName task every activated schedule in the install fires through; createTaskSql is retired ("", deprecated — see the field's own description) because there is no longer a per-schedule CREATE TASK to run. grantsSql carries the identical text for compatibility. dropTaskSql and legacyTaskName are non-empty/non-null only for a schedule still on the legacy per-report task (taskDriver == "task"); a schedule that has never been activated, or is already on the shared dispatcher, has nothing to drop.

dvt does not create the dispatcher task, and cannot. It lives in the consumer's own database, owned by a Snowflake role their admin chooses (declaredRole), and that is exactly what gives an unattended run a real identity to read the data as — ADR-0069 declined to give dvt a standing IMPERSONATE ON USER grant, so the identity belongs to the customer instead. Until an admin runs these statements no schedule in the install can fire.

taskState is a record of OBSERVATION, not a state dvt controls:

• absent — dvt has seen no run. This covers BOTH "nobody created the task" and "an admin created it but the first occurrence has not come round yet"; dvt cannot tell those apart. Calling this route does NOT change it.
• confirmed — a run actually reached dvt. Only a real run sets this, so a customer who copies the SQL and never pastes it is never told their reports are sending.
• declared is reserved for a future explicit affordance and is never returned today; nothing sets it.

dvt cannot list, edit, disable or drop a task it does not own; deleting the schedule here does not remove the task, which is why dropTaskSql is returned.