> ## Documentation Index
> Fetch the complete documentation index at: https://elementary-devin-1782754750-bigquery-permissions-docs.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# FAQ

> This section is aimed at collecting common questions users have to provide documented answers.

<Accordion title="Can I disable the `on-run-end` hooks or results uploading?">
  You can use the disablement vars or disable the entire package in your `dbt_project.yml`.
  It's possible to configure to disable with a condition like specific env.

  Here are examples:

  Disable specific hooks (the recommended method) -

  ```yaml dbt_project.yml theme={null}
  vars:
    disable_run_results: "{{ target.name not in ['prod','analytics'] }}"
    disable_tests_results: "{{ target.name != 'prod' }}"
    disable_dbt_artifacts_autoupload: "{{ target.name != 'prod' }}"
    disable_dbt_invocation_autoupload: "{{ target.name != 'prod' }}"
  ```

  Disable the whole package (Elementary tests won't work) -

  ```yaml dbt_project.yml theme={null}
  models:
    elementary:
      +schema: "elementary"
      +enabled: "{{ target.name in ['prod','analytics'] }}"
  ```
</Accordion>

<Accordion title="Can I select / exclude elementary tests only?">
  Sure! All you have to do is use the 'elementary-tests' tag in your dbt run command. Here's an example:

  ```shell theme={null}
  dbt test --select tag:elementary-tests
  ```
</Accordion>

<Accordion title="Can I disable / exclude the Elementary models?">
  Elementary only needs you to run the models once after you install, and on upgrades of minor versions (like 0.15.X -> 0.16.X).
  On such upgrades we make schema changes, so we need you to rebuild the tables.

  For excluding the elementary models from your runs we suggest 2 options:

  1. Use the selector `--exclude elementary` when you run `dbt run`.
  2. Set a var that disables the models by default. On version upgrades you could pass it as true.

  Here is how you implement option 2:

  * on your `dbt_project.yml` add:

  ```yaml dbt_project.yml theme={null}
  models:
    elementary:
      +schema: elementary
      edr:
        +enabled: "{{ var('enable_elementary_models', false) }}"
  ```

  You will run the Elementary models explicitly in one of two cases:

  1. When you upgrade elementary run
  2. If you choose to disable Elementary models from your runs and want to update them at your own time.

  To run Elementary models:

  ```shell theme={null}
  dbt run --select elementary --vars '{"enable_elementary_models": true}'
  ```
</Accordion>

<Accordion title="Can I change the Elementary schema?">
  The short answer is yes.
  We recommend that Elementary models will have their own schema, but it is not mandatory.
  You can change the schema name by using dbt [custom schema configuration](https://docs.getdbt.com/docs/building-a-dbt-project/building-models/using-custom-schemas) on your `dbt_project.yml`.
  In short, the default dbt `generate_schema_name` macro concatenate the value provided in `schema` configuration key to the target schema, as in: `target_schema_custom_schema`.

  If you want a different behaviour, like configuring a full name for the Elementary schema, you can override the default `generate_schema_name` macro with your logic.
  Before you do that, make sure that there isn't already a macro named `generate_schema_name.sql` in your project.

  Here is a macro you can use that would search for a config under `meta` named `schema_name`.
  If it exists, that would be the schema name. If not - the original dbt logic would be followed:

  ```sql generate_schema_name.sql theme={null}
  {% macro generate_schema_name(custom_schema_name, node) -%}

      {%- set default_schema = target.schema -%}
      {% set config_meta = node.config.get('meta') %}

      {% if config_meta and config_meta is mapping %}
          {% set schema_name = config_meta.get('schema_name') %}
          {% if schema_name and schema_name is string %}
              {{ return(schema_name) }}
          {% endif %}

      {%- elif custom_schema_name is none -%}

          {{ default_schema }}

      {%- else -%}

          {{ default_schema }}_{{ custom_schema_name | trim }}

      {%- endif -%}

  {%- endmacro %}
  ```

  If you implement this macro and want to name the Elementary schema `elementary_data_observability`:

  ```yml dbt_project.yml theme={null}
  models:
    elementary:
      +meta:
        schema_name: "elementary_data_observability"
  ```
</Accordion>

<Accordion title="What is the Elementary schema?">
  The Elementary package creates various models to store information about collected dbt artifacts and test results.

  To avoid mixing with your existing models, we recommend configuring a dedicated schema for the Elementary models using
  the [dbt custom schema](https://docs.getdbt.com/docs/building-a-dbt-project/building-models/using-custom-schemas)
  option.
  Here is an example configuration, that creates a schema with the suffix '\_elementary' for elementary models:

  ```yml dbt_project.yml theme={null}
  models:
    elementary:
      +schema: elementary
  ```
</Accordion>

<Accordion title="Which tests can I see on Elementary report?">
  All your dbt tests - the built-in dbt tests, Elementary tests, custom tests and any other package tests (such as dbt\_utils or dbt\_expectations).
</Accordion>

<Accordion title="Elementary supports custom tests / singular tests? How can I add configuration to custom tests?">
  Custom / Singular tests are supported by Elementary.

  * Alerts: Full support.
  * Report: Only tests that `ref` one model are presented in the report under the relevant model.

  You can add configuration to your custom tests with a config block:

  ```sql custom_test.sql theme={null}
  {{ config(
      tags=["Tag1","Tag2"]
      meta={
          "description": "This is a description",
          "owner": "Maayan Salom"
      }
  ) }}

  <test query here>

  ```
</Accordion>

<Accordion title="How to run full-refresh / truncate Elementary's incremental models?">
  Elementary’s incremental models aren’t truncated by the standard full refresh flag. This is because generally you wouldn’t want those models to truncate

  To run full-refresh, use the `elementary_full_refresh` var like this:

  ```shell theme={null}
  dbt run --select elementary --vars '{"elementary_full_refresh": "true"}
  ```
</Accordion>

<Accordion title="What permissions Elementary requires?">
  The CLI needs to have permissions to access the `profiles.yml` file with the relevant profile, write files to disk,
  and network access to the data warehouse.

  Also, in the `elementary` profile, the credentials should have permissions to read and write the elementary schema, and execute queries.
</Accordion>

<Accordion title="Can I use Elementary with dbt cloud?">
  Yes! All the functionality is available and supported for dbt cloud users as well.
</Accordion>

<Accordion title="Can I control the test result samples?">
  Yes! Elementary saves samples of failed test rows and stores them in the table `test_result_rows`, then displays them in the *Results* tab of the report.

  By default, Elementary saves **5 rows per test**, but you have several options to control this:

  * **Change the sample size** globally or per-test using `test_sample_row_count`
  * **Disable samples** for specific tests using `disable_test_samples` in the test meta
  * **Protect PII** by automatically disabling samples for tables tagged with sensitive data tags
  * **Elementary Cloud users** can also request environment-level controls from the Elementary team

  For example, to save 10 rows per test, add the following to your `dbt_project.yml` file:

  ```yaml theme={null}
  vars:
    test_sample_row_count: 10
  ```

  To disable samples entirely, set it to `0`:

  ```yaml theme={null}
  vars:
    test_sample_row_count: 0
  ```

  For the full list of controls including per-test overrides, PII protection, and Cloud options, see [Test Result Samples](/data-tests/test-result-samples).
</Accordion>

<Accordion title="Is Elementary free? Does Elementary cost money?">
  Elementary dbt package and CLI are free. Everything that is open source is 100% free and will remain free!
  Elementary Cloud is a paid SaaS offering, with premium features and integrations.
  However, we are committed to building a great OSS product first.

  Checkout [Elementary Cloud pricing](https://www.elementary-data.com/pricing).
</Accordion>

<Accordion title="My question is not listed here">
  You can join our [Slack](https://elementary-data.com/community) and search our #support channel, and of course ask us - we are very responsive!

  You could also open a [GitHub issue](https://github.com/elementary-data/elementary/issues/new) using the template `Documentation gap`, and we could add the missing question (and answer) to the docs.
</Accordion>