In the Get Started with Snowflake DCM Projects, Build Data Pipelines with Snowflake DCM Projects, and DCM Projects for Dynamic Tables guides, you learned how DCM Projects manage Snowflake infrastructure declaratively — from a single project up to dynamic-table pipelines that evolve without full recomputation.

In this guide, you'll focus on Tasks and Task graphs — the orchestration layer that drives scheduled and event-driven work across your pipeline.

Task graphs (DAGs, or directed acyclic graphs, of Tasks — meaning dependencies flow in one direction and no task can loop back to itself) are how most production Snowflake pipelines coordinate sequences of work: a root task kicks off every run, child tasks depend on their predecessors, streams and return values can gate downstream execution, and a finalizer closes out the run. Managing that whole graph as code — with retries, schedules, warehouse bindings, and config values promoted across environments — becomes much easier to maintain as a DCM Project.

You'll define a fifteen-task demo graph that shows off every interesting Task feature in one place:

Along the way, you'll see two DCM features that make Tasks a first-class citizen of the DCM Project model:

In this step, you'll create a Snowsight Workspace linked to the sample DCM Project repository on GitHub.

1. Navigate to Projects > Workspaces in Snowsight.
2. Click Create (+) and select Git repository.
3. Enter the repository URL: https://github.com/snowflake-labs/snowflake-dcm-projects
4. Select an API Integration for GitHub (create one if needed).
5. Select Public repository.

Once the workspace is created, you'll see the repository files in the file explorer. Navigate to Quickstarts/dcm-projects-for-tasks to find two directories:

Open scripts/01_pre_deploy.sql in a Snowsight worksheet — you'll use it in the next step.

Before deploying the task graph, you need a dedicated DCM developer role, a DCM Project object, and an email notification integration that the finalizer and alerts will use.

Open scripts/01_pre_deploy.sql in a Snowsight worksheet and run each section in order. This script lives outside the DCM project directory, so it won't be picked up by Plan or Deploy.

Account-level privileges cannot be granted by a project on itself, so they all happen here, before the first plan. The script grants DCM_DEVELOPER a superset: every guide in this series shares this role, so one run of any guide's pre-deploy script prepares you for all of them, and each grant carries a comment saying what capability it buys. The ones this guide relies on are the task and alert privileges:

A serverless task or alert needs both of its pair: EXECUTE TASK lets the owner run tasks it owns, and EXECUTE MANAGED TASK is additionally required when there is no warehouse. An alert that deploys but never fires is usually one of these missing. The quality-gate branch also needs EXECUTE DATA METRIC FUNCTION and the SNOWFLAKE.DATA_QUALITY_MONITORING_VIEWER application role, which the script grants too.

Notification integrations are account-level objects — they live outside any DCM Project. The finalizer task and the failed-task alert both send through this integration:

Keep these values — you'll paste them into manifest.yml and the notification_recipient field in the next section.

The finalizer task, quality-issue notification, and failed-task alert all send email through SYSTEM$SEND_SNOWFLAKE_NOTIFICATION. This only works if the recipient email is verified on the Snowflake account.

1. Click your username (bottom-left circle) in Snowsight, then select Settings → Profile.
2. Under Email, confirm your address shows a ✅ verified badge.
3. If not, click Verify and follow the link sent to your inbox.

Navigate into the DCM_Projects_Tasks/ directory. Unlike earlier guides which were centered on tables and dynamic tables, this project's definitions are almost all about orchestration: helper functions, procedures, and the task graph itself.

Open DCM_Projects_Tasks/manifest.yml:

Note how the root task sets OVERLAP_POLICY = 'NO_OVERLAP' (the default), which ensures each graph run completes before the next one starts. You can change this to ALLOW_CHILD_OVERLAP or ALLOW_ALL_OVERLAP if your pipeline benefits from concurrent runs.

Note how templating lets the same definitions produce a DEV graph with an X-SMALL warehouse and a short runtime_multiplier of 5, and a PROD graph with a SMALL warehouse and a multiplier of 10. Notification recipients differ per environment too.

Warehouse, database, schema, and a read-only role — nothing task-specific yet, but this is the baseline that the rest of the project depends on:

Five tables support the graph:

The same file also declares the stream the graph depends on:

This file uses DEFINE PROCEDURE, so procedure lifecycle is fully DCM-managed — you don't need separate CREATE OR ALTER PROCEDURE migrations for the demo procs.

DEMO_PROCEDURE_2 is similar but fails ~50% of the time, which drives the "failing task" demo later.

Three helper functions, all managed by DCM:

DCM manages DMF attachments natively through ATTACH DATA METRIC FUNCTION, so the quality gate lives in the DCM Project using Snowflake's built-in system DMFs:

Adding or removing an attachment here changes the CHECK_DATA_QUALITY task's behavior on the next deploy (it discovers attached DMFs at runtime via GET_ACTIVE_QUALITY_CHECKS) — no manual ALTER TABLE required.

The failed-task alert is defined declaratively with DEFINE ALERT, so the alert lives alongside the tasks it monitors and evolves through the same Plan/Deploy cycle. The alert deploys with a STARTED target state, so it begins checking on its schedule as soon as you deploy. The condition filters on DATABASE_NAME because INFORMATION_SCHEMA.TASK_HISTORY returns task runs from every database in the account, not only the one named in its qualifier — without the filter, a failed task anywhere in the account would trigger this alert. The recipient email comes from the same {{notification_recipient}} manifest value the finalizer uses, so you only configure it in one place.

The alert runs serverless (no warehouse specified) and monitors every task in the database for failures in the last interval — a broader scope than the finalizer. Think of them as complementary rather than overlapping: the finalizer gives you a detailed per-run summary (even when the graph failed mid-way), while the alert is a lighter-weight, database-wide safety net that only fires when something fails. SNOWFLAKE.ALERT.GET_CONDITION_QUERY_UUID() lets you re-use the result of the condition query so you don't have to re-run it to build the message.

This is the heart of the project. Every task uses the STARTED | SUSPENDED target-state property — a DCM-only extension to DEFINE TASK that has no equivalent in CREATE TASK. With plain DDL, a new task is always created in a suspended state and you have to follow up with ALTER TASK ... RESUME (or SYSTEM$TASK_DEPENDENTS_ENABLE for a whole graph) to bring it online. By declaring the desired state inline, DCM deploys the graph fully wired up — no post-scripts needed — and resolves the root-vs-child state ordering for you. It also means that suspending a task is a declarative change: flip STARTED to SUSPENDED in Git, deploy, and DCM handles the transition.

Here's the root:

And the finalizer that closes out every run with a formatted HTML email summary:

Feature tour of the remaining tasks:

Plus the quality-gate branch:

Because every task is declared with its dependencies (AFTER ...), DCM knows the full DAG. You never have to call SYSTEM$TASK_DEPENDENTS_ENABLE after deployment — DCM handles state resolution, including the SUSPENDED branch rooted at DEMO_TASK_14.

With the manifest updated (account identifier, user, notification recipient) and the pre-deploy script run, you're ready to deploy the task graph.

1. Open DCM_Projects_Tasks/manifest.yml in the Workspaces file explorer.
2. At the bottom of the editor, confirm the project selector shows DCM_DEMO.PROJECTS.DCM_TASKS_PROJECT_DEV and the target shows DCM_DEV.

3. Click Plan. Review the changeset — you should see the warehouse, database, schema, tables, procedures, functions, and every task listed as CREATE.

4. Click Deploy.

Deployment takes about 30–60 seconds. When it succeeds, every STARTED task is already running state — the schedule on DEMO_TASK_1 will fire the root task at the next CRON slot, and DEMO_TASK_14 and DEMO_TASK_15 are correctly in SUSPENDED state.

scripts/02_post_deploy.sql seeds the source table and triggers the first graph run. Everything the graph depends on is already DCM-managed — the stream, the DMF attachments, and the failed-task alert, which deploys STARTED (see tables.sql, expectations.sql and alerts.sql above).

DEMO_STREAM is declared with DEFINE STREAM next to its source table and deploys empty. DEMO_TASK_8 has WHEN SYSTEM$STREAM_HAS_DATA('...DEMO_STREAM'), so without data it is skipped on every graph run — exactly the "conditional execution on a stream" scenario.

Open that script in a Snowsight worksheet and walk through it section by section.

The graph kicks off immediately — you don't have to wait for the CRON schedule.

Because the alert deploys with a STARTED target state, it is already evaluating on its 60-minute schedule — no RESUME is needed. To see it fire on demand rather than waiting for the schedule, force-run it after the graph run has finished — a run takes several minutes:

This evaluates the alert condition immediately against recent task history. Run it straight after EXECUTE TASK and no task has failed yet, so it evaluates to false and sends nothing; run it once DEMO_TASK_9 has failed and it fires.

Navigate to Monitoring → Task History in Snowsight. Filter by database DCM_DEMO_4_DEV and you'll see the run you just triggered.

Click into the run to see the full graph:

You should see:

Check your inbox — you should see two kinds of notification email from this quickstart:

The finalizer gives you per-run detail; the alert is a background safety net that catches failures even if the finalizer itself errors out.

Run the graph a few more times (EXECUTE TASK dcm_demo_4_dev.pipeline.demo_task_1;) to see the random branches exercise themselves. Each run produces a fresh summary email thanks to the finalizer. To test the alert on demand, run EXECUTE ALERT dcm_demo_4_dev.pipeline.failed_task_alert;.

The real power of putting Tasks in DCM shows up when you want to change something. Suppose you want DEMO_TASK_14 to actually run in DEV. Open tasks.sql, change its target state:

Click Plan. The changeset shows a single ALTER TASK to flip the state. Click Deploy. Next graph run, DEMO_TASK_14 and DEMO_TASK_15 both execute.

This is the pattern: schema change, Plan, Deploy. No drift between environments — and because target state is part of the definition, if someone manually suspends a task outside DCM, the next deploy will re-enable it.

When you're done, open scripts/03_cleanup.sql in a Snowsight worksheet and run it. It purges everything the project manages, drops the now-empty project object, and drops the notification integration this guide created:

PURGE drops every object the project created — database, tables, stream, task graph, alert, functions, procedures, warehouse, roles, and all their data. It is irreversible, and it leaves the project object behind, which is why the DROP follows.

The dcm_demo database, its projects schema and the dcm_developer role are shared across every guide in this series, so the script leaves them in place, commented out. The dcm_demo.projects schema holds the project objects for every DCM guide in this series, so only drop it once you have finished with all of them. Check what it contains first:

The inherited-grants account parameter enabled during setup also stays on. It is account-wide and the other guides in this series need it; the script carries the commented-out line to turn it off:

If PURGE ever fails, the script tells you to suspend the root task and the alert first, so nothing keeps consuming credits while you investigate. The known cause is a data metric function attachment, which this guide has; dropping the table the DMF is attached to removes the attachment, after which PURGE succeeds.

In this guide, you learned how to:

The combination of DCM Projects and Tasks gives you the same production-grade workflow for orchestration that you already have for tables: version-controlled definitions, environment-aware deployments, and Plan/Deploy reviewability for every change.

You've completed the 4-part DCM series. Ready to go deeper?