Docs
Settings
Features

Features

In the Features section, you can enable and configure various Y42 features for this space, including Orchestration, Published views, and Beta features.

Core features

Spaces core featuresSpaces core features

Orchestration

Orchestration allows you to automatically build assets and pipelines on a schedule. By default, scheduled builds and alerts only work on the main branch. If you need orchestrations to run on multiple branches, especially useful when you have multiple virtual environments, you can enable this feature from here. Set up which branch will be enabled for build schedules to run automatically.

Published views

Published Views automatically create a view for each asset on a selected branch in the data warehouse. With Virtual Data Builds, you can transform branches into virtual data environments and choose which branches will be materialized into views for each asset.

For an in-depth coverage of Published views, check out our detailed documentation page.

Beta features

Spaces beta featuresSpaces beta features

Fine-grained role management

With this feature, you can grant permissions for each type of action individually on a user level.

Auto-delete unused tables

Y42 keeps the materialization of each physical UUID table within the DWH, allowing you to easily rollback using the Virtual Data Builds mechanics. By default, these tables are kept for 30 days in your data warehouse. You can customize the timeframe for when the physical UUID tables should be deleted.

The expiration logic for deleting tables is based on two criteria:

  1. The job is older than 30 days or older than what the user has configured.
  2. It is not the latest valid job run on any existing branch's head

Let's walk through an example to illustrate the expiration logic: You have a model with a successful job run A on main and branch out to dev. Job run A is the latest valid job on both branches. After making changes on main, you run two more successful jobs (job run B and job run C) of the same model. After 30 days or a custom-configured timeframe, the expiration job will assess which jobs to expire:

  • Job run A won't be expired, because it's still the latest valid job on the dev branch. âś…
  • Job run C won't be expired, because it's the latest valid job on the main branch. âś…
  • However, job run B will be expired, as it's not the latest valid job on any existing branch. ❌
Asset's expired statusAsset's expired status