How Permission Checks Work Behind the Scenes
Why access is enforced on the server, and how branch scoping factors into every check.
Why this matters even if you're not technical
Understanding roughly how permissions are enforced helps explain why access sometimes needs a moment to reflect changes, and why hiding a button alone was never how Sermfy protects sensitive data.
The short version
Every request to view or change data first resolves who's asking (the session), what role(s) they hold, and whether that role's permissions cover the specific action, all before any data is returned, not just before showing a button in the interface.
This is also why a directly-typed URL to a page you don't have permission for won't work, even if you found the link somewhere, the check happens regardless of how the page was reached.
Multi-branch nuance
For churches with branches, this same check also considers which branch the data belongs to, a role granted at one branch doesn't implicitly extend to another, even for the same person.
Related Articles
Understanding Roles and Permissions
The basic model behind Sermfy access, default roles, and how branch scoping works.
Managing Multiple Branch Admins
Assign more than one admin per branch, and what happens when an email is already linked to a login.
Deactivating or Removing a User's Access
Why removing access deactivates rather than deletes, and what happens if you re-add the same person later.
Creating a Custom Role
Build a role scoped to exactly the permissions your church's structure needs.