Configuring Space Membership, Storage Allocation and Cross-Space Data Sharing
Covers the practical configuration steps for setting up a space: assigning members and roles, sizing storage, and sharing objects between spaces for controlled reuse.
Explanation
Once the overall space architecture is agreed (as discussed in the fundamentals lesson), the practical configuration work begins with three interconnected activities: assigning storage, managing membership with roles, and enabling controlled data sharing between spaces. Getting these right determines whether the space setup will scale cleanly as more teams and data volumes are added. Storage allocation happens in the space's administration settings, where a Datasphere administrator (or a delegated space administrator, depending on tenant governance) sets a disk storage limit and, where applicable, an in-memory storage limit for that space. This allocation is drawn from the tenant's total purchased capacity pool. A practical consideration: disk storage holds persisted local tables and replicated data, while memory-related consumption is driven more by how views are materialized and queried. Undersizing disk storage causes load or replication jobs to fail once the limit is hit, so administrators typically monitor consumption trends and adjust allocations proactively rather than reactively resizing during an incident. Membership configuration involves adding named users (or, in some setups, groups depending on identity provider integration) to the space and assigning them a role that determines their capability - for example, whether they can create and edit models (modeler-type access) or only consume finished data via connected BI tools (viewer-type access). This is distinct from the tenant-level administrator role, which governs cross-space settings like overall storage pool distribution, connection type availability, and tenant-wide security policies. A user can be a modeler in one space and only a viewer in another, reflecting real organizational boundaries - for instance, a Sales analyst might build models in SALES_SPACE but only view finished Finance dashboards without editing rights in FIN_SPACE. Cross-space data sharing is the mechanism that lets teams avoid duplicating data pipelines. Instead of replicating the same source table into every space that needs it, a modeler in an owning space (commonly the staging/landing space) shares a specific table or view to a consuming space. The consuming space then sees this shared object as a read-only remote table it can build further views on top of, but it cannot modify the underlying data or structure - changes must be made in the owning space. This preserves single-source-of-truth governance while still allowing decentralized model-building in downstream spaces. Sharing is deliberate and object-level, not automatic; a space owner must explicitly select which objects to expose and to which target spaces, which is a valuable control point for data governance and for limiting blast radius if a shared object needs to be deprecated or restructured. Troubleshooting common configuration issues involves checking three things in order: is the user actually a member of the space with an appropriate role, is the space's storage allocation sufficient for the object being created or loaded, and if working with shared data, has the source space actually completed the sharing step and does the consuming space show the object as available. Many apparent access or visibility issues in real projects trace back to one of these three root causes rather than a genuine platform defect. From an operational standpoint, space configuration should not be a one-time setup - as new use cases arrive, storage needs to be revisited, membership needs periodic review as staff change roles or leave, and sharing relationships need to be documented so that when an owning space's model changes, downstream consuming spaces are notified before their dependent views break.
Real project scenario
A Finance team's modeler in FIN_SPACE needs sales revenue figures maintained by the Sales team in SALES_SPACE. Instead of building a separate replication into FIN_SPACE, the Sales space owner shares the curated 'Sales Revenue Fact' view from SALES_SPACE to FIN_SPACE. The Finance modeler builds a consumption view combining this shared fact with local Finance dimension tables, while Sales retains full ownership and update control of the original data.
Common mistakes
• Granting modeler-level access broadly to all space members instead of restricting edit rights to a small governed group • Forgetting to revisit storage allocation as replicated data volumes grow, causing failed load jobs • Sharing raw, unfiltered staging tables directly to consumption spaces instead of sharing curated, documented views • Not communicating structural changes to a shared object, breaking downstream views in consuming spaces without warning • Confusing tenant administrator privileges with space-level administrator privileges, leading to incorrect assumptions about who can change settings
Best practices
• Assign the minimum necessary role to each space member and review membership on a regular governance cadence • Monitor storage consumption trends per space and adjust allocation proactively before jobs start failing • Share only curated, well-documented views rather than raw staging tables whenever possible • Maintain a lightweight register of which objects are shared from which space to which consuming spaces • Notify downstream space owners before making breaking structural changes to a shared object
Interview angle
Expect scenario questions asking how you would let two departments share a common dimension table without duplicating data or losing governance control; a strong answer explains space-level sharing of a curated view rather than replicating the same source connection in both spaces. Also be ready to explain the practical difference between modeler and viewer roles within a space.