The Shared entity Trap in Snowflake Medallion Architecture
A practical guide to reusing entities, relationships and facts across data products in Snowflake
The architectural dilemma usually appears when a cross-domain data product needs reusable business entities, governing relationships and domain facts that mature at different speeds. Customer context may be ready enough to reuse, while service history, sales activity, product usage, billing behavior, invoices, contracts, service cases, equipment context or financial exposure may still sit inside domain-specific pipelines. Waiting for every contributing business capability to complete its target model can block delivery; copying everything into a product schema can create another physical and semantic boundary by accident.
The trouble usually starts when teams decide where to put the combined data. Several different questions get collapsed into one: Which business entity should be reused? Which governing relationship needs agreed meaning? Which facts must stay with the business capability or domain that understands them? Who owns the definition of a metric such as churn risk or financial exposure? Where should the product-specific logic live? Who is allowed to consume the published result? When one schema is expected to answer all of these questions, it starts acting as a semantic boundary, deployment unit, ownership claim and security perimeter at the same time.
This article is for architects who already understand logical modelling but still have to make the harder implementation calls in Snowflake: what to reuse, what to keep domain-owned, what to publish through a governed Interface View or consumer Contract, what to materialise in the data product layer, and when a controlled physical copy is acceptable architecture debt rather than unmanaged clean-up work.
The cross-domain physicalisation dilemma
A cross-domain use case usually needs more than one category of data, and not all of them should be forced into one reusable abstraction:
- reusable business entities that may represent people, places, objects, events, agreements, transactions, activities or other business Concepts
- governing relationships that require agreed meaning, cardinality, lineage and usage rules
- Domain-owned facts such as transactions, events, observations or lifecycle changes
- Measures such as cost, revenue, margin, service effort or operational impact
- Derived metrics, indicators or decision signals created for the use case
- Product-specific transformations, snapshots or projections needed for consumption
Three common implementation choices appear reasonable:
1. Wait until every participating domain has created production-ready Silver entities.
2. Copy all required data into a dedicated schema so the use case can proceed independently.
3. Reuse what is ready, keep domain facts in place, and put product-specific logic in the product-facing layer.
None of these choices is wrong in isolation:
- Waiting for every domain protects the target architecture, but it can turn organisational dependencies into delivery blockers.
- Copying everything into a product-specific schema helps the team move fast, but it creates multiple versions of shared business entities, facts and metrics with different definitions, controls and refresh behaviour.
- Reusing what is ready, keeping domain facts in place and placing product-specific logic in the product layer is usually the practical default, provided the contracts, ownership gaps and access paths are explicit.
Separate the boundaries before deciding the schema
Before deciding where the data should physically live, separate the decisions teams often collapse into the schema name. business Capability, business Entity, governing relationship, ownership, consumer Contract, access and Physical Implementation are related decisions, but they should not be collapsed into the same Snowflake schema. Before deciding where data lives physically
- Business Outcome
- Business Process
- Business Capability
- Business Entity
- Governing Relationship
- Facts, Measures and Metrics
- Consumer Contract
- Physical Implementation and Access
These boundaries influence one another, but they do not require a one-to-one mapping. A business capability may provide a proposed ownership and semantic boundary, but it does not automatically determine the physical schema, consumer access model or data product boundary. A cross-domain data product may consume business entities, governing relationships, facts, events and measures from several capabilities without owning their underlying business meaning.
Why “one schema per domain” becomes fragile
A schema-per-domain convention can be useful for deployment, discoverability and coarse-grained privilege management. The problem starts when that convention is treated as a fixed mapping from business ownership to physical design. The issue is not that different domains own different data but when storage location becomes the access model and every consuming product starts making local copies because governed consumption paths are missing.
A reuse-first physicalization pattern
A reuse-first pattern does not mean every useful dataset becomes shared infrastructure. It means each dataset has a clear job: reusable entity, domain-owned fact, governed metric, product-specific derivation or controlled copy.
1. Reusable business entities and governing relationships
Depending on the business capability and business process, reusable business entities may represent people, places, objects, events, agreements, transactions, activities or other business Concepts required by multiple data products. governing relationships may also need to be defined and reused with their meaning, cardinality, lineage and usage rules intact.
Reusable does not mean authoritative for every purpose as business entity may coexist with operational sources, formally mastered identities, capability-specific interpretations and data product projections. A source-authoritative attribute, mastered identity, reusable analytical representation and product-specific projection may each be valid for different purposes, provided the distinction is explicit and not hidden behind one schema name.
Medallion layers do not decide ownership by themselves
Bronze, Silver and Gold describe transformation maturity and consumption intent. They do not, by themselves, determine business ownership, business capability boundaries, enterprise reuse, physical schema placement or access boundaries. Silver may contain reusable business entities and governing relationships where grain, business key, lineage, ownership, history treatment and consumer contract are explicit. Domain or capability-owned facts and events may also be curated for controlled reuse when their meaning and contract are clear. Gold data products compose approved inputs for analytical, reporting, operational or AI consumption, but should not silently redefine reusable business meaning, relationships or history.
“Shared” is not a mandatory fourth medallion layer. A Silver object is not automatically enterprise-shared, and a Gold object is not automatically owned by one business capability or domain. Physical placement should follow grain, Business Meaning, ownership, lifecycle and access decisions rather than the layer name alone. The focus is intentionally on physicalization decisions rather than providing a complete modelling approach for the Silver layer.
Contextual domain or process layer
Keep context-specific events and relationships close to the processes that create meaning. Opportunities, service cases, campaign responses, invoices, maintenance events or usage measures may remain in their respective subject areas. They do not need to be copied into a single product schema merely because one data product joins them.
Product or publication layer
Expose the curated shape required by the data product through versioned interface views and consumer contracts. A consumer contract should state the object or interface being consumed, grain, approved columns, semantics, freshness expectations, change and versioning rules, and permitted consumer access . These interfaces may be standard views, secure views or materialized product tables depending on privacy, performance, latency and lifecycle requirements. The product consumes the contract, not the internal storage design.
If an interface view and role mapping can satisfy the consumer, create the interface first. Create another physical copy only when performance, isolation, audit or delivery risk makes that trade-off explicit, with a named reason, owner, reconciliation rule and lifecycle.
Reuse can make RBAC feel harder when roles are created separately for every user, table and project. But the harder path is uncontrolled grantsand missing interfaces. A schema name does not prove business ownership, and access problems should not automatically be solved through copying. Snowflake separates securable objects, privileges, roles and users, and roles can be arranged in a hierarchy. That means object access can be packaged into reusable access roles and inherited by functional roles instead of being granted directly to individuals.
The practical access pattern is to separate users and personas from object privileges:
- ownership roles control object ownership and administrative change; access roles package read or usage privileges for controlled objects.
- Account roles and database roles should be used deliberately where relevant, rather than treating every role as the same kind of entitlement.
- Functional or application roles represent a job function, workload or service identity and inherit the required object-access roles.
- Users and service identities receive functional roles through the organisation’s identity-management process rather than direct grants.
- USAGE on databases and schemas makes namespaces visible; SELECT on tables or views controls read access to data.
- Masking policies protect sensitive column values based on defined conditions; row access policies control row visibility based on defined conditions.
- Tags support classification and may support policy-based governance where the relevant Snowflake feature, edition and availability have been validated. Verify current feature availability and edition requirements in the Snowflake documentation before implementation.
- Published views provide a consumer interface without exposing implementation tables unnecessarily.
Under this pattern, a data product does not require a single role with unrestricted access to every participating schema. It requires a product-specific functional role that inherits only the approved interface views or consumer contracts. RBAC Complexity comes from uncontrolled direct grants, unclear personas, inconsistent role granularity and failure to distinguish base-table access from published-interface access .
Get Anupama Gangadhar’s stories in your inbox
Join Medium for free to get updates from this writer.
Use secure views deliberately as they are not required for every publication interface. Secure views are required when privacy or structural protection makes them necessary and standard views when the main need is abstraction and convenience. Reusable entities and materialised product projections should remain separate design choices.
A concrete illustration using Customer 360 and churn
The example below is deliberately limited. It shows the physicalization pattern rather than a complete logical model, naming standard or master-data design.
Customer is useful because it illustrates identity, relationship and temporal conflicts, but Customer 360 is not only a Customer or MDM problem. A business process or cross-domain data product may consume reusable business entities such as customer, contract, invoice, service case and equipment; governing relationships such as customer-to-contract or equipment-to-location; transactional facts, business events, measures, metrics, features and decision signals from several business capabilities. Consuming those inputs does not transfer ownership of their business meaning to the data product.
Different processes may still carry legitimate but different representations. Sales may treat an account as the customer. Finance may distinguish sold-to, bill-to and payer parties. Service may operate around installed assets and service locations. Marketing consent may be purpose-, channel- or jurisdiction-specific. Some records may not yet have a trusted enterprise identifier. Historical invoices may need to retain the customer interpretation valid when they were posted, while a churn product may require a current consolidated identity. These representations should not be forced into one undifferentiated Customer table merely because the product is called Customer 360.
The design decision is which identity and relationship elements are reusable, which process facts remain domain-owned, which current-state projection belongs to Customer 360, which historical interpretation must remain reproducible, which product features and decision signals remain product-owned, and which component, if any, is authoritative for a specific purpose.
- reusable customer, product, contract, equipment or similar business entities hold approved grain, business key, lineage and usage rules where those are ready for reuse.
- Sales activity, service case history, invoice behavior, product usage and relevant business events retain their process context unless they have an explicit consumer contract for reuse.
- Customer 360 interface views expose only the approved fields, relationships, measures and semantics required by the product.
- A functional role created inherits read access to publication interfaces, not unrestricted access to all underlying schemas.
- Sensitive fields are protected through approved masking or row-access policies where needed.
- Product-specific aggregates, churn scores, financial-impact features, customer-health signals and intervention rules remain in the data productlayer rather than being pushed back into a reusable business Entity.
Temporal interpretation must be explicit
The physical model must distinguish current-state entity representation from historical entity state. Effective-dated relationships, late-arriving corrections and reproducibility of previously issued outputs change how facts join to entities. The architectural test should be whether a fact joins to the current entity or to the entity state valid at the fact’s business date. Churn analysis, financial reporting and operational lookup may require different temporal interpretations of the same business entity, so SCD Type 2 should be a deliberate method, not a universal answer.
Metrics, features and decision rules need separate ownership
As an illustration, invoice amount may be a finance-owned base measure, revenue at risk may be a governed cross-domain metric, churn probability may be a model output, and an intervention flag may be a product decision rule. This is not a universal ownership assignment. The point is that base measures, governed metrics, model features, model outputs and product thresholds should not automatically share the same owner, lifecycle, approval process or physical location.
This design lets the data product move forward without requiring every participating team to complete its whole domain model first. The release only needs the contracts, facts, attributes and measures required for the current product increment. Those contracts can expand through governed versioning as new use cases arrive.
When a physical copy is justified
A strict never duplicate rule is as impractical as copying everything. Duplication can be justified, but the reason must be explicit and the copy must have a lifecycle.
- Performance or workload isolation requires a product-optimised structure that cannot be delivered adequately through a view.
- Regulatory or contractual isolation requires a separately controlled data set.
- A point-in-time snapshot is part of the product’s audit or reproducibility requirement.
- The source contract is not yet reliable enough for the delivery deadline, and a temporary copy is formally accepted as architecture debt.
- Semantics are intentionally different because the product represents a projection, not another authoritative version of the entity.
Every approved copy should record its source, purpose, owner, refresh mechanism, permitted divergence, reconciliation rule and retirement or review condition. Without these controls, temporary copies become permanent and competing definitions proliferate.
Where this pattern can fail
- No trusted or reconcilable business key exists, but the business entity is still published as reusable.
- The grain is unstable or undocumented, so consumers join at different levels of meaning.
- Temporal interpretations are incompatible across reporting, operational lookup and analytical features.
- Publication views conceal conflicting transformation logic instead of resolving or exposing it.
- Reusable business entities have no accountable owner for semantic change.
- Product projections are presented as enterprise masters.
- Direct grants bypass the approved role hierarchy.
- Policy design cannot be operated consistently across teams and environments.
- Copies are created without reconciliation and retirement conditions.
- Contracts exist in documentation but are not enforced through delivery and change processes.
A decision framework for Architects
Before physicalizing a cross-domain data product, answer the following practical architecture questions:
1. Which business outcome and business process are being supported, and which business capabilities contribute meaning, facts, measures or controls?
2. Which business entities, governing relationships, facts, events, measures, metrics and product-specific derivations are required by this increment? record the required artefacts, grain and business key where relevant.
3. For each required dataset, does a trusted version already exist, and is its consumer Contract fit for this use case? record the business meaning, semantic owner, history treatment and approved interface view.
4. Who is accountable for changes to entity definitions, governing relationships, fact logic, metric formulas and data-quality rules? Name the owner or record the ownership gap as architecture debt.
5. Can the use case consume a governed interface view or consumer contract instead of receiving base-table access ? record the interface and access -role mapping.
6. Which fields or rows require policy-driven protection? record classification, masking-policy and row-access -policy decisions.
7. If a copy is created, who will reconcile it and under what condition will it be retired or formalized? record source, owner, reconciliation rule and retirement condition.
8. Can the release proceed with a clearly documented ownership gap rather than waiting for an enterprise-wide operating model? record the gap, risk, compensating control and trigger for review.
These questions prevent the physical-schema decision from dominating the modelling discussion too early. They keep governance actionable: approve the minimum business Meaning, boundaries, contracts and controls required for the current release, then change them only through recorded evidence and review.
Anti-patterns to avoid
- One use case, one copy: every product recreates business entities, facts and metrics locally because copying is easier than publishing a governed contract.
- One schema, one security perimeter: consumers are either granted the whole schema or forced to create copies elsewhere.
- Direct grants as operating model: privileges accumulate on users and project roles without a reusable hierarchy.
- Shared means unrestricted: reusable assets are exposed broadly without classification, policy or purpose-specific interfaces.
- Enterprise model as prerequisite: delivery is blocked until every neighbouring domain and owner is formally established.
Practitioner conclusion
A strong cross-domain implementation is not one with zero duplication or a perfectly symmetrical schema structure. It is one where teams can explain which business entities and governing relationships are reused, which facts and events remain domain-owned, which measures and metrics are governed, which logic belongs to the data product, which access path is approved and which copies are deliberate, reconciled and temporary. Physical reuse decisions must remain visible, governed and understandable, without turning the article into a complete modelling methodology.
