Exceptions for one person

Roles handle the common cases, but now and then one person needs a little more — or a little less — than their role gives them. "Mary at the front desk may also record baptisms." Rather than invent a whole new role, you can grant or deny a single permission for that one person, and it sits neatly on top of whatever their role already allows.

Where it lives

Open the person in Settings → Staff & Teams and find the Access panel on their staff card. It shows that person's effective access — everything their role gives them, plus any exceptions you have already made, all in one view — so you can see at a glance exactly what they can do. Each permission appears as a small chip with a ✓ or a — beside it; a chip outlined in oxblood is one you have already excepted.

Grant or deny one permission

• 1. Open the staff card and go to the Access panel.
• 2. In Permission, choose the action you want to change. The list is grouped by module — for example, *Baptism → Record a baptism*, *Events → Manage events & RSVPs* for the volunteer who runs the fish fry, *Connect → Approve library content*, or one section of Settings such as *Settings: Modules* for an office manager who otherwise has no Settings access.
• 3. Set Access to Allow to grant it, or Deny to take it away, then press Add exception. It takes effect within seconds.
• 4. Every exception you have made is listed underneath as *Allow …* or *Deny …*; remove one with the × beside it.

A *Deny* is just as useful as an *Allow*. If, for instance, you are happy for someone to build and publish schedules but would rather they did not approve a sign-up over one of your scheduling rules, deny them Ministries → Override schedule rules and leave the rest of their access alone.

Actions here, module doors in the role

The Access panel deals in actions — the individual things a person may do inside a module. The module door itself (whether they may open Baptism, Events or Connect at all) comes from their role, set in the role access matrix. So think of it as two layers: the role decides which rooms are open to them, and an exception adjusts what they may do in one of those rooms.

Two rules are worth knowing:

• The finer setting wins. When a role has been granted a whole module and you deny one action beneath it for this person, the denial is what is enforced. The most specific instruction about a key always beats the broader one, whichever way round they were set.
• Capacity & asks never rides along. *Stewardship → Capacity & asks* is deliberately never inherited from a Stewardship grant — it has to be allowed on its own. (A Stewardship denial still covers it.)

How exceptions layer on the role

An exception is an addition to the role, not a replacement for it. The role is the starting point; each Allow you add hands this person one extra permission, and each Deny removes one they would otherwise have. Everything you have not touched still follows their role exactly, and the panel says so plainly: *None — this person follows their role exactly.*

Only genuine differences are stored. If you set a permission back to whatever the person's role already says, Vianney simply drops the exception rather than keeping a switch that changes nothing — which is also how you undo one. Remove an exception at any time and the person falls straight back to what their role allows.

What you cannot except

• The locked permission — "Remove a funeral case" (pastor-only 🔒) — cannot be granted or denied here. Canon law reserves it to the pastor, so it is left out of the picker entirely; the chip simply shows with its padlock.
• Father himself is not a target for exceptions. The priest role always has everything, so the panel says *Always everything — the priest can't be restricted*, and there is nothing to add or withhold.
• Safe Environment is shown at the top of the panel but is read-only there — it reads either *no access* or the level the person holds, *managed in the Safe Environment module*. Change it on the staff row itself, not here.

The module-door reminder

Actions live inside modules. If you are about to allow a specific action for a module the person cannot otherwise open — say, *Record a baptism* for someone with no Baptism access at all — Vianney warns you before you add it: *this person can't open Baptism, so this won't show anywhere.* Give them the module too, through their role or the matrix, and the new permission becomes usable.

Tips

• Reach for an exception before creating a new role — it is far simpler, and the Access panel keeps the whole picture in one place.
• Denials are useful too: keep a role broad but quietly withhold one sensitive action from a particular person.
• Every change here is written to the audit trail.
• To decide what the roles themselves allow, see Who can do what: the role access matrix.