Staff console entry checks
The web console requires an authenticated account, a staff role, and a non-default active church context before opening staff workspaces. This describes console entry; individual data paths still apply their own rules.
Security & trust
A church platform holds prayer requests, family details, kids' check-ins, and pastoral notes. This page describes how FaithIt protects that work today — plainly, and only where the product actually backs it up.
This is a practical product overview — not a certification, compliance attestation, contractual security schedule, or uptime commitment.
Depending on the operation, FaithIt uses role checks, church assignments or memberships, collection-specific rules, and server-mediated workflows.
Current controls
These statements intentionally avoid universal tenant-isolation, certification, transport-policy, or reliability claims that the product does not establish.
The web console requires an authenticated account, a staff role, and a non-default active church context before opening staff workspaces. This describes console entry; individual data paths still apply their own rules.
Roles and explicit permissions are used by staff navigation and many protected operations. The exact check depends on the route, collection, and server workflow; this page does not claim one universal authorization rule.
Many protected church-scoped collections compare a requested church with an authenticated assignment or membership record. The current rules also retain legacy/default behavior and collection-specific exceptions that require path-level review before reliance.
Prayer requests, testimonies, join requests, and other submitted content can use approval and visibility rules where those workflows are configured. Visibility still depends on the exact collection and request path.
Selected minor, household, consent, and audit fields are protected from ordinary client edits. Eligible family and child actions use server-mediated checks in the represented workflows.
Child check-in creates a pickup code that is returned once to the authorized workflow. Only a hash is persisted, and checkout validates the presented code without exposing the stored hash in member-facing responses.
The web client redirects detected production HTTP sessions to the corresponding HTTPS URL. This is a client behavior and is not presented as evidence of edge-level TLS policy or HSTS enforcement.
Production agents use a separate church-scoped identity path with an active-agent record instead of inheriting general staff access.
What this overview means
A readable summary of selected controls and known boundaries in the current FaithIt product.
A substitute for a church-specific review, legal assessment, or independent audit.
As you set up your church
When you enable modules and invite your team, take a few minutes to match access to responsibility. A demo covers all of this too.
Ask directly
We'll answer against how the product actually works today, and tell you plainly where configuration or further review would still be needed.