New hires productive on their first morning.
A joiner needs a dozen tools at once, and the list lives in somebody’s head. Build it once per role, schedule it against the start date, and every tool is routed to the person who can grant it, on the record as it happens.
Wesley Crusher requests access
“Shipping the billing fix”
The cost of bad onboarding is rarely the first day. It is the fortnight of small blockers afterwards: the design tool nobody remembered, the repo access that needed a different approver, the account that was created but never added to the right group. Driply makes the list explicit. Build a checklist per role, run it against the hire, and each tool routes to whoever can grant it. What is done, what is waiting, and on whom, is visible the whole way.
The list nobody wrote down
Most teams onboard from memory, or from a doc that was accurate two hires ago. The result is predictable: the obvious tools land on day one and the long tail trickles in over two weeks, each item costing somebody a message and a context switch.
It gets worse as you grow, because the person who knows the list stops being the person doing the onboarding, and because more of the tools have an owner who is not an admin. The hand-off multiplies exactly when you have less slack to absorb it.
One list per role, reused
An engineer, a designer, and an account executive need different stacks. Build each list once and run it against every future hire in that role, so the knowledge lives in the register rather than in whoever did it last time.
Routed, not chased
Tools that have an owner go to that owner as a request; the rest you work inline. Tools the person already holds are skipped. Nobody is asked for something they cannot grant.
Scheduled against the start date
On Business, an HR manager schedules the hire and the checklist fires automatically ahead of their first day by the lead time you set. The access work starts before the person does, without anybody remembering to start it.
The result, A first morning that works, and a record of why every account exists.
Onboarding that leaves evidence behind
Because each item is resolved by a person who attests that access was granted, an onboarding run doubles as evidence: who got what, approved by whom, on which date. The same record that makes the first morning smooth is the record the access review reads later.
Checklists are available on Pro and up, combinable on Business, where a baseline list for everyone merges with the hire’s department list into a single de-duplicated pass. The HR Manager role that schedules them is a Business capability.
One boundary worth being explicit about: "provisioned" in Driply means the grant is recorded and a human attested to it. Your admin or the tool owner performs the actual account creation in the tool. Driply never writes to your tools.
Driply documents and proves access. It doesn’t provision or revoke inside your tools, and by design never writes to them. You stay in control of the actual access.
Questions, answered.
- Does Driply create the accounts?
- No, and it never will. It routes each tool to the person who can create the account and records the grant once they confirm it. The register stays accurate without Driply holding write access to anything.
- Can onboarding start before the first day?
- Yes. On Business, HR schedules the hire with a start date and Driply fires the checklist ahead of it by the lead time you configure, so access is ready rather than requested on the morning.
- What if a hire needs something not on the list?
- Add a tool to a run in progress. The addition is recorded like any other item, and you can fold it into the role’s checklist so the next hire gets it automatically.