@kapa.ai We have a dbt monorepo where we have many individual DBT projects that are all imported into one main project. Each sub-project is executed on it's own schedule and runs it's own tests. We want to avoid having a dashboard per subproject, but I am unsure how to organize one "main" report effectively with many sub-projects. What are some recommended approaches?

Great question — this is a common challenge with monorepo / multi-project dbt setups. Here's a summary of the approaches that have been discussed in the Elementary community, from most to least recommended: 1. Elementary Cloud: Multi-Project Environment (Recommended) Elementary Cloud now natively supports connecting multiple dbt projects into a single environment, giving you a unified view of lineage, data health, and test results without changing your dbt structure. Each sub-project keeps its own Elementary schema, and Elementary handles the unification at the environment level. [Multi-env docs] Key capabilities include: • Unified lineage across projects — assets are identified by their full relation name • No changes to your dbt structure — each project keeps its own models, sources, and Elementary schema • Automatic linking between sources in one project and models in another This is the cleanest solution if you're open to using Elementary Cloud. [Multi-env docs] 2. OSS: "Umbrella" Project with Unioned Views A community-validated workaround for Elementary OSS is to create a dedicated umbrella dbt project that contains only views, each of which unions the corresponding Elementary schema tables from all your sub-projects using

dbt_utils.union_relations

. You then point

edr report

at this umbrella schema. > _"I've managed to setup an

elementary-umbrella

dbt project which contains only views which actually are union from source dbt-elementary projects models. Using

dbt_utils.union_relations

macro it was quite easy to do. Thanks to such approach I can now generate 1 elementary report which covers all my dbt projects on 1 web page."_ [Community thread] Practical considerations for this approach: • You must maintain uniform versions of Elementary across all sub-projects • Add project/scope-specific tags to each sub-project so you can filter by them in the report • Add owner metadata to aid navigation • Lineage across bespoke projects can be clunky without good tag/owner filters • Works well for small teams (~3 people, ~5 projects), but can become cumbersome at larger scale [Slack thread] 3. OSS: Wrapper/Parent Project (Packages Approach) Another approach that has worked for some teams is creating a parent dbt project that lists all sub-projects as packages. Running Elementary from this parent project includes all sub-projects and produces a single report. This also has the benefit of unifying

dbt docs

. [Slack thread] > "What we ended up doing was creating a project that had the other 2 projects listed as packages and then we ran Elementary from there. That way both projects get included... Yes, it works great!" Summary Table One important caveat for OSS: Elementary OSS is fundamentally designed around one report per dbt project. The OSS workarounds above are community-driven and not officially supported — Elementary's own support staff have noted that no fully successful multi-project OSS setup has been confirmed yet. [Slack thread] If a unified dashboard is a core requirement, Elementary Cloud's multi-project support is the most reliable path. 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements