Permissions and Roles
Overview
Q&A access in TimelyChurch is controlled by two distinct gates that work independently:
- Admin permissions (role-based) -- who can create, edit, archive, or delete a Q&A session in the admin portal.
- Host PIN (knowledge-based) -- who can moderate a live session from the host panel.
These gates are independent. A user with admin permissions does not automatically pass the host PIN gate, and a person with the host PIN does not need admin permissions to moderate -- they just need the 6-digit PIN.
This page documents both gates and how they map to common roles.
Admin Permissions
Q&A has its own dedicated permission group, separate from Events -- granting someone Events access does not grant them Q&A access, and vice versa. Each protected action in the admin portal checks a Q&A permission:
| Action | Required Permission | Effect |
|---|---|---|
| List Q&A sessions, view a session detail page | View | Read-only access to all Q&A sessions for the church. |
| Create a new Q&A session | Create | Plus the church plan must include the Live Q&A feature (Growth or Pro) and the active-session quota must not be exceeded. |
| Edit settings, regenerate Host PIN, regenerate join code, change status, link/unlink event | Edit | Includes archiving, reopening, and pausing sessions. |
| Delete a Q&A session | Delete | Removes the session from active lists; data preserved for restore/audit. |
| Moderate (queue management) | Moderate | A separate permission the role editor can grant; the live host panel itself is gated by the Host PIN, not this permission (see below). |
The Q&A admin area lives under Admin Portal -> Q&A in your sidebar. The entire section also requires your church's plan to include the Live Q&A feature; churches on a plan without it will not see the Q&A admin pages at all.
Permissions are enforced per-church. A Church Admin in Church A has no Q&A access in Church B unless explicitly granted there.
Common Role Mapping (Default Roles)
By default, the only role that can manage Q&A is Administrator (which has full access to every non-finance feature, Q&A included). The other default roles -- Team Leader, Team Member, and Member -- do not include Q&A access, so they cannot open the Q&A admin pages until you explicitly grant them Q&A permissions in the role editor.
| Role | View | Create | Edit | Delete | Moderate |
|---|---|---|---|---|---|
| Super Admin | Yes | Yes | Yes | Yes | Yes |
| Administrator | Yes | Yes | Yes | Yes | Yes |
| Finance Admin | No | No | No | No | No |
| Team Leader | No | No | No | No | No |
| Team Member | No | No | No | No | No |
| Member | No | No | No | No | No |
Roles are configurable per-church, so the actual matrix at your church may differ. To give, for example, a media volunteer the ability to create and run Q&A sessions without making them a full Administrator, open the Roles page in your admin portal, edit their role, and tick the Q&A Sessions checkboxes you want them to have. Each feature is granted as individual action checkboxes (view, create, edit, delete, moderate) plus a data scope (All, Team, or Self).
Host PIN (Moderation Gate)
The host panel is not protected by role-based permissions. Any device that knows the session's 6-digit Host PIN can authenticate and moderate. This is by design: it lets a pastor hand off moderation to a volunteer mid-service without provisioning admin accounts or assigning roles.
How the PIN is Used
- The first time a device opens the host panel, it is challenged for the PIN.
- On a correct entry, that device is marked as authenticated for that session, and is treated as a host for that session only.
- The host session is session-specific -- entering the PIN for Session A does not grant moderation access to Session B.
- Host access persists for the life of that browser session. Closing or archiving the Q&A session ends moderation access.
Regenerating the PIN
If the PIN leaks (for example, a volunteer shares it outside your moderator team), an admin with Edit permission can regenerate it from the session detail page. Regenerating immediately invalidates the existing PIN -- anyone who was relying on the old PIN will be re-challenged and must enter the new one.
Practical Implications
- Admin permissions are not required to moderate. A volunteer with the PIN can run the queue from their phone while the pastor speaks.
- Admin permissions alone do not grant moderation. Even an Administrator must enter the PIN the first time they open the host panel for a session.
- Display View has its own gate -- a 32-character display token in the URL. See Display Token and Security for that flow.
Public Participant Access (No Login)
The participant-facing pages are completely unauthenticated -- anyone with the join link or join code can take part:
- The code-entry page, where participants type in the session's join code.
- The direct join link, which opens the session straight away.
- Submitting a question, voting on a question, and casting a poll vote.
These actions are protected by per-device rate limits (see Rate Limits and Abuse Prevention) and by the optional block participant flow from the host panel. There is no participant login; identity is established via a per-device fingerprint kept in the participant's own browser.
Recommended Setups
- Small church / single-pastor: The Administrator role already covers Q&A. The pastor uses the host panel from their phone with the PIN. Display View runs from a separate browser tab with the display URL.
- Larger church / dedicated AV team: Pastor has the Administrator role. AV volunteer has only the PIN for that Sunday's session -- no admin account needed. Display View URL is preloaded in ProPresenter. If a volunteer needs to create sessions themselves, grant their role the Create / Edit Q&A permissions instead of giving them full Administrator.
- Multi-campus / association: Each campus has its own church record with its own role grants. Q&A sessions are church-scoped; cross-campus moderation is not supported by design.
Previous: Event Integration | Next: Rate Limits and Abuse Prevention