The

anomaly_sensitivity

parameter in Elementary's

volume_anomalies

test determines how wide the expected range is for what is considered "normal" row count behavior. Specifically, it sets the number of standard deviations (Z-score) from the mean of the training data that a new value must exceed to be flagged as an anomaly. - How it works: - A sensitivity of 3 means the expected range is within 3 standard deviations from the average of the training set. This is the default. - Lowering the sensitivity (e.g., to 2) makes the test more sensitive, so smaller deviations from the mean will be flagged as anomalies. - Increasing the sensitivity (e.g., to 4) makes the test less sensitive, so only larger deviations will be flagged. Calculation: Elementary uses the standard score (Z-score) method for anomaly detection. For each time bucket (e.g., daily row count), it calculates the mean and standard deviation of the row counts in the training period. The anomaly sensitivity sets the Z-score threshold:

expected_range = [mean - (anomaly_sensitivity * stddev), mean + (anomaly_sensitivity * stddev)]

If the observed value falls outside this range, it is flagged as an anomaly. For example, with the default sensitivity of 3, only values more than 3 standard deviations away from the mean are considered anomalous, which aligns with the empirical rule for normal distributions ([~99.7% of values fall within 3 standard deviations](https://docs.elementary-data.com/data-tests/data-anomaly-detection)). You can configure

anomaly_sensitivity

directly in your test configuration:

yaml models:   - name: this_is_a_model     tests:       - elementary.volume_anomalies:           anomaly_sensitivity: 2.5

Smaller values increase sensitivity (more anomalies), larger values decrease it (fewer anomalies) [see documentation](https://docs.elementary-data.com/data-tests/anomaly-detection-configuration/anomaly-sensitivity). For more details on the underlying method, see the [anomaly detection method documentation](https://docs.elementary-data.com/data-tests/data-anomaly-detection).

Based on the knowledge sources, there is currently no explicit configuration in Elementary OSS or Cloud to send a summary message to Microsoft Teams containing total tests done, total successes, total failures, etc., in the same way the dashboard displays these metrics. Elementary does support grouping test alerts by table, which reduces the number of messages by combining all issues for a table into a single alert, but this does not provide a dashboard-style summary with overall totals. The grouping feature is configured with the

--group-by table

flag for the CLI, but it still focuses on test failures and issues, not overall test statistics or a dashboard snapshot [see release notes](https://docs.elementary-data.com/oss/release-notes/releases/0.7.5), [alerts configuration](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alerts-cli-flags). For Slack, there is a feature to send a summary or snapshot of the report, but this is not documented for Teams. In Teams, alerts are sent as Adaptive Cards for each issue or grouped by table, but not as a single dashboard summary message [Teams integration docs](https://docs.elementary-data.com/oss/guides/alerts/send-teams-alerts). If you need a single summary message with overall test statistics sent to Teams, this is not natively supported according to the current documentation and available features. If you have further needs, you may consider submitting a feature request to the Elementary team.

If

dbt run -s elementary

is not working after upgrading to a new version, there are a few common causes and troubleshooting steps based on the knowledge sources: 1. Version Compatibility Ensure that both the Elementary dbt package (in your

packages.yml

) and the Elementary CLI are upgraded to compatible versions. Incompatibility between the CLI and dbt package is a frequent cause of errors. After upgrading, always run:

dbt deps    dbt run -s elementary

If you see warnings about incompatible versions, update both and rerun the commands [see here](https://slack.com/archives/C02CTC89LAX/p1698373085921559), [here](https://slack.com/archives/C02CTC89LAX/p1669374086647569), and [here](https://docs.elementary-data.com/oss/release-notes/upgrading-elementary). 2. Target Configuration Make sure you are running the command on the correct dbt target where Elementary is enabled. If you have multiple targets, specify the correct one:

dbt run -s elementary --target=your_target

Running on a target where Elementary is disabled will result in "Nothing to do" errors [see here](https://slack.com/archives/C02CTC89LAX/p1687776269471449). 3. Full Refresh or Rebuilding Views If you encounter errors related to schema changes (e.g., column mismatch, view errors), you may need to manually delete problematic views/tables or run a full refresh:

dbt run -s elementary --full-refresh

This is especially important after upgrading across minor or major versions [see here](https://slack.com/archives/C02CTC89LAX/p1706098623244639). 4. Order of Operations Always run

dbt deps

before

dbt run -s elementary

after changing package versions. Running these in different terminals or with different targets can cause issues [see here](https://slack.com/archives/C02CTC89LAX/p1680277889043609). 5. Error Messages If you receive a specific error message, check the logs (

edr.log

or dbt logs) for more details. Common issues include missing macros, incompatible dbt versions, or database errors due to schema changes. If you have followed these steps and are still experiencing issues, please provide the specific error message for more targeted troubleshooting.

The anomaly score in Elementary is calculated using the standard score, also known as the Z-score. This score measures how many standard deviations a value is from the mean of a set of historical values (the training set). Calculation steps: 1. Collect historical data: For each metric (e.g., row count), Elementary collects values over a defined training period. 2. Compute mean and standard deviation: It calculates the average (mean) and standard deviation of the metric values in the training set. 3. Calculate the anomaly score: For a new value (from the detection period), the anomaly score is calculated as:

anomaly_score = (value - mean) / standard_deviation

This tells you how far (in standard deviations) the new value is from the historical average. 4. Flagging anomalies: By default, if the absolute value of the anomaly score is greater than 3 (|anomaly_score| > 3), the value is considered an anomaly. This threshold can be adjusted using the

anomaly_sensitivity

configuration [Data anomaly detection method](https://docs.elementary-data.com/data-tests/data-anomaly-detection), [anomaly_sensitivity](https://docs.elementary-data.com/data-tests/anomaly-detection-configuration/anomaly-sensitivity). This approach is based on the empirical rule for normal distributions, where about 99.7% of values are expected to fall within 3 standard deviations of the mean. Values outside this range are flagged as potential anomalies. For more details, see the official documentation on [how anomaly detection works](https://docs.elementary-data.com/data-tests/how-anomaly-detection-works) and the [data anomaly detection method](https://docs.elementary-data.com/data-tests/data-anomaly-detection).

To access

elementary_test_results

via

ref()

in your dbt models without enabling the full Elementary package (and thus avoiding the hooks and data uploads), the recommended approach is: 1. Enable Only the Required Elementary Models: You can selectively enable just the

elementary_test_results

model while keeping the rest of the Elementary package disabled. In your

dbt_project.yml

, you can do something like:

yaml    models:      elementary:        +enabled: false        edr:          elementary_test_results:            +enabled: true

If the above does not work due to model pathing, you may need to specify the full path to the model within the Elementary package. 2. Alternative: Build Only the Required Model Another approach is to keep Elementary disabled by default and explicitly run only the required model when needed:

bash    dbt run --select elementary.edr.elementary_test_results

This ensures the model exists for your

ref()

calls, but the rest of the package and hooks remain inactive. 3. Caveat: If you have Elementary-specific tests in your

.yml

files, disabling the package may cause those tests to fail to compile or run, as noted in community discussions. In such cases, you may need to stub out the required tables or ensure the minimal set of Elementary models are built in your environment [see discussion](https://slack.com/archives/C02CTC89LAX/p1692696677104579). 4. Disabling Hooks: If you want to further ensure that no hooks are triggered, set the disabling variables in your `dbt_project.yml`:

yaml    vars:      disable_run_results: true      disable_tests_results: true      disable_dbt_artifacts_autoupload: true      disable_dbt_invocation_autoupload: true

This will prevent the hooks from uploading data even if some Elementary models are enabled [see documentation](https://docs.elementary-data.com/dbt/on-run-end_hooks#can-i-disable-the-on-run-end-hooks%3F). Summary: Enable only the specific Elementary model(s) you need, and use the disabling vars to prevent hooks from running. This allows you to use

ref('elementary_test_results')

without triggering the full Elementary workflow or data uploads. If you encounter issues with model pathing or compilation, you may need to experiment with the exact model path or consider running

dbt run -s elementary

once to create the necessary tables, as suggested in community threads.

I'm sorry, but the knowledge sources do not contain enough information to confirm that Elementary provides a built-in feature to check how many users have queried a specific table. While Elementary does collect some query logs and metadata (such as the user performing the query) for tracking usage and troubleshooting purposes, there is no explicit documentation or example showing a report or metric that aggregates the number of unique users querying a particular table [What information does Elementary collect?](https://docs.elementary-data.com/cloud/general/security-and-privacy#what-information-does-elementary-collect?). If you need this functionality, you may need to rely on your data warehouse's native query logging or audit features, or consider reaching out to the Elementary team for more details on advanced usage tracking capabilities.