Ministry leader data sharing

• Status: Proposed — needs leadership/elder approval. One part was decided by the owner on Sat 24 Oct 2026 and still needs leadership to confirm it (contact details, §5).
• For: the elders, the senior pastor, the executive pastor and the communications lead.
• Written: Sat 24 Oct 2026, from the owner's direction that "how and what info we share between ministry head users" needs careful thought.
• What it governs: what the back office shows a staff member or ministry leader who has been given access to Messages, and what it never shows. The system follows this document, not the other way round: every recommendation below is a setting in Settings → Team and permissions, so leadership can choose differently without new code.
• How it is enforced: communications spec COM-052 to COM-059, ADR-0026, and a database draft in supabase/proposed/ that is not applied anywhere until this policy is approved.

In plain words

When we give a ministry leader access to send messages, they can write to the people in their own ministry and nobody else. They can see those people's names, email addresses and mobile numbers so they can do their job. They can't see who is in other ministries, they can't download the list, and they never see giving, medical, custody, background-check or pastoral information. Children never get messages of their own: their parents or guardians are copied. Every send, approval and download is written to a log that an admin reviews each month.

Two or three people at most, appointed by leadership, are Super admins. They set up who can do what, and they can use View as to check exactly what a particular leader sees. View as is look-only: nothing can be sent, approved, downloaded or changed while using it, and every use is logged.

1. Principles

1. Least privilege. Each person gets the smallest set of permissions that lets them do their ministry's work. Access is given per ministry and per action (see email, send texts, make sub-lists), not all at once.
2. Need to know. A leader sees a fact about a person only because their own ministry needs it. Being a leader somewhere is not a reason to see anything about people outside that ministry.
3. Private by default. New leaders start with nothing. Anything not listed as allowed is not allowed. Exports are off. Sensitive ministries are hidden.
4. Consent always wins. A permission to send never overrides a person's choice. People who opted out, have no consent on record, or are children under 13 are left out of every send, whoever sends it, and Super admins can't override that either.
5. Some data is never shared. Giving detail, medical and allergy detail, custody and pickup restrictions, background-check (screening) status and pastoral or counselling notes are never shown in Messages to anyone, in any role. These are the S4 and S5 tiers in the project rules, and they stay in their own protected areas with their own access rules.
6. Children are reached through their guardians. Under-13s have no accounts and no contact details of their own. Messages about them go to their guardians.
7. Everything is attributable. Every send, approval, contact view, download and View as session records who did it, in which role, for which list and under which permission.

2. Roles

A ministry permission (a "grant") is given to one leader for one ministry, with these switches, each set separately:

Every grant has a review date: 12 months after it is given, or 6 months for a sensitive ministry. After that date it stops working until an admin reviews it.

3. Who sees what

"Own ministry" means the ministries a leader has a grant for. "Sensitive" ministries are those whose membership itself is private, such as recovery, grief support, care or counselling-type groups (see §4).

Notes on the table:

• "Never in Messages" for Super admins and Admins means the Messages area never shows it, and View as never shows it either. Finance staff see giving in Giving, and the check-in and safety team see the restriction flag at check-in, under their own rules.
• A custody restriction quietly stops a guardian copy from being sent. The leader sees only "1 guardian not copied (restriction on file)", never the reason.
• The communications lead sends church-wide messages to "Everyone" without seeing sensitive ministries' membership, because "Everyone" reveals nothing about who is in which group.

4. A person in two ministries

The problem. Someone is in the worship team and in a grief support group. The worship leader must not learn about the grief support group from the system: not from a list, a badge, a count, a "also in" line, a consent page, a message history or a search result.

The rule. Each leader sees only their own ministry's membership facts about a person. The system never tells a leader which other ministries someone belongs to, and never says "this person is also in a list you can't see".

Sensitive ministries (recovery, grief, care, counselling-type groups, and any ministry leadership marks sensitive):

• Their membership is never revealed outside the ministry, even to the communications lead and admins, unless that person holds an explicit grant for the ministry. Giving yourself such a grant is logged and shows up in the monthly review.
• Their lists don't appear in other people's audience pickers at all, apart from a locked entry for the communications lead saying the list exists but is private.
• Their contact details can be masked even for their own leader (§5), and their grants are reviewed every 6 months.

5. Contact details

Decided by the owner (Sat 24 Oct 2026); leadership to confirm. A ministry leader sees the email address and mobile number of each person in their own ministries, in full, with no extra step. Leaders need to reach their people, and hiding the details only pushes them back to private spreadsheets.

What stays protected:

• No cross-ministry visibility. Contact details appear only next to the leader's own ministry members.
• Sensitive ministries' membership is never revealed (§4).
• Under-13s have no contact details of their own. Leaders see the guardians' email and mobile for children in their ministry (the "See guardian contacts" switch, on by default).
• Address, birthday, giving, medical, custody, screening and notes keep the defaults in §3.
• Masking stays available as an option, set per ministry: when it's on, the leader sees "j•••@example.org" and "(512) •••-••12" and can still send to everyone; a Reveal button shows one person's details and logs it. Recommended for sensitive ministries.
• A leader can always send to the whole list, masked or not. Sending never requires seeing the addresses.

6. Exports and downloads

• Off by default for ministry leaders. The church-wide "allow exports" setting is off, and so is each grant's download switch.
• If leadership turns exports on, a leader needs both the setting and the switch on their grant. Every download is logged with who, when, which list and how many rows.
• A download never includes consent evidence, address, birthday or anything from §3's "never" rows.
• Admins and the communications lead may download, and theirs are logged too.

7. Message content and replies

• A leader sees only messages sent to their own ministries' lists, including messages others sent to those lists. They never see messages to other ministries' lists.
• Replies go to the sending ministry's inbox only, never to other ministries. Students' replies are never forwarded to guardians (COM-010).
• Test messages go to the church's own test phone and inbox, never to a person.

8. Sub-lists

• A leader may save a smaller list made only from their own ministry's members (for example "Fall retreat drivers"), if their grant allows sub-lists. The sub-list belongs to that ministry and follows its permissions.
• Combining lists across ministries (for example worship team plus youth volunteers) needs the communications lead, even if one leader holds grants for both, so that one list doesn't reveal the overlap to someone who shouldn't see it.

9. Student ministry

• Under-13s get no direct messages. Their guardians get a separate copy marked "Copy of a message to [ministry] students".
• Students aged 13–17 get texts only with a guardian's consent and their own opt-in (COM-049).
• Youth and kids leaders see guardians' contact details for children in their ministry when "See guardian contacts" is on (the default).
• One-to-one adult and student conversations are out of scope for Messages today, and when they arrive they follow the two-adult visibility rule in COM-010.

10. Approvals

• A leader without "Send without approval" sends into the Approvals queue. The communications lead (or an admin) can approve, edit then approve, or decline with a note.
• Nobody approves their own message.
• At approval time the consent check runs again, so anyone who opted out in the meantime is still left out.
• Church-wide sends are made or approved by the communications lead (see question 3 below for who backs them up).

11. View as (Super admins only)

• What it is. A Super admin picks a person, gives a reason ("Checking what the Kids leader sees"), and sees the back office exactly as that person would: their lists, their masking, their locks. Not the Super admin's own wider view.
• Look only. While viewing as someone, nothing can be sent, approved, declined, revealed, downloaded or changed. Buttons are disabled with "You're viewing as [name] — read-only".
• Always visible. A banner on every page says "Viewing as [name] ([role]) — read-only", with Exit.
• Time-limited. It ends by itself after 30 minutes.
• Logged. The start (with the reason), every page viewed and the end are written to the Access log, which admins see in Team and permissions.
• Bound by the same rules. View as never shows giving, medical, custody, screening or pastoral information, because the viewed role can't see it, and leader roles never can.
• No "act as". Nobody can send or change anything in another person's name. If that is ever needed, it's an open question below, not a feature.

Who may be a Super admin. As few people as possible (two at launch), appointed by leadership in writing, each signing in with a second factor (AAL2). Super admin is a role assignment in Team and permissions, not a name in the code.

12. Auditing

Every one of these is logged with who, in which role, when, which list and which permission allowed it: a send, a test send, an approval request, an approval, a decline, revealing a masked contact, a download, a change to a role, grant or setting, and each View as start, page view and end.

Monthly review. An admin (not the person being reviewed) looks through the log each month and confirms: downloads were expected; reveals and self-grants on sensitive ministries had a reason; View as sessions had a reason and stayed within 30 minutes; and grants past their review date were renewed or removed.

13. Onboarding and offboarding

• Starting. An admin gives the role and grants. The new leader reads and signs a one-page confidentiality acknowledgement (what they may see, that it stays within their ministry, no copying lists into personal tools) before the grant is switched on.
• Review. Each grant is reviewed at its review date (12 months, or 6 for sensitive ministries). Unreviewed grants stop working.
• Leaving a role. When someone steps down from a ministry, that grant is removed the same week. When someone leaves the church staff or volunteer team, all access ends the day they leave (the staff sign-in is suspended and the grants revoked).

14. Open questions for leadership

Each question has options and a recommendation. Until leadership decides, the recommendation is the system's default.

1. Should leaders see other leaders' names and contact details (a staff directory)?
   • Options: (a) no; (b) names and ministry only; (c) names plus church email and phone.
   • Recommendation: (b), names and ministry only, so leaders know whom to ask for an approval or a combined list, without sharing personal contacts.
2. Can a leader see a member's other ministries if the member opts in?
   • Options: (a) never; (b) only if the member opts in, per ministry, from their own profile; (c) yes for all non-sensitive ministries.
   • Recommendation: (a) never for now; revisit (b) when the member app exists, and never for sensitive ministries.
3. Who approves church-wide sends?
   • Options: (a) the communications lead alone; (b) the communications lead with a named second approver for absences; (c) any admin.
   • Recommendation: (b), matching COM-004's "never one gatekeeper" rule.
4. How long are message history and the logs kept?
   • Options: (a) 2 years; (b) 5 years after the last message, matching the consent record; (c) forever.
   • Recommendation: (b) for messages and consent, and 2 years for View as page-view entries (keep the start and end records for 5 years).
5. Is an "act as" mode ever needed (sending or changing something in another person's name)?
   • Options: (a) never; (b) only for a named emergency, with two Super admins agreeing and the action marked "sent by X on behalf of Y".
   • Recommendation: (a) never. View as stays read-only so every action is honestly attributed; in an emergency a Super admin sends in their own name.

How this maps to the system