New message text here

@kapa.ai Follow-up: Is it possible for elementary to notify should there be new tables added to source?

Yes, Elementary Cloud can automatically detect new source tables. The platform monitors your data warehouse's information schema and query history to identify tables, including new ones. By default, automated monitors are activated on tables included in your dbt project (sources and models), and Elementary can also support non-dbt tables. This means that if a new table is added as a source in your dbt project, Elementary will detect it and can begin monitoring it for freshness, volume, and schema changes. However, while Elementary can detect new tables, the knowledge sources do not explicitly state that it will send a notification or alert specifically when a new table is added. Automated monitors are created for new tables, but alerts are typically triggered by data issues (such as freshness or volume anomalies), not simply by the presence of a new table. If you need an alert specifically for the creation of a new table, this may require additional configuration or a feature request. For more details, see the discussion confirming automatic detection of new source tables and how Elementary monitors them: [Slack discussion on automated detection](https://slack.com/archives/C02CTC89LAX/p1716464124470759), [Automated monitors documentation](https://docs.elementary-data.com/features/anomaly-detection/automated-monitors).

New message text here

When you run a schema changes test (such as

elementary.schema_changes

or

elementary.schema_changes_from_baseline

) on a table that has been deleted, it can indeed result in a database error. This is because the test attempts to query the table's schema, and if the table no longer exists, the underlying SQL will fail—often with a syntax or "object does not exist" error, as you observed. This behavior is confirmed in community discussions, where users encountered similar errors when running Elementary tests on deleted tables. The recommended approach in such cases is to ensure that tests are not run on tables that have been dropped, or to clean up any pending alerts or test configurations referencing those tables. For example, you can mark the relevant alerts as sent in the

alerts

table by filtering on the

table_name

and setting the

alert_sent

column to

true

 [Slack discussion on deleted tables and errors](https://slack.com/archives/C02CTC89LAX/p1662029029665899). Additionally, recent updates to Elementary aim to provide more indicative error messages when a tested table or column does not exist in the warehouse, but the fundamental limitation remains: if the table is gone, the test will error out [Slack discussion on error handling for deleted tables](https://slack.com/archives/C02CTC89LAX/p1668099874659909). In summary: Yes, running schema change tests on deleted tables will result in errors, and this is expected behavior. You should remove or update tests and alerts that reference tables which no longer exist.

You raise a valid point—ideally, a schema test should notify you if the table being tested has been deleted, as this is a critical schema change. According to the knowledge sources, when a schema changes test is run on a deleted table, it currently results in a database error rather than a clear notification or alert about the table's deletion. This behavior has been observed and discussed in the community, and there is recognition that a more informative message or alert would be helpful. Recent updates to Elementary have aimed to provide more indicative error messages when a tested table or column does not exist, but the fundamental behavior is still that an error occurs, not a structured alert or notification about the deletion itself. The current workaround is to manually clean up test configurations or alerts referencing deleted tables [Slack discussion on error handling for deleted tables](https://slack.com/archives/C02CTC89LAX/p1668099874659909). In summary: While the schema test does error out if a table is deleted, it does not currently provide a dedicated notification or alert for table deletion. This is a known limitation, and improvements have been discussed in the community, but as of now, you will see an error rather than a clear notification.

Schema tests in Elementary are a set of dbt-based tests that validate the structure of your data tables—specifically, they check for changes such as added or removed columns, changes in column data types, and overall consistency with an expected schema. Elementary provides several schema validation tests, including: - Schema changes: Fails if columns are added, removed, or their data types change. - Schema changes from baseline: Fails if the table schema differs from a predefined baseline (which can be auto-generated). - JSON schema: Validates that JSON columns conform to a specified schema. - Exposure schema: Ensures that changes in your models’ columns do not break downstream consumers, such as BI dashboards [Schema Validation Tests](https://docs.elementary-data.com/features/data-tests/schema-validation-test). ### Why are schema tests useful, especially for source data? Schema tests are particularly valuable for source data because they help you: - Detect breaking changes early: If a source system changes its schema (e.g., adds or removes columns), this can break downstream data models and analytics. Schema tests catch these changes as soon as the data lands in your warehouse. - Enforce data contracts: By validating that source tables match an expected schema, you ensure that your data pipeline is built on a reliable and predictable foundation. - Prevent silent failures: Without schema tests, changes in source data structure might go unnoticed until they cause errors or incorrect results further downstream. - Monitor for unexpected changes: Automated schema tests can alert you to changes in the source data structure, allowing you to respond quickly and maintain data quality [Best practices: Common testing use cases](https://docs.elementary-data.com/best-practices/detection-and-coverage#common-testing-use-cases). In summary, schema tests are essential for maintaining the integrity of your data pipeline, especially at the source, where changes are most likely to propagate and cause issues throughout your analytics stack.