Visibility
Who needs to know an entry exists? View access through parent paths is considered before granular action rights.
We translate ownership, job responsibility, and sensitivity into a maintainable RDM vault and permission model.
A vault should have a clear purpose, defined owners, a known audience, and a lifecycle. Folder trees then support that model rather than becoming the model.
Who needs to know an entry exists? View access through parent paths is considered before granular action rights.
Launch, edit, delete, reveal, import, export, manage templates, and administer workspaces are treated as different responsibilities.
Parent rules are the default. Overrides remain limited, named, and reviewable so audits do not become archaeology.
| Role | Typical scope | Operating intent |
|---|---|---|
| Workspace administrator | System settings, users, vaults | Few named custodians |
| Platform engineer | Assigned infrastructure folders | Use and maintain entries |
| Service desk | Approved support targets | Launch without broad secret exposure |
| External consultant | Time-bound project subset | Minimum visible and usable scope |
Not automatically. Use a separate vault when ownership, audience, lifecycle, or security requirements are materially different.
RDM supports inherited and custom permission patterns in applicable advanced data sources. We keep overrides exceptional and documented.
Yes—on a schedule and after material team, vendor, or infrastructure changes. The review should verify both membership and the underlying role intent.
We will map owners, roles, inheritance, and exceptions before rollout.