Before collecting a member’s location, church leaders should be able to explain what is collected, who can see it, why it is needed, how long it remains, and how members can refuse or correct it. If those answers cannot be given in plain language before check-in, the church is not ready to collect the data.
Imagine Efua, a composite member, standing outside a conference venue in Accra at 7:14 on Saturday morning. She is holding her registration code while two ushers guide the queue ahead of her. The church app asks for her location so it can confirm that she is close enough to check in.
She taps Allow, enters the auditorium, and finds her seat.
Later, during the opening session, a harder question arrives: “Can my group leader see where I am now?”
Efua cannot tell whether the app captured one location at check-in or continues tracking her. She wonders whether an usher, pastor, software provider, or anyone with dashboard access can open a map and find her. The possibility changes how the morning feels. A tool intended to confirm attendance has created doubt about surveillance.
Define exactly what the app collects and when
The first privacy question is: what data are we collecting?
“Location data” is too broad. A useful explanation should distinguish between a one-time GPS reading and continuous background tracking. It should also say whether the system saves exact coordinates, calculates a distance and discards the coordinates, or records only that the member was within the permitted check-in area.
ChurchFlow supports location-based conference check-in. The member’s phone captures their position, and the backend validates whether they are within the conference’s configured radius. That purpose is specific: preventing remote check-ins. Church leaders still need to decide and document what location details remain after validation.
The second question follows immediately: when does collection begin and end?
Permission should match the task. If location is needed when a member presses “Check in,” explain that it is requested for that moment. Avoid language that leaves members wondering whether the app follows them after they enter the venue, travel home, or attend another event.
This distinction matters because people often treat an operating system permission as a description of the whole practice. It is only a technical prompt. Your church must provide the human explanation.
Limit who can see the record and why
The third question is: who can access this information?
“Authorized staff” tells Efua almost nothing. Name the roles. Perhaps designated conference administrators can review check-in records while volunteer ushers can only see whether a registration succeeded. A branch leader may need attendance totals without seeing coordinates. A software support person may need controlled access to diagnose an error.
Give each role the smallest view required for its work. An usher scanning codes does not need the same access as the conference administrator. A pastor checking attendance patterns does not automatically need a member’s precise check-in location.
This is where privacy and operational discipline meet. Miriam’s overexposed member database shows how broad access can place both members and church plans at risk.
The fourth question is: how long will the church keep the data?
“Forever” is usually a default, not a reason. A check-in result may support attendance reporting, safeguarding, or resolving a registration dispute. Exact coordinates may have a much shorter useful life, especially after the system has confirmed that the member was inside the permitted area.
Set a retention period for each kind of record. Then make deletion part of the system’s routine rather than a promise someone must remember months later.
Give members a real choice and a clear correction path
The fifth question is: what can a member do if they decline, change their mind, or find an error?
A location permission becomes coercive when refusing it means missing the conference. Provide another path, such as an administrator checking the member in through their registration record. Explain any extra step honestly, without making the member feel disobedient or suspicious.
Members also need a way to ask what was recorded, report an incorrect check-in, and request correction or deletion where appropriate. Publish a contact route that reaches someone responsible for data decisions. “Speak to any usher” is unlikely to work once the conference ends and the temporary team disperses.
Churches should apply the same discipline to other sensitive records, including prayer requests, pastoral notes, giving history, group membership, and volunteer roles. A recent report that the pope’s prayer app had leaked users’ information for months offers a sobering reminder: spiritual purpose does not reduce the harm caused by weak data practices. Sensitive context can increase it.
For a broader approach to permissions and collecting only what is needed, see a plain-English guide to data minimization, permissions, and privacy for African churches.
Put the explanation beside the decision
Before the next conference, write a short notice that answers all five questions. Place it beside the location request and give volunteers the same wording, so members receive one consistent explanation.
When Efua reaches the next check-in screen, she sees a simple message: her location will be checked once to confirm she is near the venue, the notice names who can access the resulting record, and manual check-in remains available. She chooses with enough information.
Then she puts her phone away and joins the conference without wondering who is still watching.
Comments
No comments yet.