Every tool gets an owner.
Access decisions shouldn’t all funnel through one admin. Name an owner for each tool and they approve, review, and manage access for it, while admins stay a permanent safety net.
Owner
Geordi La Forge
Wesley Crusher requests WRITE
Tool owners bring delegated access approvals to Driply. Instead of every request landing on a single org admin, you appoint a Person as the owner of a specific tool, and for that tool, they can approve and deny requests, grant access directly, change levels, revoke, and even edit or decommission the tool.
The person closest to the tool makes the call; the org admin stays a permanent safety net, so nothing stalls when an owner is away.
Approve for their tool, in context
Owners are notified of requests for the tools they own, in Slack and by email, exactly like admins, and decide in one click. The decision is recorded with the owner as the actor, so the trail shows who really approved.
Manage access end to end
For a tool they own, an owner can grant directly, change a grant’s level, revoke, and edit or decommission the tool, the full bundle, scoped to just their tool. Admins keep every right; an owner is additive, never a downgrade.
A focused view, not the whole admin app
A non-admin owner gets a slim shell: the requests for their tools, the tools they own, and their profile. They manage what’s theirs without seeing, or touching, the rest of the org.
Delegation that an auditor still trusts
Owners are appointed by an admin, never self-assigned, and ownership is single and explicit: one accountable owner per tool. Admins manage it in bulk from the catalog: filter tools by category and owner, then assign, reassign, or remove an owner across many tools at once (select every Design tool, assign it to one person). When someone who owns tools is offboarded, the flow surfaces their tools so you can hand them off in the same step.
Every ownership change is written to the audit log as its own event, who was made owner of which tool, and any reassignment or removal, so delegation itself is evidence, not a side conversation. And because authority is re-checked at every layer (database, server action, and the page), an owner can only ever act on the specific tools they actually own; an inactive or offboarded owner has no power at all.
Tool owners is a paid capability, available on Pro and up. Driply still documents and proves access. An owner’s decision records the grant and its reason; the actual change in the tool is performed by your team. By design Driply never writes to your tools.
The result, Faster decisions by the people closest to each tool, with the accountability still on the record.
Questions, answered.
- What is a tool owner in Driply?
- A Person an admin designates as responsible for a specific tool. For that tool they can approve or deny access requests, grant directly, change levels, revoke, and edit or decommission it, without being a full org admin.
- Do owners replace admins?
- No. Admins keep every right and remain a permanent safety net, for any tool, the owner or an admin can act, so a request never stalls because an owner is on vacation.
- Can a tool have more than one owner?
- Each tool has a single, explicit owner today. Co-owners are on the roadmap; for now admins act as the shared fallback.
- Is delegated approval secure?
- Authority is re-checked at every layer, database row-level security, the server action, and the page, and scoped to the exact tool an owner holds. An inactive or offboarded owner has no power, and every ownership change is audited.