Forms Permissions and Access Control

This article explains who can build, view, edit, and delete forms in TimelyChurch, and how to grant access to the right people on your team.

Who Can Manage Forms?

Form access is governed by two layers:

1. Plan-feature gating -- Does your church's subscription plan include the Forms feature at all? If not, the entire Forms sidebar item is hidden.
2. Role-based module permissions -- Among users who can see Forms, what can each individual do?

Both layers must allow access for a user to take a given action.

Layer 1: Plan-Feature Gating

Whether the Forms module is available depends on your church's subscription plan:

• If your church's plan does not include the Forms feature, the admin area for forms shows a "Feature Not Available" / upgrade prompt -- regardless of the user's role.
• Public form pages are not affected by this gating -- already-published forms keep working even if a plan downgrade removed the feature, but new forms cannot be created or edited.

Tip for Super Admins: To check whether a church has the Forms feature, look at the plan's feature list under Super Admin -> Plans.

Layer 2: Role-Based Permissions

Within a church, access to the Forms module is controlled by the same role/permission system used everywhere in TimelyChurch. The Forms module supports four standard actions:

These show up in the Roles & Permissions screen (Settings -> Roles & Permissions, reached from the Team page via Manage Roles). Modules are grouped into collapsible category sections; Forms appears under the Forms category as a row labeled "Forms — Create forms and view submissions". Instead of toggling raw checkboxes, you pick a permission level from a pill row -- None, View, Edit, or Full:

• None -- no access (the module is off for this role).
• View -- grants view access.
• Edit -- grants view, create, and edit access.
• Full -- grants all four actions (view, create, edit, delete).

If you want a non-standard combination, the row switches to a Custom state and exposes the individual action checkboxes (View / Create / Edit / Delete) underneath the level pills, so you can fine-tune exactly which actions are granted.

Built-in Roles

Out of the box, the following roles have full access (view, create, edit, delete) to Forms:

• Super Admin -- TimelyChurch staff. Has access to every church.
• Church Admin -- The "owner" role. Full access to all modules.
• Team Member -- The default role for invited staff and volunteers. Access is shaped by the permissions you grant.

Custom roles (e.g., "Connections Coordinator", "Volunteer Director") are blank by default and need Forms permissions explicitly granted in the role editor.

Permission Scope

Forms uses the same All / Team / Self scope levels as the rest of the app:

• All scope -- See every form in the church (default for Church Admin / Super Admin).
• Team scope -- Currently treated like All for Forms because forms are church-wide rather than group-scoped. (If a future release adds per-group form ownership, scope will narrow to forms tied to groups the user leads.)
• Self scope -- Currently treated like an effective lockout for Forms management; users with self-only scope generally should not have the Forms module enabled.

Where Forms Are Managed

There are three different surfaces that touch forms. Each respects the permission layers above.

Admin Portal (primary, recommended)

This is the modern UI used for day-to-day form work: building, publishing, sharing, and reviewing submissions. Access requires Forms permissions on the user's role and a plan that includes the Forms feature.

Advanced Admin (Super Admin)

An advanced admin area exists for power-user data work (bulk edits, advanced filtering, and Super Admin support tasks). Access requires the user to be authorized for the advanced admin panel for that church (typically Super Admins and Church Admins).

Member Portal (read-only public access)

Anyone -- members, visitors, or admins -- can fill out a published form here. There are three visibility modes set by your church's Portal Visibility settings:

• Public -- Anyone, signed in or not, can submit forms.
• Members Only -- Only signed-in members can access forms; visitors get redirected to the login page.
• Hidden -- The forms area is hidden from the public; admins still manage forms in the admin portal.

See 08-embedding-forms.md for the visibility-settings table.

Granting Access -- Step by Step

To let a non-admin user (e.g., a "Connections" coordinator) manage forms:

1. Sign in as a Church Admin.
2. Go to Settings -> Roles & Permissions (from the Team page, click Manage Roles).
3. Either edit an existing role or create a new one (e.g., "Connections Coordinator").
4. Open the Forms category section, find the Forms row, and set the permission level you want to grant. Common combinations:
   • Build & monitor only: choose Edit (grants view, create, edit). Delete stays off, so they cannot remove forms or submissions.
   • Submissions reviewer: choose View only. They can read submissions and run reports but cannot change form structure.
   • Full owner: choose Full (view, create, edit, delete).
   • Anything in between: use the per-action checkboxes in the Custom state to grant an exact mix.
5. Save the role.
6. Go to Settings -> Team, open the team member you want to grant access to, and assign the role.
7. The user must sign out and back in for the new permission to take effect.

What Happens When Permission Is Denied

• Module-level denial (View turned off): The Forms sidebar item is hidden. Trying to open a forms page directly shows "You don't have permission to access Forms."
• Action-level denial (e.g., Delete turned off but the user tried to delete anyway): The system blocks the action and shows a message like "You don't have permission to delete in Forms."
• Plan-level denial (the plan does not include Forms): The user is redirected to the plan upgrade prompt.

See Also

• 10-build-your-first-form.md -- end-to-end tutorial for users who already have permission.
• 09-approval-workflows.md -- how approval/rejection of submissions interacts with these permissions.
• 08-embedding-forms.md -- public visibility settings.