It sounds like permissions on Elementary’s relations are being reset when they’re rebuilt during dbt runs (e.g., on-run-end artifacts refresh), which matches issues others saw when artifact tables/views are recreated or updated by different users/roles. A few approaches from similar cases: - Ensure the correct schema/target is used by EDR so it doesn’t read from an unexpected schema without grants (verify the Elementary profile/target used by edr monitor) ([Databricks schema mismatch example](https://slack.com/archives/C02CTC89LAX/p1687777278488809)). - Avoid global materialization overrides that can change Elementary relations and trigger rebuild behavior; scope global configs to your own project and keep Elementary’s defaults (this prevents accidental view/table changes that can cause permissions issues) ([materialization overrides cause issues](https://slack.com/archives/C02CTC89LAX/p1723832490968039), [empty model_run_results due to override](https://slack.com/archives/C02CTC89LAX/p1693825818714329), [Spark truncate/view issue from override](https://slack.com/archives/C02CTC89LAX/p1676563091250799)). - If different users run different steps (e.g., seed vs. run) and artifacts get updated on on-run-end, consider disabling Elementary’s on-run-end for commands run by a user without ownership (e.g., disable during dbt seed) to avoid recreate/replace operations that drop grants ([disable Elementary on seed](https://slack.com/archives/C02CTC89LAX/p1682612682384909)). - If you changed schema/need a clean start, recreate Elementary in a new schema (or drop and rebuild) and then apply the grants policy you want; migrating or starting fresh can clear prior ownership/grant drift ([recreate/migrate schema guidance](https://slack.com/archives/C02CTC89LAX/p1681384521227129)). Given your error: - Confirm model_run_results is a view in the same schema EDR queries, and not inadvertently materialized as a table by a global override. - Apply grants via role-based default privileges or automation after rebuilds. If ownership flips between users, grants on “all tables/views” may not persist after replace operations run by another owner; disabling the on-run-end updates for the jobs run by the non-owner user can help, or run those jobs with a role that owns the Elementary schema/tables ([artifacts updated on on-run-end](https://slack.com/archives/C02CTC89LAX/p1682612682384909)). If you share which warehouse and how permissions/ownership are managed, I can suggest a tighter config (e.g., scoping project-level materializations, specific flags to disable Elementary for certain commands, or target setups).