The screen answers “who can do what?” without forcing a second user system.
- Clerk handles sign-in and stores role metadata.
- SalonCare shows provisioned users so operations can verify access quickly.
- Vendor access stays narrow from day one.
- The same model can later be tested in SalonOverview if it proves simpler.
Security is not hidden behind the backend phase.
- Tenant isolation by customer is part of the architecture.
- Every ticket move, note, and role change should be auditable.
- Uploads need size limits, type checks, and safer storage.
- A release security review becomes a planned milestone, not a guess.
Role rules at a glance
Clear behavior matters more than a complex matrix. These cards show the access logic you already approved.
Admin
All salons, all board moves, vendor assignment, PM template management, close authority.
GM
Same ticket movement power as admin, portfolio visibility, digest access.
Salon Manager
Own salon only. Add notes and photos. Move tickets only from In Process to Resolved.
Vendor
Assigned items only. Add notes. Accept assigned PM work. No cross-salon visibility.
Provisioning model
Clerk remains the source for login and role metadata. SalonCare can still show who is provisioned and what each person can see.
What lives in Clerk
User identity, sign-in, role metadata, and salon scope fields used by the app.
What lives in SalonCare
Audit history, activity records, ticket ownership, PM assignments, and digest results.
Why this is simpler
No duplicate password flow. One source for access. Cleaner path if you later test the same model in SalonOverview.
Provisioned users
You said it would be useful to see provisioned users even if the app is reading access from Clerk. This table is the right center of gravity.
Security and release planning stays visible
You wanted security planning included up front, not added at the end. This can live inside the project plan and later become the release checklist.