Start with people, not a permissions table
An owner thinks in concrete terms: Kendall leads Jose, Jay, and the Design team. The setup experience should begin there.
Assign the Team Lead to the relevant team or contractors. Then show a short list of understandable abilities. Do not lead with internal concepts such as scopes, grants, or capability keys.
The result should be easy to repeat aloud: “Kendall leads Design and can see who is working and review team time.”
Define the minimum useful access
A valid Team Lead may only need to see who is currently working. That can help coordinate a handoff or check availability without giving the person authority over Timesheets or money.
- Operational access: see who is working, review team time, approve Timesheets, or see team time away.
- Financial access: see contractor rates, review expenses or invoices, or view amounts owed and payments.
Keep financial access off by default
Rates, invoices, and payments reveal information many operational leads do not need. Make financial access an explicit choice by an authorized person, not a side effect of the Team Lead label.
This is a practical privacy control, not a claim that one permission design is legally required for every business.
Do not confuse a title with authority
A job title in the real world should not silently override product permissions. Someone called Operations Director may have broad responsibilities. Someone called Team Lead may coordinate a small group. The system should enforce what the Company assigned, not guess from the title.
The same principle applies when a person changes teams. Removing them from one team should stop team-scoped access there while preserving unrelated Company access and historical evidence.
Review access as an outcome
A useful access review answers ordinary questions:
- Which contractors can this person see?
- Can they view current work?
- Can they change or approve records?
- Can they see rates or payment information?
- Does any advanced access extend beyond the normal Team Lead setup?
Handle exceptions deliberately
Some companies need a Team Lead to review expenses but not invoices. Others need a Finance user to see invoices and payments without unrelated operational records. Support those cases as explicit permissions rather than inventing a role for every combination.
When access is missing, explain the likely boundary without revealing a private record the person was never allowed to know existed.
Friday Falcon follows this model: the Company chooses who a Team Lead leads, then what they can see and do. Seeing who is working is the minimum. Financial information stays off unless the Company turns it on.
Test the result before the handoff
After saving access, review the outcome from the Team Lead’s point of view. Can they find the contractors they lead? Can they complete the review the owner expects? Are rates, invoices, and payments absent when they were not granted?
This quick check catches both kinds of error: access that is too broad and access that leaves the Team Lead unable to act. Repeat it when team assignments or responsibilities change. A permissions model is only useful when the real experience matches the owner’s intent.