Privacy Policy
How church data is handled
ShepherdOS is operated by VFGL Tech. Each church is its own tenant. Every church record carries a church_id, including members, attendance, welfare follow-up, events, groups, and custom fields. PostgreSQL row-level security policies are the enforcement layer. A query from Church A cannot see or change Church B, even if there is a bug in the application code.
When a church signs up it receives a church_id and a unique slug, for example dominion-assembly. The sign-in token contains that church_id. On every request the API sets app.current_church_id on the database session from the token, before any query runs. Row-level security then filters the rows. The church id is taken from the token, not from a value the browser submits.
Roles inside a church
Isolation between churches is not the only limit. Inside one church, each role receives a different set of records.
- Ushers check people in and can look people up for that service. Pastoral notes are omitted, and ushers cannot open welfare follow-up or church settings.
- Welfare staff see people and follow-up, and they can read and edit pastoral notes. They do not get admin settings.
- Pastors see analytics and growth, and they can read pastoral notes. They cannot edit those notes, and they do not manage staff or settings.
- Church admins have full access for that church, including staff, imports, settings, and pastoral notes.
Pastoral notes are the sensitive care record. They are never sent to ushers. There is no separate case file that other roles can browse.
Security measures
- Passwords are hashed with Argon2id.
- Sign-in tokens are stored in HttpOnly, Secure, SameSite cookies. Page scripts cannot read them, and they are not kept in local storage.
- A change request must include a CSRF token that matches the cookie.
- Sign-in and password reset are rate limited.
Who owns the records
The church owns its data. The platform super admin can see church names and people counts in order to operate the service. Member lists, welfare follow-up, and pastoral notes are loaded only for the signed-in church. The platform account is not a congregation, so those screens are not a way to read another church.
Another church cannot read these records. If a church creates an API key, that key can read people in that church without pastoral notes, and the church can revoke it.
Custom fields
ShepherdOS does not assume one denomination. A church defines its own fields, such as baptism date, house fellowship zone, or membership type. Those fields exist only for that church_id.
Visitor forms
A visitor form belongs to one church. The form asks for consent before a submission is saved. Welfare staff at that church can then see the person for follow-up. A hidden field on the form is used only to reject automated spam.
Cookies
Signing in stores a session in cookies on that browser:
- An access cookie, so the app knows who is signed in
- A refresh cookie, so the session can continue
- A security cookie that must match each change the browser sends
Light or dark appearance is saved in the browser only. It is not a church record. Church mail and messaging secrets are stored encrypted, and the app never sends those secrets back to the browser.
Messages
Birthday notes, visitor welcomes, and test messages are sent only when the church has set up email or WhatsApp. If text messaging is not configured, the message is recorded as not sent.
How long it is kept
Records stay while the church account is active. A deactivated church is switched off rather than left open to its staff. A church admin can correct or remove a person's record from inside the app.