Onboard a new hire’s access in one pass.
A new joiner needs many tools at once. Build a reusable per-role checklist, run it against the new hire, and work every tool to done, routed to the right owners and logged as you go.
- Google Workspaceprovisioned
- GitHubprovisioned
- Figmaowner: Geordi
- Notionyou provision
Day-to-day, access changes one tool at a time. A new hire needs many at once, and that’s where things get missed. Onboarding checklists are reusable, per-role access lists (an “Engineer” list, a “Marketeer” list) you run against a new joiner in one guided pass.
Each tool is tracked from request to granted on a run board, owned tools route automatically to their tool owners, and the whole thing is logged, so a new hire’s access is complete, consistent, and on the record from day one.
Build a checklist once, per role
Define an ordered list of the tools a role needs, each with the access levels and the seat that role should get, optionally tied to a department. Reuse it for every hire into that role, no more rebuilding the list from memory each time.
Run it, and the work routes itself
Start a run against a new hire. Driply auto-suggests the checklist matching their department. Tools that have an owner route to that owner as a request; the rest you work inline. Tools the person already holds are skipped automatically.
Track every tool to done
A run board shows each tool’s state, provisioned, waiting on an owner, pending, or skipped, with live progress (“6 of 9 · 2 waiting”). Change your mind mid-run? Cancelling tears down cleanly: it revokes this run’s grants and cancels its open requests.
Guided and consistent, without losing the record
The checklist is snapshotted into each run, so editing a template later never rewrites an onboarding that already happened, historical runs stay exactly as they ran. Owners are notified once per run (a single batched message and email listing their tools to action, not one ping per tool), and the new hire gets a single completion summary at the end rather than a stream of per-tool emails.
Onboarding sits on top of tool owners, so the same accountability applies: owned tools are approved by their owner, everything is scoped per tenant, and every grant lands in the append-only audit log. Owners and onboarding are both paid capabilities on Pro and up; departments, the grouping that powers auto-suggest, are available on every plan. On Business and up, a single run can combine multiple checklists, a baseline “everyone” list plus the hire’s department list, merged and de-duplicated into one pass.
An honest note on what “provision” means here: ticking a tool as provisioned records the grant and a human attestation that access was given. Driply documents and proves the access. Your admin or the tool’s owner performs the actual account change in the tool itself. It’s a guided, audit-defensible workflow, not an auto-provisioning engine, and Driply never writes to your tools. Read-only connectors that confirm which accounts already exist and reconcile them to your register are on the roadmap; they verify, they never provision.
The result, Every new hire starts with exactly the right access, granted, routed, and recorded.
Questions, answered.
- What is an onboarding access checklist?
- A reusable, per-role list of the tools a new hire needs, with the access levels and the seat for each. You run it against a joiner and work each tool to done on a run board, with owned tools routed to their owners, so nothing is forgotten and it’s all logged.
- Does Driply automatically create the new hire’s accounts?
- No. Driply guides and records the work and routes it to the right people; ticking an item attests the access was granted and writes the grant to the record. Your admin or the tool owner makes the actual change in each tool. Driply never writes to your tools by design. (Read-only connectors that confirm which accounts already exist are on the roadmap; they verify, they never provision.)
- Can checklists be tailored per role or department?
- Yes, build one checklist per role, optionally tied to a department. When you onboard someone, Driply pre-selects the checklist that matches their department.
- What happens if I cancel an onboarding run?
- Cancelling is a confirmation-gated teardown: it revokes the grants already made in that run and cancels its pending owner requests, so a stopped onboarding doesn’t leave access behind.