Onboarding in Folkbase begins when a role is defined, well before anyone's first morning. The access the job needs is written down ahead of time, and the work around it is split into tasks with clear owners. By the start date, there is nothing left to assemble.
The role declares access
Every role can have a role template: the list of grants a person in that role should hold. A grant covers one tool at a given scope, so a template for a product designer might list Slack, Google Workspace, and Notion, each with the scope the job calls for.
The template is set when the job is posted. By the time an offer is accepted, nobody has to guess which accounts to request or open a ticket to get them. Each grant on the new record points back to the role that justifies it, so the reason for every account is visible from day one. The path from accepted offer to first day is covered in hiring to day one.
The role decides the access, so the start date only has to open it.
From pending to open
Access moves through a short, visible sequence:
- The record exists. Accepting an offer creates it from the application, or an admin adds the person directly.
- Onboarding starts. Every grant in the role template is queued on the record as pending. You can see exactly what the person will get, and nothing is open yet.
- The person is activated. The pending grants open. For tools connected as integrations, the account is provisioned in the tool itself.
- Extra access is a request. Anything outside the template goes through a request that a manager or admin approves, and the approval stays with the grant.
The gap between pending and active is deliberate. It gives IT and the manager a chance to check what is coming before anything opens, and activation is a single action instead of a list of accounts to create one at a time. On the start date, accounts and tasks are ready before the new hire signs in.
Tasks for each person involved
Access is half of onboarding. The other half is work that people have to do, and Folkbase assigns it as tasks. Each task has an owner, a status, a priority, and a due date. Onboarding usually splits across three owners:
| Owner | Example onboarding tasks |
|---|---|
| IT | Check every pending grant before activation, prepare hardware, confirm sign-in on day one |
| Manager | Plan the first week, set early goals, review the new hire's first submissions |
| New hire | Fill in personal details, upload signed documents, pass the security policy quiz |
These come from task templates built out of steps: forms, checklists, quizzes scored pass or fail, document upload slots, and reviewer steps where someone approves a submission. Submissions waiting on a reviewer collect in a review queue, and filters surface anything overdue, escalated, or blocked.
Everyone sees the part that belongs to them. The new hire signs in to their own tasks and their own access, with no shared checklist to scroll through.
Progress managers can see
Managers see onboarding for their own team, next to team access and team analytics such as task completion, review turnaround, and onboarding progress. They do not have to ask IT whether accounts are ready or ask the new hire which forms are done. The record answers both.
Take Maya Okonkwo, joining the Design team in Berlin on Jun 2, 2026. Ahead of that date, her manager, A. Reyes, can see which of her grants are still pending and which of her tasks have owners and due dates. On her first morning, the same view shows her grants open and her first tasks waiting.
Plan availability
Onboarding and offboarding are included in the Growth and Business plans, along with tasks and documents, integrations, and the job pipeline. Starter includes the directory and access grants by role.