New User Checklist
Use this checklist when a new teammate is joining and needs access to YND OS. It's meant for the Admin who creates the account and the Manager who confirms what the person needs.
Before their first day
- Manager confirms the new hire's role (see the role list in Welcome to YND OS): door_expert, csr, project_manager, dispatcher, design_concierge, reconciler, manager, executive, installer, or admin.
- Manager submits a Role Assignment Request with the chosen role and any extra pages they'll need beyond the default.
- Admin creates the user account in Users (
/admin/users). - Admin assigns the correct role to the account.
- Admin checks whether a standard Permission Set exists for that role in Permission Sets (
/admin/permission-sets) and applies it, rather than granting one-off page access. - Admin confirms the account does not have any demo-data flag enabled — production users should never see demo data.
- Send the new hire their sign-in link and credentials, and point them to Signing In.
Their first day
- New hire signs in successfully (see Signing In).
- New hire's sidebar matches what's expected for their role (see Navigation) — manager spot-checks this.
- New hire reads Your First Day.
- New hire reviews the relevant FAQ pages for their area: General, Sales Pipeline, Site Assessments.
First week
- Manager shadows the new hire on at least one real workflow (a booking, an estimate, a dispatch run, etc., depending on role).
- Confirm the new hire knows what to do if they hit
/access-denied— see Signing In. - Confirm the new hire knows key vocabulary: SAD, Necessary Components, pipeline stages, financing terms — see Sales Pipeline FAQ.
- If the new hire is a Door Expert or CSR, confirm they understand the Appointment Note Taker (call recording + transcription) and the ADD framework (Align, Discover, Design, Decide).
Common mistakes to avoid
Warning: Don't grant broad access "just in case." Permission sets are currently underused across the team — the recommendation is one standard permission set per role, not custom one-offs per person. Ad hoc grants make it hard to know later why someone can see a page.
Note: Remember that several pages aren't gated by role at all (/bookings/new, /estimate, /workbench, most /admin/*, /csr-intake). Creating an account is enough for someone to technically reach these — training and expectations, not the UI, are what keep people in their lane today.
Tip: If the new hire is meant to have the same access as an existing teammate, don't just copy that person's individual grants — check their role and standard permission set instead, since individual access can drift over time.