< kapa ai> version 2 I have this yml file in dbt sources nam Elementary Community #ask-elementary-ai

<@U088WCP3B4P> version: 2 I have this yml file in...

Yang Xu

03/03/2026, 9:43 AM

@kapa.ai version: 2 I have this yml file in dbt: sources: - name: dummy_source description: Dummy Mongo data for development and testing purposes. database: "DUMMY_DATABASE" schema: dummy_schema tables: - name: dummy_admin_individuals description: Dummy admin individuals table for testing. columns: - name: dummy_first_name config: meta: database_tags: data_classification: "dummy_level" - name: dummy_last_name config: meta: database_tags: data_classification: "dummy_level" - name: dummy_user_emails config: meta: database_tags: data_classification: "dummy_level" - name: dummy_advance_payments description: Dummy advance payments feature adoption data. - name: dummy_expenses description: Dummy expense data for testing. - name: dummy_module_employee_level description: Dummy employee module table containing test access data. - name: dummy_payments_bridge_users description: > Dummy team collection containing fake company activation data for bridge integration testing. - name: dummy_tickings description: Dummy ticking feature adoption data. - name: dummy_roles - name: dummy_collaborator_role config: freshness: warn_after: period: hour count: 24 meta: channel: dummy-data-quality-warning I want to apply the freshness test to all tables in the schema, except one table dummy_advance_payments, how to exclude it

kapa.ai

03/03/2026, 9:43 AM

Hey @Yang Xu! Searching the Elementary knowledge base, normally takes around 15 seconds 😊 Feel free to ask a follow-up question once I've answered by mentioning me with @kapa.ai

kapa.ai

03/03/2026, 9:43 AM

Based on the knowledge sources, dbt's native freshness configuration doesn't provide a built-in "exclude" option for specific tables when defined at the source level. However, you can achieve this by overriding the freshness config at the table level — specifically, you can disable freshness for

dummy_advance_payments

by not defining a

loaded_at_field

or by removing the freshness block for that table. The recommended approach from the knowledge sources is to move the freshness config from the source level to each individual table, explicitly defining it only on the tables you want to monitor, and omitting it for

dummy_advance_payments

. [dbt sources table freshness] Here's how your YAML would look:

Copy code

version: 2

sources:
  - name: dummy_source
    description: Dummy Mongo data for development and testing purposes.
    database: "DUMMY_DATABASE"
    schema: dummy_schema
    meta:
      channel: dummy-data-quality-warning
    tables:
      - name: dummy_admin_individuals
        description: Dummy admin individuals table for testing.
        config:
          freshness:
            warn_after:
              period: hour
              count: 24
        columns:
          - name: dummy_first_name
            config:
              meta:
                database_tags:
                  data_classification: "dummy_level"
          - name: dummy_last_name
            config:
              meta:
                database_tags:
                  data_classification: "dummy_level"
          - name: dummy_user_emails
            config:
              meta:
                database_tags:
                  data_classification: "dummy_level"

      - name: dummy_advance_payments
        description: Dummy advance payments feature adoption data.
        # No freshness config here — excluded intentionally

      - name: dummy_expenses
        description: Dummy expense data for testing.
        config:
          freshness:
            warn_after:
              period: hour
              count: 24

      - name: dummy_module_employee_level
        description: Dummy employee module table containing test access data.
        config:
          freshness:
            warn_after:
              period: hour
              count: 24

      - name: dummy_payments_bridge_users
        description: >
          Dummy team collection containing fake company activation data
          for bridge integration testing.
        config:
          freshness:
            warn_after:
              period: hour
              count: 24

      - name: dummy_tickings
        description: Dummy ticking feature adoption data.
        config:
          freshness:
            warn_after:
              period: hour
              count: 24

      - name: dummy_roles
        config:
          freshness:
            warn_after:
              period: hour
              count: 24

      - name: dummy_collaborator_role
        config:
          freshness:
            warn_after:
              period: hour
              count: 24

The key points: • The

meta.channel

is moved to the source level so it still applies to all alerts across all tables. [Alert properties] • The

freshness

config is defined per table, so you can simply omit it for

dummy_advance_payments

. • Table-level freshness config takes precedence over source-level config. [dbt sources table freshness] This is the cleanest supported approach given that there is no native "exclude table" option for source-level freshness in dbt or Elementary. 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.

24 Views

Open in Slack

Previous Next