Access is set per person, one feature at a time. There are no roles to decode: what you tick is exactly what that person gets.
Open People & Team → Access. Choose someone on the left, and the right-hand panel lists everything the back office contains — Schedule & calendar, Content, Sacraments, People & households, Finance, and so on. Each row offers:
Two rows go further, because two actions leave the building: Send on Emergency alerts (staff may draft one; sending it to the whole parish is a separate decision) and Publish on Groups (renaming a committee is not the same as putting twenty-four parishioners' names on the public website).
Under every feature is the list of pages it opens, in the same words as the menu — "Sacraments · 7 pages · Baptism · First Communion · Confirmation…". You are never asked to guess what a permission means.
And at the bottom of the panel, "What they will see when they sign in" updates as you tick, so you can check your work before saving.
When you choose Read, the panel says what Read means for that feature — because it varies, and the differences matter:
Some features do not offer Read yet. That is deliberate: Nave only offers a level it can actually enforce, so you are never shown a setting that would quietly not work.
Above the list, pick the job that is closest — Pastor, Parish office, Finance, Content editor — and the whole panel fills in with what that job usually needs. Then change any row. The job is a starting point, not a setting: nothing remembers which one you used, and nobody's access changes later because the job did.
Two more shortcuts sit beside them. Read-only gives Read on every feature that supports it, for a council member or an auditor who should see but not touch. No access clears everything in one press.
Sacraments, Ministries and Groups can be narrowed to the ones a person actually governs. Your Baptism coordinator is not your Confirmation coordinator, and now you can say so: set Sacraments to No view, then set Baptism to Write. The panel marks it as an exception so the shape of someone's access reads at a glance.
Changing the top-level choice clears the exceptions under it — a new decision replaces the old one rather than leaving pieces of it behind.
Super admin is the tick at the top: every feature at its highest level, including the power to change anyone else's access. Nave will not let you remove the last one — a parish that cannot change its own access is locked out of everything else it might want to fix.
An invitation carries a job, and that job is applied once, when they first sign in. If they were invited as a plain member they will have nothing until you grant it. Open their row in Access and set what they need.
It updates on their next page load. What you see in "What they will see when they sign in" is what they get — the menu and the data behind it come from the same place.
Every access change is recorded in the Activity Log under Governance, with who made it and what it was before. Access changes are the ones worth being able to answer for later.
They are still there as a name — "Parish office", "Finance" — used on invitations and where a person is introduced. They no longer decide anything. If you want to know what someone can do, look at their Access panel; it is the only answer.