New snapshot_meta_column_names config for dbt snapshots

website/docs/docs/cloud/account-settings.md

@@ -39,7 +39,7 @@ To use, select the **Enable partial parsing between deployment runs** option fro
 
 <Lightbox src="/img/docs/deploy/example-account-settings.png" width="85%" title="Example of the Enable partial parsing between deployment runs option" />
 
-## Account access to Advanced CI features <Lifecycle status="beta" />
+## Account access to Advanced CI features <Lifecycle status="enterprise" />
 
 [Advanced CI](/docs/deploy/advanced-ci) features, such as [compare changes](/docs/deploy/advanced-ci#compare-changes), allow dbt Cloud account members to view details about the changes between what's in the production environment and the pull request.
 

website/docs/docs/cloud/git/connect-github.md

@@ -17,7 +17,7 @@ Connecting your GitHub account to dbt Cloud provides convenience and another lay
   * **Note** — [Single tenant](/docs/cloud/about-cloud/tenancy#single-tenant) accounts offer enhanced connection options for integrating with an On-Premises GitHub deployment setup using the native integration.  This integration allows you to use all the features of the integration, such as triggering CI builds. The dbt Labs infrastructure team will coordinate with you to ensure any additional networking configuration requirements are met and completed. To discuss details, contact dbt Labs support or your dbt Cloud account team.
 - You _must_ be a **GitHub organization owner** in order to [install the dbt Cloud application](/docs/cloud/git/connect-github#installing-dbt-cloud-in-your-github-account) in your GitHub organization. To learn about GitHub organization roles, see the [GitHub documentation](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization). 
 - The GitHub organization owner requires [_Owner_](/docs/cloud/manage-access/self-service-permissions) or [_Account Admin_](/docs/cloud/manage-access/enterprise-permissions) permissions when they log into dbt Cloud to integrate with a GitHub environment using organizations.
-- You may need to temporarily provide an extra dbt Cloud user account with _Owner_ or _Account Admin_ [permissions](/docs/cloud/manage-access/self-service-permissions) for your GitHub organization owner until they complete the installation.
+- You may need to temporarily provide an extra dbt Cloud user account with _Owner_ or _Account Admin_ [permissions](/docs/cloud/manage-access/enterprise-permissions) for your GitHub organization owner until they complete the installation.
 
 
 ## Installing dbt Cloud in your GitHub account

website/docs/docs/cloud/manage-access/cloud-seats-and-users.md

@@ -3,7 +3,7 @@ title: "Users and licenses"
 description: "Learn how dbt Cloud administrators can use licenses and seats to control access in a dbt Cloud account."
 id: "seats-and-users"
 sidebar: "Users and licenses"
-pagination_next: "docs/cloud/manage-access/self-service-permissions"
+pagination_next: "docs/cloud/manage-access/enterprise-permissions"
 pagination_prev: null
 ---
 

website/docs/docs/cloud/manage-access/self-service-permissions.md

@@ -1,42 +1,84 @@
 ---
-title: "Self-service permissions"
-description: "Learn how dbt Cloud administrators can use self-service permissions to control access in a dbt Cloud account."
+title: "Self-service Team account permissions"
+description: "Learn how dbt Cloud administrators can use self-service permissions to control access in a dbt Cloud Team account."
+sidebar_label: "Team permissions"
 id: "self-service-permissions"
 ---
 
-import Permissions from '/snippets/_self-service-permissions-table.md';
+Self-service Team accounts are a quick and easy way to get dbt Cloud up and running for a small team. For teams looking to scale and access advanced features like SSO, group management, and support for larger user bases, upgrading to an [Enterprise](/docs/cloud/manage-access/enterprise-permissions) account unlocks these capabilities. 
 
+If you're interested in upgrading, contact [dbt Labs today](https://www.getdbt.com/contact)
 
-<Permissions features={'/snippets/_self-service-permissions-table.md'}/>
+## Groups and permissions
 
-## Read-Only vs. Developer License Types
+Groups determine a user's permission and there are three groups are available for Team plan dbt Cloud accounts: Owner, Member, and Everyone. The first Owner user is the person who created the dbt Cloud account. 
 
-Users configured with Read-Only license types will experience a restricted set of permissions in dbt Cloud. If a user is associated with a _Member_ permission set and a Read-Only seat license, then they will only have access to what a Read-Only seat allows. See [Seats and Users](/docs/cloud/manage-access/seats-and-users) for more information on the impact of licenses on these permissions.
+New users are added to the Member and Everyone groups when they onboard but this can be changed when the invitation is created. These groups only affect users with a [Developer license](#licenses) assigned. 
 
-## Owner and Member Groups in dbt Cloud Enterprise  
+The group access permissions are as follows:
 
-By default, new users are added to the Member and Owner groups when they onboard to a new dbt Cloud account. Member and Owner groups are included with every new dbt Cloud account because they provide access for administrators to add users and groups, and to apply permission sets.
+- **Owner** &mdash; Full access to account features.
+- **Member** &mdash; Robust access to the account with restrictions on features that can alter billing or security.
+- **Everyone** &mdash; A catch-all group for all users in the account. This group does not have any permission assignments beyond the user's profile. Users must be assigned to either the Member or Owner group to work in dbt Cloud. 
 
-You will need owner and member groups to help with account onboarding, but these groups can create confusion when initially setting up SSO and RBAC for dbt Cloud Enterprise accounts as described in the [Enterprise Permissions](enterprise-permissions) guide. Owner and Member groups are **account level** groups, so their permissions override any project-level permissions you wish to apply.
+## Licenses
 
-After onboarding administrative users and configuring RBAC/SSO groups, we recommend the following steps for onboarding users to a dbt Cloud Enterprise account.
+You assign licenses to every user onboarded into dbt Cloud. You only assign Developer-licensed users to the Owner and Member groups. The groups have no impact on Read-only or IT licensed users.
 
+There are three license types:
 
-### Prerequisites
+- **Developer** &mdash; The default license. Developer licenses don't restrict access to any features, so users with this license should be assigned to either the Owner or Member group. You're allotted up to 8 developer licenses per account.
+- **Read-Only** &mdash; Read-only access to your project, including environments dbt Explorer. Doesn't have access to account settings at all. Functions the same regardless of group assignments. You're allotted up to 5 read-only licenses per account.
+- **IT** &mdash; Partial access to the account settings including users, integrations, billing, and API settings. Cannot create or edit connects or access the project at all. Functions the same regardless of group assignments. You're allocated 1 seat per account.
 
-You need to create an Account Admins group before removing any other groups.
+See [Seats and Users](/docs/cloud/manage-access/seats-and-users) for more information on the impact of licenses on these permissions.
 
-1. Create an Account Admins group.  
-2. Assign at least one user to the Account Admins group. The assigned user can manage future group, SSO mapping, and user or group assignment.
+## Table of groups, licenses, and permissions
 
-### Remove the Owner and Member groups
+Key:
 
-Follow these steps for both Owner and Member groups:
+* (W)rite &mdash; Create new or modify existing. Includes `send`, `create`, `delete`, `allocate`, `modify`, and `read`.
+* (R)ead &mdash; Can view but can not create or change any fields.
+* No value &mdash; No access to the feature.
+
+Permissions:
+
+* [Account-level permissions](#account-permissions-for-account-roles) &mdash; Permissions related to management of the dbt Cloud account. For example, billing and account settings.
+* [Project-level permissions](#project-permissions-for-account-roles) &mdash; Permissions related to the projects in dbt Cloud. For example, Explorer and the IDE.
+
+The following tables outline the access that users have if they are assigned a Developer license and the Owner or Member group, Read-only license, or IT license.
+
+#### Account permissions for account roles
+
+| Account-level permission| Owner | Member | Read-only license|  IT license  |
+|:------------------------|:-----:|:------:|:----------------:|:------------:|
+| Account settings        |   W   |   W    |                  |       W      |
+| Billing                 |   W   |        |                  |       W      |
+| Invitations             |   W   |   W    |                  |       W      |
+| Licenses                |   W   |   R    |                  |       W      |
+| Users                   |   W   |   R    |                  |       W      |
+| Project (create)        |   W   |   W    |                  |       W      |
+| Connections             |   W   |   W    |                  |       W      |
+| Service tokens          |   W   |        |                  |       W      |
+| Webhooks                |   W   |   W    |                  |              |
+
+#### Project permissions for account roles
+
+|Project-level permission | Owner | Member  | Read-only | IT license |
+|:------------------------|:-----:|:-------:|:---------:|:----------:|
+| Adapters                |   W   |    W    |    R      |             |
+| Connections             |   W   |    W    |    R      |             |
+| Credentials             |   W   |    W    |    R      |             |
+| Custom env. variables   |   W   |    W    |    R      |             |
+| Develop (IDE or dbt Cloud CLI)| W |  W    |           |             |
+| Environments            |   W   |    W    |    R      |             |
+| Jobs                    |   W   |    W    |    R      |             |
+| dbt Explorer            |   W   |    W   |    R      |             |
+| Permissions             |   W   |    R    |           |             |
+| Profile                 |   W   |    W    |    R      |             |
+| Projects                |   W   |    W    |    R      |             |
+| Repositories            |   W   |    W    |    R      |             |
+| Runs                    |   W   |    W    |    R      |             |
+| Semantic Layer Config   |   W   |    W    |    R      |             |
 
-1. Log into dbt Cloud.
-2. Click the gear icon at the top right and select **Account settings**.
-3. Select **Groups** then select **OWNER** or **MEMBER**** group.  
-4. Click **Edit**.
-5. At the bottom of the Group page, click **Delete**.
 
-The Account Admin can add additional SSO mapping groups, permission sets, and users as needed.

website/docs/docs/dbt-cloud-apis/service-tokens.md

@@ -54,7 +54,7 @@ Job admin service tokens can authorize requests for viewing, editing, and creati
 Job runner service tokens can authorize requests for triggering runs and viewing historical runs.
 
 **Member** <br/>
-Member service tokens can authorize requests for viewing and editing resources, triggering runs, and inviting members to the account. Tokens assigned the Member permission set will have the same permissions as a Member user. For more information about Member users, see "[Self-service permissions](/docs/cloud/manage-access/self-service-permissions)".
+Member service tokens can authorize requests for viewing and editing resources, triggering runs, and inviting members to the account. Tokens assigned the Member permission set will have the same permissions as a Member user. For more information about Member users, see "[Self-service Team plan permissions](/docs/cloud/manage-access/self-service-permissions)".
 
 **Read-only**<br/>
 Read-only service tokens can authorize requests for viewing a read-only dashboard, viewing generated documentation, and viewing source freshness reports. This token can access and retrieve account-level information endpoints on the [Admin API](/docs/dbt-cloud-apis/admin-cloud-api) and authorize requests to the [Discovery API](/docs/dbt-cloud-apis/discovery-api). 

website/docs/docs/dbt-versions/release-notes.md

@@ -20,10 +20,8 @@ Release notes are grouped by month for both multi-tenant and virtual private clo
 
 ## October 2024
 
-
-- **New**: In dbt Cloud Versionless, [Snapshots](/docs/build/snapshots) have been updated to use YAML configuration files instead of SQL snapshot blocks. This new feature simplifies snapshot management and improves performance, and will soon be released in dbt Core 1.9.
-  - Who does this affect? New user on Versionless can define snapshots using the new YAML specification. Users upgrading to Versionless who use snapshots can keep their existing configuration or can choose to migrate their snapshot definitions to YAML. 
-  - Users on dbt 1.8 and earlier: No action is needed; existing snapshots will continue to work as before. However, we recommend upgrading to Versionless to take advantage of the new snapshot features.
+- **Behavior change:** Set [`state_modified_compare_more_unrendered`](/reference/global-configs/behavior-changes#source-definitions-for-state) to true to reduce false positives for `state:modified` when configs differ between `dev` and `prod` environments.
+- **Behavior change:** Set the [`skip_nodes_if_on_run_start_fails`](/reference/global-configs/behavior-changes#failures-in-on-run-start-hooks) flag to `True` to skip all selected resources from running if there is a failure on an `on-run-start` hook.
 - **Enhancement**: In dbt Cloud Versionless, snapshots defined in SQL files can now use `config` defined in `schema.yml` YAML files. This update resolves the previous limitation that required snapshot properties to be defined exclusively in `dbt_project.yml` and/or a `config()` block within the SQL file. This enhancement will be included in the upcoming dbt Core v1.9 release.
 - **New**: In dbt Cloud Versionless, the `snapshot_meta_column_names` config allows for customizing the snapshot metadata columns. This feature allows an organization to align these automatically-generated column names with their conventions, and will be included in the upcoming dbt Core 1.9 release.
 - **Enhancement**: In May 2024, dbt Cloud versionless began inferring a model's `primary_key` based on configured data tests and/or constraints within `manifest.json`. The inferred `primary_key` is visible in dbt Explorer and utilized by the dbt Cloud [compare changes](/docs/deploy/run-visibility#compare-tab) feature. This will also be released in dbt Core 1.9.

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

@@ -5,12 +5,12 @@ sidebar_label: "Advanced CI"
 description: "Advanced CI enables developers to compare changes by demonstrating the changes the code produces."
 ---
 
-# Advanced CI <Lifecycle status="preview" />
+# Advanced CI <Lifecycle status="enterprise"/>
 
 [Continuous integration workflows](/docs/deploy/continuous-integration) help increase the governance and improve the quality of the data. Additionally for these CI jobs, you can use Advanced CI features, such as [compare changes](#compare-changes), that provide details about the changes between what's currently in your production environment and the pull request's latest commit, giving you observability into how data changes are affected by your code changes. By analyzing the data changes that code changes produce, you can ensure you're always shipping trustworthy data products as you're developing.
 
-:::tip Preview feature
-The compare changes feature is currently available as a [preview](/docs/dbt-versions/product-lifecycles#dbt-cloud) in dbt Cloud. dbt Labs plans to provide additional Advanced CI features in the near future. More info coming soon.
+:::tip More features
+dbt Labs plans to provide additional Advanced CI features in the near future. More info coming soon.
 
 :::
 

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

@@ -15,8 +15,8 @@ dbt Labs recommends that you create your CI job in a dedicated dbt Cloud [deploy
 - CI features:
    - For both the [concurrent CI checks](/docs/deploy/continuous-integration#concurrent-ci-checks) and [smart cancellation of stale builds](/docs/deploy/continuous-integration#smart-cancellation) features, your dbt Cloud account must be on the [Team or Enterprise plan](https://www.getdbt.com/pricing/).
    - The [SQL linting](/docs/deploy/continuous-integration#sql-linting) feature is currently available in beta to a limited group of users and is gradually being rolled out. If you're in the beta, the **Linting** option is available for use. 
-- [Advanced CI](/docs/deploy/advanced-ci) features:<Lifecycle status="preview" />
-   - For the [compare changes](/docs/deploy/advanced-ci#compare-changes) feature, your dbt Cloud account must have access to Advanced CI. Please ask your [dbt Cloud administrator to enable](/docs/cloud/account-settings#account-access-to-advanced-ci-features) this for you.
+- [Advanced CI](/docs/deploy/advanced-ci) features:
+   - For the [compare changes](/docs/deploy/advanced-ci#compare-changes) feature, your dbt Cloud account must be on the [Enterprise plan](https://www.getdbt.com/pricing/) and have enabled Advanced CI features. Please ask your [dbt Cloud administrator to enable](/docs/cloud/account-settings#account-access-to-advanced-ci-features) this feauture for you. After enablement, the **Run compare changes** option becomes available in the CI job settings.
 - Set up a [connection with your Git provider](/docs/cloud/git/git-configuration-in-dbt-cloud). This integration lets dbt Cloud run jobs on your behalf for job triggering.
    - If you're using a native [GitLab](/docs/cloud/git/connect-gitlab) integration, you need a paid or self-hosted account that includes support for GitLab webhooks and [project access tokens](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html). If you're using GitLab Free, merge requests will trigger CI jobs but CI job status updates (success or failure of the job) will not be reported back to GitLab.
 
@@ -37,7 +37,7 @@ To make CI job creation easier, many options on the **CI job** page are set to d
 1. Options in the **Execution settings** section:
     - **Commands** &mdash; By default, it includes the `dbt build --select state:modified+` command. This informs dbt Cloud to build only new or changed models and their downstream dependents. Importantly, state comparison can only happen when there is a deferred environment selected to compare state to. Click **Add command** to add more [commands](/docs/deploy/job-commands)  that you want to be invoked when this job runs.
     - **Linting**<Lifecycle status="beta" /> &mdash; Enable this option for dbt to [lint the SQL files](/docs/deploy/continuous-integration#sql-linting) in your project as the first step in `dbt run`. If this check runs into an error, dbt can either **Fail job run** or **Continue running job**. 
-    - **Run compare changes**<Lifecycle status="preview" /> &mdash; Enable this option to compare the last applied state of the production environment (if one exists) with the latest changes from the pull request, and identify what those differences are. To enable record-level comparison and primary key analysis, you must add a [primary key constraint](/reference/resource-properties/constraints) or [uniqueness test](/reference/resource-properties/data-tests#unique). Otherwise, you'll receive a "Primary key missing" error message in dbt Cloud.
+    - **Run compare changes**<Lifecycle status="enterprise" /> &mdash; Enable this option to compare the last applied state of the production environment (if one exists) with the latest changes from the pull request, and identify what those differences are. To enable record-level comparison and primary key analysis, you must add a [primary key constraint](/reference/resource-properties/constraints) or [uniqueness test](/reference/resource-properties/data-tests#unique). Otherwise, you'll receive a "Primary key missing" error message in dbt Cloud.
 
       To review the comparison report, navigate to the [Compare tab](/docs/deploy/run-visibility#compare-tab) in the job run's details. A summary of the report is also available from the pull request in your Git provider (see the [CI report example](#example-ci-report)). 
     - **Compare changes against an environment (Deferral)** &mdash; By default, it’s set to the **Production** environment if you created one. This option allows dbt Cloud to check the state of the code in the PR against the code running in the deferred environment, so as to only check the modified code, instead of building the full table or the entire DAG.

website/docs/docs/deploy/run-visibility.md

@@ -55,7 +55,7 @@ This provides a list of the artifacts generated by the job run. The files are sa
 
 <Lightbox src="/img/docs/dbt-cloud/example-artifacts-tab.png" width="85%" title="Example of the Artifacts tab" />
 
-### Compare tab <Lifecycle status="preview"/>
+### Compare tab <Lifecycle status="enterprise" />
 
 The **Compare** tab is shown for [CI job runs](/docs/deploy/ci-jobs) with the **Run compare changes** setting enabled. It displays details about [the changes from the comparison dbt performed](/docs/deploy/advanced-ci#compare-changes) between what's in your production environment and the pull request. To help you better visualize the differences, dbt Cloud highlights changes to your models in red (deletions) and green (inserts).
 

website/docs/guides/sl-snowflake-qs.md

@@ -97,7 +97,7 @@ Open a new tab and follow these quick steps for account setup and data loading i
 ## Prerequisites
 
 - You need a [dbt Cloud](https://www.getdbt.com/signup/) Trial, Team, or Enterprise account for all deployments. Contact your representative for Single-tenant setup; otherwise, create an account using this guide.
-- Have the correct [dbt Cloud license](/docs/cloud/manage-access/seats-and-users) and [permissions](/docs/cloud/manage-access/self-service-permissions) based on your plan:
+- Have the correct [dbt Cloud license](/docs/cloud/manage-access/seats-and-users) and [permissions](/docs/cloud/manage-access/enterprise-permissions) based on your plan:
   <DetailsToggle alt_header="More info on license and permissions">  
 
   - Enterprise &mdash; Developer license with Account Admin permissions. Or "Owner" with a Developer license, assigned Project Creator, Database Admin, or Admin permissions.

website/docs/reference/global-configs/behavior-changes.md

@@ -64,15 +64,32 @@ When we use dbt Cloud in the following table, we're referring to accounts that h
 
 | Flag                                                            | dbt Cloud: Intro | dbt Cloud: Maturity | dbt Core: Intro | dbt Core: Maturity | 
 |-----------------------------------------------------------------|------------------|---------------------|-----------------|--------------------|
-| require_explicit_package_overrides_for_builtin_materializations | 2024.04.141      | 2024.06.192         | 1.6.14, 1.7.14  | 1.8.0             |
-| require_resource_names_without_spaces                           | 2024.05.146      | TBD*                | 1.8.0           | 1.9.0             |
-| source_freshness_run_project_hooks                              | 2024.03.61       | TBD*                | 1.8.0           | 1.9.0             |
-| [Redshift] [restrict_direct_pg_catalog_access](#redshift-restrict_direct_pg_catalog_access)    | 2024.09.242      | TBD*                | dbt-redshift v1.9.0           | 1.9.0             |
+| require_explicit_package_overrides_for_builtin_materializations | 2024.04          | 2024.06             | 1.6.14, 1.7.14  | 1.8.0             |
+| require_resource_names_without_spaces                           | 2024.05          | TBD*                | 1.8.0           | 1.9.0             |
+| source_freshness_run_project_hooks                              | 2024.03          | TBD*                | 1.8.0           | 1.9.0             |
+| [Redshift] [restrict_direct_pg_catalog_access](#redshift-restrict_direct_pg_catalog_access)    | 2024.09          | TBD*                | dbt-redshift v1.9.0           | 1.9.0             |
+| skip_nodes_if_on_run_start_fails                                | 2024.10          | TBD*                | 1.9.0           | TBD*              |
+| state_modified_compare_more_unrendered                          | 2024.10          | TBD*                | 1.9.0           | TBD*              |
 
 When the dbt Cloud Maturity is "TBD," it means we have not yet determined the exact date when these flags' default values will change. Affected users will see deprecation warnings in the meantime, and they will receive emails providing advance warning ahead of the maturity date. In the meantime, if you are seeing a deprecation warning, you can either:
 - Migrate your project to support the new behavior, and then set the flag to `True` to stop seeing the warnings.
 - Set the flag to `False`. You will continue to see warnings, and you will retain the legacy behavior even after the maturity date (when the default value changes).
 
+### Failures in on-run-start hooks
+
+The flag is `False` by default.
+
+Set the `skip_nodes_if_on_run_start_fails` flag to `True` to skip all selected resources from running if there is a failure on an `on-run-start` hook. 
+
+### Source definitions for state:modified
+
+The flag is `False` by default.
+
+Set `state_modified_compare_more_unrendered` to `True` to reduce false positives during `state:modified` checks (especially when configs differ by target environment like `prod` vs. `dev`).
+
+Setting the flag to `True` changes the `state:modified` comparison from using rendered values to unrendered values instead. It accomplishes this by persisting `unrendered_config` during model parsing and `unrendered_database` and `unrendered_schema` configs during source parsing.
+
+
 ###  Package override for built-in materialization 
 
 Setting the `require_explicit_package_overrides_for_builtin_materializations` flag to `True` prevents this automatic override. 
@@ -128,4 +145,3 @@ on-run-start:
   - '{{ ... if flags.WHICH != 'freshness' }}'
 ```
 </File>
-

website/docs/reference/node-selection/state-comparison-caveats.md

@@ -44,12 +44,19 @@ dbt test -s "state:modified" --exclude "test_name:relationships"
 
 ### False positives
 
+<VersionBlock firstVersion="1.9">
+
+To reduce false positives during `state:modified` selection due to env-aware logic, you can set the `state_modified_compare_more_unrendered` [behavior flag](/reference/global-configs/behavior-changes#behavior-change-flags) to `True`. 
+
+</VersionBlock>
+
+<VersionBlock lastVersion="1.8">
 State comparison works by identifying discrepancies between two manifests.  Those discrepancies could be the result of:
 
 1. Changes made to a project in development
-2. Env-aware logic that causes different behavior based on the `target`, env vars, etc.
+2. Env-aware logic that causes different behavior based on the `target`, env vars, etc., which can be avoided if you upgrade to dbt Core 1.9 and set the `state_modified_compare_more_unrendered` [behavior flag](/reference/global-configs/behavior-changes#behavior-change-flags) to `True`. 
 
-State comparison detects env-aware config in `dbt_project.yml`. This target-based config registers as a modification:
+State comparison detects env-aware config in `dbt_project.yml`. This target-based config won't register as a modification:
 
 <File name='dbt_project.yml'>
 
@@ -73,6 +80,7 @@ That means the following config—functionally identical to the snippet above—
     materialized = ('table' if target.name == 'prod' else 'view')
 ) }}
 ```
+</VersionBlock>
 
 ### Final note
 

website/docs/reference/resource-configs/contract.md

@@ -2,7 +2,7 @@
 resource_types: [models]
 description: "When the contract configuration is enforced, dbt will ensure that your model's returned dataset exactly matches the attributes you have defined in yaml, such as name and data_type, as well as any additional constraints supported by the data platform."
 datatype: "{<dictionary>}"
-default_value: {contract: false}
+default_value: {enforced: false}
 id: "contract"
 ---
 

website/sidebars.js

@@ -91,8 +91,8 @@ const sidebarSettings = {
                   },
                   items: [
                     "docs/cloud/manage-access/seats-and-users",
-                    "docs/cloud/manage-access/self-service-permissions",
                     "docs/cloud/manage-access/enterprise-permissions",
+                    "docs/cloud/manage-access/self-service-permissions",
                   ],
                 },
                 {

website/snippets/_new-sl-setup.md

@@ -1,6 +1,6 @@
 import SLEnvVars from '/snippets/_sl-env-vars.md';
 
-You must be part of the Owner group and have the correct [license](/docs/cloud/manage-access/seats-and-users) and [permissions](/docs/cloud/manage-access/self-service-permissions) to set up the Semantic Layer at the environment and project level.
+You must be part of the Owner group and have the correct [license](/docs/cloud/manage-access/seats-and-users) and [permissions](/docs/cloud/manage-access/enterprise-permissions) to set up the Semantic Layer at the environment and project level.
 - Enterprise plan:
   - Developer license with Account Admin permissions, or
   - Owner with a Developer license, assigned Project Creator, Database Admin, or Admin permissions.