IT & Security/First-party starter playbook

Onboard new employee

Provision access across Okta, Slack & Calendar.

// what it does

01Collect the essentials. Read the request and confirm you have the new hire's full name, work email, department, and role. If any of these are missing, stop and ask.
02Provision identity in Okta. Create the user in Okta and assign the group policies that match their department and role. Let Okta group membership drive downstream SSO app access — email, docs, and other connected apps — rather than provisioning each app by hand.
03Set up collaboration. Once their account is active, add them to the default company-wide and team Slack channels for their department and introduce them to the team.
04Schedule first-day basics. Add first-day orientation and first-week check-in events to their Google Calendar so they know where to be.
05Welcome and report. Send a friendly welcome message with first-day links in Slack, then post a summary of everything provisioned and anything left for a human to finish.

// guardrails in the draft

Never guess a department or role to unblock yourself — missing info means stop and ask the requester.

Assign access through Okta groups, never by granting individual app entitlements directly.

Don't claim to have created accounts you can't actually provision — if an app is out of reach, hand that step to a human and say so.

If any provisioning step fails, halt and report exactly what succeeded and what did not; do not silently continue.

Before you publish this playbook

Playbook updated 2026-09-17

Map roles to approved groups before provisioning

This playbook coordinates Okta, Slack, and Google Calendar for a new employee. Prepare an approved mapping from department and role to Okta groups, the default collaboration channels, and the first-day events. Confirm that the connected accounts can perform the required actions. Keep access decisions with the people who own identity policy; a convenient template is not a reason to broaden entitlements.

The draft requires the new hire's full name, work email, department, and role. Decide who supplies corrections when any of those are missing. Access should follow the approved Okta groups rather than a collection of individual app grants. Some downstream applications may still need a human; name those handoffs instead of describing every account as provisioned.

Test missing data and partial provisioning

Use an approved test identity and controlled channels to evaluate the setup. Leave out the department in one case and confirm that the workflow asks for it. Try a role without an approved mapping and inspect the handoff. Review the actual group memberships, channel additions, and calendar invitations, not only the final summary. Configure approval gates for access changes according to your policy.

A partial failure needs an exact report of what succeeded and what remains. Before another attempt, have the owner inspect the identity and collaboration systems so already completed steps are accounted for. The useful outcome is a new hire with the intended access and a clear list of any remaining work. It is not a generic success message that conceals an application the agent could not reach.

Onboard new employee

Before you publish this playbook

Map roles to approved groups before provisioning

Test missing data and partial provisioning

Make onboard new employee yours.