Invite people and set access

The roster, and the place access is decided: one level per class per person, stated in English on the row.

The roster is the permissions surface. There is deliberately no separate grid on a settings page somewhere, because the moment access is decided is the moment somebody is invited or edited, and a permissions screen nobody visits is where a good permission model goes to die.

So the decision lives next to the person it applies to, and every row says in plain words what that person can do.

What you are setting

Access is four classes and a level per class. Somebody can hold edit on the schedule and none on money. A lender can hold view on money and nothing else. The roles page is the table of what each level means.

Three things sit alongside the levels. A membership covers the whole workspace or only the projects you name. Somebody from outside your company is marked as such, so a row says who is in the building and who is not. An invitation carries an expiry date, and an expired invitation is shown as expired rather than quietly still working.

Where somebody may approve money, the approval carries a ceiling, so the sentence on their row states the limit as well as the power.

What the app refuses

Every change here runs through the same checks the platform console uses. They re-check your authority, refuse to leave a workspace without a full administrator, and reject a project that belongs to a different workspace.