Cross-Tenant Assessments#

This feature is disabled by default

Cross-tenant assessments must be explicitly enabled and should be rolled out carefully — once enabled, users will see more assessment records, which can affect existing dashboards and aggregations. Get partner sign-off before turning it on. See dbt Variables for configuration details.

Students move. A third grader tested at one district shows up as a fifth grader at another. When that happens, the receiving district has no visibility into that student's prior assessment history — even though that history exists in the warehouse, just under a different tenant.

The cross-tenant assessments feature is designed to close that gap. When enabled, the warehouse surfaces a student's complete assessment history to every tenant where that student has an active enrollment — regardless of which tenant originally collected the data. This gives the active tenant a full view of student performance across all organizations, not just their own.

What is a tenant?

In most cases, 'tenant' refers to the 'LEA'/'school district' to whom the data belongs. For more info on how this is represented in the warehouse, see Tenant codes in the Table Structure guide.

Two terms used throughout this article: - Active tenant — the tenant where the student currently has an active enrollment - Source tenant — the tenant that originally administered and collected the assessment

In practice, this means assessment records are duplicated across tenants. The surrogate keys (e.g., k_assessment) that make up the grain of the affected tables are scoped to the active tenant, not the source tenant. Therefore, this is not a breaking change to the grain of any tables. But your downstream metrics and dashboards will surface more results to users, so it's important to get partner approval before enabling.

Two years ago                              Today
────────────────────────────────────────────────────────────────
Student enrolled at District A             Student enrolled at District B
District A administers assessments         (active tenant)
→ assessment records created                    │
  (source tenant = District A)                  │
        │                                       ▼
        └───────────────────────────→  District B can now see
                                       District A's assessment records
                                       attributed to District B

The same assessment event produces two rows in fct_student_assessment — one per tenant. The natural key fields (student, assessment) are identical; only the surrogate keys and tenant columns differ:

k_student_assessment	k_assessment	tenant_code	student_unique_id	assessment_identifier	administration_date	scale_score	is_original_record	original_tenant_code
`a1b2c3...`	`f6g7h8...`	district_a	STU-0042	SAT	2023-10-15	1200	`true`	district_a
`x9y8z7...`	`p2q3r4...`	district_b	STU-0042	SAT	2023-10-15	1200	`false`	district_a

When does a record get copied?#

A student's assessment records are copied to the active tenant when: - The student has an active school enrollment at the active tenant - The active tenant is different from the source tenant - The student can be matched across tenants by student_unique_id

Identity validation is applied to guard against false matches where two different students share a student_unique_id across tenants.

Which tables are affected?#

Table	What's added
`fct_student_assessment`	One additional row per assessment per additional tenant the student is enrolled in
`fct_student_objective_assessment`	Same, for each objective/sub-assessment result
`dim_assessment`	One additional row per assessment per tenant where a cross-tenant student has taken it
`dim_objective_assessment`	Same, for each objective assessment

How to tell original from copied records#

Every row in fct_student_assessment and fct_student_objective_assessment carries two columns:

is_original_record — true if tenant_code is the source tenant (the one that administered the assessment); false if it is an active-tenant copy
original_tenant_code — the source tenant that originally collected the data

The score values, dates, and all other assessment data are identical between the original and its copies.

The main thing to watch out for: double-counting#

If you query fct_student_assessment across multiple tenants without filtering, a student enrolled in two tenants will appear twice for the same assessment — once per tenant. Any count or aggregation that should reflect unique assessment events needs a filter:

-- count unique assessment events, not tenant copies
where is_original_record = true

If you're already scoping a query to a single tenant, this is not an issue — you'll see original records for students whose data lives in that tenant, plus copies for students whose data lives elsewhere.

Joining dim tables#

dim_assessment and dim_objective_assessment also contain one row per tenant. When joining from a fact table, the surrogate keys (k_assessment, k_objective_assessment) are already tenant-scoped, so joins work correctly without any additional filtering.