← All privacy impact assessments

PIA: “Send feedback to GroupApp” — sending one item to us

Status: Built on 30 September 2026 against this assessment, which was written before the code; not yet released — it reaches members with the next database release and app update. As built: the action is offered on an assistant reply to the member and (until the app update after 31 October 2026) on their own message in the group chat, and a note can be sent from Settings → Your choices, where each sent item is listed with the date it will be deleted and a Delete. Task and event items are not offered yet. The rate limit counts sendings in our consent record, so deleting an item does not allow another sending that day. Revised on 3 October 2026: we decided to drop the preview of the item and to email each item to our team's inbox at help@groupapp.ai. Names we hold are still replaced before sending and checked again on our side. The sections below say what that changes, and §8 records what we now accept. Revised on 10 October 2026: the visible entry is renamed “Send feedback to GroupApp” to name its actual team destination. The separate “Send to assistant” group-chat action only prefills a private assistant composer and does not use this feedback flow. The two-tap disclosure, recipient, consent, redaction, storage and retention here do not change. Revised on 12 October 2026: adults who enable Help us improve may open this same sheet from the reviewed Add several or Describe a routine draft. The initial editable general note combines the member's own submitted text and the proposed draft; the member can edit it, then must press Send. It is subject to the same age, group, redaction, consent, 90-day retention and deletion rules. A thumb alone sends nothing, and this feedback is not a LangSmith score. Revised on 30 October 2026: adults can also open this same sheet from a stopped Woolworths shop (“Report this problem”). It is offered as a general note the app pre-fills with the stage and a fixed stop sentence (no item title, no error text, no trace link). The member edits it before Send; the same age, group, redaction, consent, 90-day and deletion rules apply. The in-place “Sent to GroupApp.” is the sender's own confirmation, held in memory. The wording version and the consent version do not change. Revised on 15 October 2026: when the item is about a request that was recorded under “Help us improve the assistant” (an assistant reply, an Add several tasks or events draft, or a Describe a routine draft), the phone sends that record's identifier with the item, the sheet's first line says so before Send (wording version feedback-1.3-2026-10), and the emailed copy carries a link to the record. Nothing of the record is copied into the item: the link only opens it, for people on our team who can sign in to the tracing tool, for as long as the tracing tool keeps it (14 days). The changes are in §2, §4 and §8. Revised on 31 October 2026: from the next app update, the group chat no longer offers “Send feedback to GroupApp” on a member's own message. A message to the group is not feedback about GroupApp, and the action sat beside “Send to assistant” on the same sheet. It stays on an assistant reply, in the reviews and the stopped shop above, and as a note from Settings. Items already sent from the chat are kept and deleted exactly as before. Nothing else here changes. Written: 30 September 2026 · Last revised: 31 October 2026 Nothing here is legal advice. We have not taken legal advice at this stage; where a question needed a lawyer we took the more conservative reading and say so. Children's Code citations are to the exposure draft; section numbers may move on registration (due 10 December 2026).

1. Purpose and scope

Why: so that a member who wants us to see something that went wrong — an assistant answer that was wrong, a message that looked broken — can send us that one item, instead of us needing any way to read their group's content ourselves.

This is one of two routes by which a member's content reaches our team on purpose. The other, since 27 October 2026, is a report about another member's message or about a member (member-safety-reports-and-blocks.md, HQ PIA-007), which carries another person's words and has its own assessment. Everything else we say about content — that we do not read it, that some of it is encrypted with keys our servers never receive — depends on there being no other route. So this assessment is written to make the route narrow: one item, the member's own, with other people's names replaced, sent only on a second tap, kept for 90 days, read by our team in its own inbox and through a restricted role, and never shown to anyone else in the app.

In scope: the “Send feedback to GroupApp” action on an item; what is removed before sending; the email to our team; the optional thumbs-up or thumbs-down and comment; storage; who can read it; retention and deletion; the consent record; the age and posture limits; whether it is a "feedback feature" under the Online Safety Rules.

Out of scope: improvement traces, which are a standing consent with a different recipient and their own assessment (assistant tracing); public recipe reviews, which are published by design; bug reports sent through the app stores, which we do not control.

2. Data involved

Kind Whose Children's? Sensitive? Free text?
The item as sent: the text of one thing the member wrote, or of one assistant reply to the member together with the request it answered the member's own (a reply addressed to them counts as theirs) possibly — see below possibly — a request about a child's medicine is health information yes
An optional rating: thumbs up or thumbs down the member's own no no no
An optional comment from the member, up to 1,000 characters the member's own possibly possibly yes
The kind of item (closed list), the app version, the group's privacy level at the time, and the date the member's own no no no
Since 15 October 2026, when the item is about a request recorded under “Help us improve the assistant”: that record's identifier the member's own no no no
The member's account id and group id the member's; the group's no no no
A consent row, purpose feedback_submission, one per sending the member's own no no no

Why each is necessary. The item and comment are the whole point. The record's identifier lets us open the steps behind a wrong answer — which the item alone cannot show — without asking the member to describe them; it exists only for members who already chose to share that record. The rating lets a member say "this was wrong" in one tap. The kind, version and privacy level let us understand the item without asking for more. The account and group ids are kept only so that the item can be deleted when the member withdraws it, deletes their account or when the group is deleted; the reviewing role cannot read them (§6).

Children's information. An item can mention a child — "log a nappy for Remi". Children's names from the group's baby tracker are replaced before sending (§3), but a child can be referred to in ways we cannot recognise ("the little one"). A member under 16 cannot send anything (§4).

Not collected, and could have been:

3. Flows and locations

Data Device Supabase (Sydney) Our assistant server Model provider Our team
The item, before sending opened on the phone (sealed items are decrypted here, as they are for display) — — — —
The item as sent, names replaced redacted here; the member confirms with a second tap stored in feedback_submissions for 90 days never never emailed through Resend to help@groupapp.ai, and readable by the reviewing role
Rating and comment typed here stored with the item never never in the same email; readable by the reviewing role
Consent row — stored in consents — — —

The phone sends text, not a reference. The phone builds the exact text that will be stored and sends that text — not a reference to the item from which the server could fetch more. Until 3 October 2026 it also showed that text to the member before sending; we dropped that preview because it made a simple report feel like a form. Before sending, the phone replaces:

and the sheet tells the member how many were replaced ("3 names or contact details will be replaced before sending"). Items from Mail Sifter — forwarded mail and the cards made from it — cannot be sent at all, because they are written by people outside the group.

On our side, the function that stores the item checks it again against the group's current roster and baby names and refuses it if one is still present, rather than quietly changing it; changing it on our side would mean storing something different from what the member's phone sent.

Emailed to our team. Every ten minutes a scheduled job sends each stored item that has not been emailed to our team's inbox at help@groupapp.ai, through Resend, our email provider (which already receives Mail Sifter mail). The email carries what the reviewing role can read — the item, rating, comment, kind, app version, group privacy level, date and the item's id — and never the member's account, their group or their consent. The item is stored before any email is attempted: a failed email is retried, up to ten times, and the item stays stored, listed in Settings and deletable either way. Each item is checked again in the moment before its own email is sent: if the member deleted it before then, it is not emailed. An email that has gone is a copy in our inbox that deleting the stored item does not reach; it stays until we delete it, and the sheet says so.

Encryption. Chat, photos and the assistant conversation are sealed on the phone. Sending one of those items to us means the member's phone opens it and sends its text to us in the clear, over the usual encrypted connection, and our side emails it on to our inbox. That is the member's choice for that one item, and the sheet says so: "This will be readable by our team."

Where it is kept. In our database in Sydney, in a table our app reads only to show the member their own items, and as an email in our team's inbox. It is never sent to a model or to our assistant server; the only other provider it passes through is Resend, to deliver the email.

4. Legal basis and consents

One consent per sending. Each time a member sends an item, a consent row with the new purpose feedback_submission is written in the same step as the item, and the item records which consent row it belongs to. The consent's expiry is the item's deletion date (90 days), not the usual twelve months, because the consent is to keep that one item for that long.

What the member is told at that moment, on the sheet, before the confirm tap (wording version feedback-1.3-2026-10 since 15 October 2026; 1.2 shortened the facts of 1.1 on 10 October). One line is always shown — who reads it and exactly what, which is the choice being made:

Our team will read only this, your rating and your comment. Other people's names and contact details are replaced.

When the item is about a request recorded under “Help us improve the assistant”, that line is replaced, because “only this” would no longer be true:

Our team will read this, your rating, your comment and this request's record from “Help us improve the assistant”. Other people's names and contact details are replaced.

The rest opens under "How it's handled" on the same sheet, one tap away and before Send:

It's emailed to help@groupapp.ai to help us fix what went wrong. Kept for 90 days. Delete it any time in Settings → Your choices; ask help@groupapp.ai to delete the emailed copy. More in the privacy policy, in Settings.

Putting the last four behind a tap is an accepted trade (our principle, "useful first, with informed opt-in"): the line that decides the choice is always in view, the rest is on the same sheet before Send, and the privacy policy carries all of it.

Our position, taken without legal advice: per-act consent is valid here with the item being the member's own, the removal of other people's details, a plain statement of who receives it and how, and a separate confirm tap. We first required a preview of the exact payload as well; we dropped it on 3 October 2026, judging that a member who opened the action on their own message or reply knows what that item says, and that the names we can recognise are replaced either way. What a preview used to catch and no longer does is in §8. The consent wording version moved to record the change.

Who cannot send:

Withdrawal. A member can delete any of their items from "Your choices" at any time. Deleting removes the item immediately and writes a withdrawal to the consent record.

5. Risks and mitigations

Risk Who is harmed Mitigation Structural or conventional? Residual
F1 A member sends something that names another member or a child, and our team reads it the other member; the child Names from the roster and tracker replaced on the phone and checked again on our side, which refuses a match Conventional on the phone; structural on our side for names we hold A nickname or description we cannot recognise ("my ex"), now without a preview to catch it
F2 An assistant reply quotes a task or event another member wrote, and it is sent the other member The reply is the member's own (addressed to them); names are replaced Conventional Titles written by others can appear in a reply, and no preview shows them first
F3 The action is used to send us a whole conversation, or a chat thread the group One item per sending; items capped at 4,000 characters; ten sendings a day and thirty a month per member; the function refuses anything else Structural (function limits) —
F4 A child sends a sibling's baby log the baby; the family Not available under 16, refused on our side Structural —
F5 A member of a Phones-only group sends group content the group Refused on our side by reading the group's level Structural A member can still copy text and email it to us; that is outside the app
F6 Our team reads more than the items members sent every member Items live in their own table, readable only by a restricted role that cannot see who sent them or from which group, and in our team's inbox as an email that names nobody; our rule that no one at GroupApp reads group content applies to everything else Structural for the table; the rule is a policy commitment Holders of the database's own administrative access
F7 Items are kept longer than promised the member A nightly deletion job, built and shipped before the action itself, deletes every item past 90 days Structural (scheduled database job) —
F8 An item survives the member's account deletion or the group's deletion the member Both deletions cascade to the item Structural Backups, for up to 90 days
F9 A rating is shown back to someone, becoming a "how others reacted to your post" feature the member who wrote the item Ratings are stored for our team only; no screen displays any rating, count or "reviewed" state to anyone; the item rated is always the sender's own Conventional, test-pinned by a source scan —
F10 Items feed back into what a member is shown every member Items are never used to choose, rank or personalise anything the app displays Conventional —
F11 The stored text differs from what the phone sent the member Our side stores the text sent or refuses it; it never edits Structural —
F12 An emailed item outlives the 90 days, a deletion or the account the member The email carries no account, group or consent; the sheet and the policy say the email stays until we delete it and how to ask Conventional (our inbox is outside the database's deletion) An emailed copy is kept until we delete it by hand
F13 An email fails and the item is lost the member The item is stored before the email; a failure is retried up to ten times and never deletes the item Structural (the delivery function only stamps or counts) —

Is this a "feedback feature" under the Online Safety Rules? Rules s 4A(5)(a) defines one as a service that "can display information to an end-user about the extent to which other end-users have viewed or otherwise engaged with material posted by the end-user". We checked each part:

Finding: not a feedback feature, because the app displays nothing about anyone's engagement with anything, and the only engagement recorded is the sender's own, with their own item, sent to the operator. It also does not add a recommender feature (s 4A(2)), because items are never used to select what a member is shown (F10). If a future change shows a member "your report was reviewed", lets a member rate another member's post, or uses items to rank anything, this finding must be re-run.

6. Structural versus conventional

Property How it is held Kind
Only the text the member's phone sent is stored Items are written only through a storing function; members have no direct insert Structural
Other members' and babies' names are not stored Replaced on the phone; the storing function refuses a remaining roster or baby name Conventional + structural check for names we hold
Under 16s and Phones-only groups cannot send The storing function reads the age band and the group's level on every call Structural
One consent row per sending, linked to the item Written in the same step by the storing function Structural
Rate limits Counted inside the storing function, which answers a refusal without recording it as a failure Structural
90-day deletion Scheduled database job, shipped before any sending is possible Structural
Deletion on withdrawal, account deletion and group deletion Deleting function; cascading foreign keys Structural
Included in the member's data download The download reads the member's own items through their own session Structural (row rule), test-pinned
Our team reads items but not who sent them A dedicated reviewing role with read access to the item, rating, comment, kind, version, level and date only — not the account or group Structural
The reviewing role cannot change or delete items Read-only grant Structural
No rating or "reviewed" state is shown to anyone No column records a review, and a source scan refuses any screen reading a rating Conventional, test-pinned
Items never reach a model No code path; a check that our assistant server never reads the table Conventional, test-pinned
The email carries no account, group or consent The delivery function selects only the reviewing role's columns, and the service role holds no read on the others Structural (column grant), test-pinned
A failed email never loses the item The item is stored by submit_feedback first; the delivery function may only stamp emailed_at or count attempts Structural (column grant)
The emailed copy is deleted By hand, from our inbox Policy
No one at GroupApp reads group content except items sent to us Policy commitment and our operator-access rule Policy

7. Best interests of the child

A member under 16 cannot send, so a child's own words never reach our team through this route.

Children can still be mentioned in an adult's item. Replacing tracker names with "a child" removes the most identifying part; descriptions we cannot recognise remain, and since the preview was dropped nothing shows them to the parent before sending. We judged that giving a parent a narrow, visible way to report something that went wrong with a child-related answer — a wrong feed time, a mislabelled dose — serves the child better than having no route, provided the route is one item, with the names we hold replaced, and stored for 90 days.

A 16- or 17-year-old may send their own items, on the same terms as an adult. That respects their autonomy over their own words; they cannot send anything written by anyone else.

8. Residual risk we accept

9. Review trigger

10. Checklist against exposure draft s 38(2)

s 38(2) Requires Answered in
(a) nature, scope, context, flow and purposes §§1–3
(b) why collection is strictly necessary §2
(c) lawful and fair means §4
(d) best interests of the child §7
(e) how the entity complies with the Code and the Act §4, §6
(f) risk of harm to children §5, §7

11. Sources

Primary:

Our own code and documents: