Share what the team owns. Keep boundaries legible.

We define vault purpose, audience, ownership, and lifecycle before permissions and folders accumulate.

Use vaults for meaningful separation.

Separate vaults may make sense for different owners, audiences, security requirements, or lifecycles. A single team can still need more than one boundary; a single department may not.

Shared operational

Authoritative entries used and maintained by a defined team.

Restricted project

Time-bound access with a named sponsor and closure plan.

User-private

Personal items with clear rules against shadow copies of team resources.

Vault charter

Each vault receives a short charter that future administrators can understand without reverse-engineering permissions.

Purpose and in-scope content
Business and technical owners
Eligible roles and access path
Folder and naming conventions
Offline expectations where applicable
Review and retirement cadence

Role validation

Task	Validation
Discover a vault	Eligible user sees it; ineligible user does not
Navigate a parent path	Required visibility exists without excess action rights
Use an entry	Launch and credential behavior match the role
Maintain content	Edit, create, delete, import, and export align with responsibility

Vault FAQ

What is a vault owner?

In applicable RDM workspaces, vault owners can manage a specific vault without broad data-source administration. Exact behavior depends on configuration.

Should offline access be enabled?

Decide from business need, datasource support, security controls, cache behavior, expiry, and limitations of offline mode.

Write the charter before the rules.

We can facilitate a vault-boundary workshop.

Plan the workshop