highlight job completion more on docs

website/docs/docs/deploy/about-ci.md

@@ -19,9 +19,9 @@ Refer to the guide [Get started with continuous integration tests](/guides/set-u
     icon="dbt-bit"/>
 
   <Card
-    title="Advanced CI (preview)"
+    title="Advanced CI"
     body="Compare the differences between what's in the production environment and the pull request before merging those changes, ensuring that you're always shipping trusted data products."
     link="/docs/deploy/advanced-ci"
     icon="dbt-bit"/>
 
-</div><br />
+</div><br />

website/docs/docs/deploy/deploy-jobs.md

@@ -13,7 +13,7 @@ You can use deploy jobs to build production data assets. Deploy jobs make it eas
 - Job run details, including run timing, [model timing data](/docs/deploy/run-visibility#model-timing), and [artifacts](/docs/deploy/artifacts)
 - Detailed run steps with logs and their run step statuses
 
-You can create a deploy job and configure it to run on [scheduled days and times](#schedule-days) or enter a [custom cron schedule](#cron-schedule).
+You can create a deploy job and configure it to run on [scheduled days and times](#schedule-days), enter a [custom cron schedule](#cron-schedule), or [trigger the job after another job completes](#trigger-on-job-completion).
 
 
 ## Prerequisites
@@ -115,11 +115,18 @@ Examples of cron job schedules:
 
 ### Trigger on job completion  <Lifecycle status="team,enterprise" />
 
-To _chain_ deploy jobs together, enable the **Run when another job finishes** option and specify the upstream (parent) job that, when it completes, will trigger your job. You can also use the [Create Job API](/dbt-cloud/api-v2#/operations/Create%20Job) to do this.
+To _chain_ deploy jobs together:
+1. In the **Triggers** section, enable the **Run when another job finishes** option.
+2. Select the project that has the deploy job you want to run after completion.
+3. Specify the upstream (parent) job that, when completed, will trigger your job.
+   - You can also use the [Create Job API](/dbt-cloud/api-v2#/operations/Create%20Job) to do this.
+4. In the **Completes on** option, select the job run status(es) that will [enqueue](/docs/deploy/job-scheduler#scheduler-queue) the deploy job.
 
-You can set up a configuration where an upstream job triggers multiple downstream (child) jobs and jobs in other projects. You must have proper [permissions](/docs/cloud/manage-access/enterprise-permissions#project-role-permissions) to the project and job to configure the trigger. 
+<Lightbox src="/img/docs/deploy/deploy-job-completion.jpg" width="100%" title="Example of Trigger on job completion on the Deploy job page"/>
 
-For jobs that are triggered to run by another job, a link to the upstream job run is available from your [job's run details](/docs/deploy/run-visibility#job-run-details).
+5. You can set up a configuration where an upstream job triggers multiple downstream (child) jobs and jobs in other projects. You must have proper [permissions](/docs/cloud/manage-access/enterprise-permissions#project-role-permissions) to the project and job to configure the trigger. 
+
+If another job triggers your job to run, you can find a link to the upstream job in the [run details section](/docs/deploy/run-visibility#job-run-details).
 
 ## Related docs
 

website/docs/docs/deploy/deployment-overview.md

@@ -33,7 +33,7 @@ Learn how to use dbt Cloud's features to help your team ship timely and quality
 
 <Card
     title="Deploy jobs"
-    body="Create and schedule jobs for the dbt Cloud scheduler to run."
+    body="Create and schedule jobs for the job scheduler to run. <br /><br />Runs on a schedule, by API, or after another job completes."
     link="/docs/deploy/deploy-jobs"
     icon="dbt-bit"/>
 

website/docs/docs/deploy/jobs.md

@@ -4,21 +4,22 @@ sidebar_label: "About Jobs"
 description: "Learn about the different job types in dbt Cloud and what their differences are." 
 tags: [scheduler]
 pagination_next: "docs/deploy/deploy-jobs"
+hide_table_of_contents: true
 ---
 
 These are the available job types in dbt Cloud: 
-- [Deploy jobs](/docs/deploy/deploy-jobs) — To create and set up triggers for building production data assets
-- [Continuous integration (CI) jobs](/docs/deploy/continuous-integration) — To create and set up triggers for checking code changes
-- [Merge jobs](/docs/deploy/merge-jobs) — To create and set up triggers for merged pull requests
+- [Deploy jobs](/docs/deploy/deploy-jobs) — Build production data assets. Runs on a schedule, by API, or after another job completes.
+- [Continuous integration (CI) jobs](/docs/deploy/continuous-integration) — Test and validate code changes before merging. Triggered by commit to a PR or by API.
+- [Merge jobs](/docs/deploy/merge-jobs) — Deploy merged changes into production. Runs after a successful PR merge or by API.
 
-Below is a comparison table that describes the behaviors of the different job types:
+The following comparison table describes the behaviors of the different job types:
 
 |  | **Deploy jobs** | **CI jobs** | **Merge jobs** |  
 | --- | --- | --- | --- |
 | Purpose | Builds production data assets. | Builds and tests new code before merging changes into production. | Build merged changes into production or update state for deferral. |
-| Trigger types | Triggered by a schedule or by API. | Triggered by a commit to a PR or by API. | Triggered by a successful merge into the environment's branch or by API.|
+| Trigger types | Triggered by a schedule, API, or the successful completion of another job. | Triggered by a commit to a PR or by API. | Triggered by a successful merge into the environment's branch or by API.|
 | Destination | Builds into a production database and schema. | Builds into a staging database and ephemeral schema, lived for the lifetime of the PR. | Builds into a production database and schema. |
 | Execution mode | Runs execute sequentially, so as to not have collisions on the underlying DAG. | Runs execute in parallel to promote team velocity. | Runs execute sequentially, so as to not have collisions on the underlying DAG. |
 | Efficiency run savings | Detects over-scheduled jobs and cancels unnecessary runs to avoid queue clog. | Cancels existing runs when a newer commit is pushed to avoid redundant work. | N/A |
 | State comparison | Only sometimes needs to detect state. | Almost always needs to compare state against the production environment to build on modified code and its dependents. | Almost always needs to compare state against the production environment to build on modified code and its dependents. |
-| Job run duration | Limit is 24 hours. | Limit is 24 hours. | Limit is 24 hours. |
+| Job run duration | Limit is 24 hours. | Limit is 24 hours. | Limit is 24 hours. |