Managing Model Jobs

Once a Model has been deployed, the Model Job Management interface lets you configure, run and manage the Jobs associated with that Model. Access it from the Model node inspector by clicking the 'Manage Jobs' button or from the Job Definitions page in the Jobs module.

Configuring a Model Job

To update a Model Job's configuration from the Model Management interface: Select a Model Job and click Edit to configure it.

The following settings are available:

Section	Description
Environment	The environment where the Model Job will run
Tag	The Model version tag the Job will use when it runs
Source Table Mapping	Override design-time data source locations. New source schemas must still match the original
Target	The target Snowflake location (database, schema, table) for the materialized dataset
Incremental Materialization	Enable incremental materialization to process only new or changed data
Trigger	Configure when the Job runs: on a schedule or event-driven (when another Job or Deployment completes)
Source Freshness Conditions	Conditional triggers based on the freshness of the Model's data sources — skip the Job run if sources have not been updated
Source Data Quality Conditions	Conditional triggers based on source Data Quality checks — skip the Job run if source DQ checks fail

Via the Jobs Module

You can also update Model Job configuration by accessing the Model Job via the dedicated Job Definition interface.

Environment

Choose the environment where the Model Job will run: e.g., marketing_dev, marketing_prd, sandbox, etc.

Tag

Select a tag to use for this Model Job. The tag refers to a specific version of the Model source configuration. Using Tags allows to run different versions of the same Model in different environments.

Source Table Mapping

Override the configured Data Source location for the Model Job. Many teams use different databases or schemas to store their development and production data. E.g., if your design environment uses the DATALAKE_DEV database for design time, you can point a production job at the correct source location for this environment, e.g., DATALAKE_PRD.

Target

Specify the target Snowflake location for the materialized dataset. Since genereally, this will differ from your design time location, for other Model Jobs you can point a production job at the correct target location.

Incremental Materialization

Enable incremental materialization to process only new or changed data.

Triggers

Configure Triggers for the Model Job.

Event Driven

Model Jobs can be triggered by two kinds of events: a classic Deployment or a Job execution.

Deployments

Navigate to the Deployment's Project and select the Deloyment.

Jobs

Use the filters to find the Job to use as the trigger. Note that any type of Job can be used to trigger Model Jobs (and vice versa).

Scheduled

Model Jobs also support standard schedule based triggers.

Source Freshness Conditions

Configure Source Freshness conditions under which the Jobs module will skip execution of the Model Job. E.g., you can configure a Model Job to only run if specific sources have been updated in the last day or hour. This avoids unnecessary execution of large, costly jobs.

Managing Multiple Jobs for a Model

A single Model can be deployed into multiple environments by creating additional Model Jobs, each configured with a different Environment.

To add a new Job for an existing Model:

• Click Add Job in the Model node inspector in the Workbench, or

• Create a new Job Definition from the Jobs module and select the Model as the workload.

Configure the Job

Promoting a New Version to Another Environment

When changes are made to the Model in the Workbench and re-deployed in the design environment, a new tag is created. Jobs in other environments (e.g. test, production) are not updated automatically — they continue running on their currently configured tag.

To promote a new version to another environment:

1. Open the Model Job for the target environment.
2. Click Edit and update the Tag to the new version.
3. Save and run the Job to apply the new version.

This controlled promotion flow ensures that changes to a Model in development are only applied to downstream environments when explicitly approved.