Trust and privacy at Arkrooms™

What Arkrooms does, and doesn't, vouch for

Arkrooms builds a proposed schedule and checks it against your church's settings (two adults in a room, a woman in each room, training, background checks, ratios, your own rules) using what Planning Center says. It doesn't certify that a room is staffed safely or that your requirements are met. A team leader or admin reviews each schedule and approves it, and that approval is their confirmation, not Arkrooms'. The checks are only as current as the data behind them (a background check entered late, a training date never recorded), and they can't see who is actually in the room on Sunday. The live counts and alerts during services are an aid to the people watching the rooms, not a guarantee.

What Arkrooms stores

• Planning Center IDs, not names, in schedules. A schedule records which person serves in which room by their Planning Center ID. Names are filled in from Planning Center each time a page is shown.
• What your volunteers and leaders do in Arkrooms: sub requests and trades (by Planning Center ID, a reason from a short list such as "away" or "unwell", and any note, which only the team's leaders and admins see and which is deleted two weeks after the Sunday), no-show marks, sign-ups, reminder choices and calendar-feed settings. Pictures you upload (floor plans, room setups, logos) are saved without the location or device a phone records.
• Your church's setup: rooms, floor plan, rules, teams and services, branding.
• A record of who changed what (the audit log), so admins can see who approved or changed a schedule.
• Counts for stats: how many subs were asked for, covered and taken, per person and month, with no names, notes or dates.
• Badges: which badges each volunteer has been shown (like "10 Sundays"), by Planning Center ID. Badges are worked out from the schedules; each volunteer sees only their own, and nothing is ranked.
• Getting started: the dates your church first reached each setup step (signed up, connected, first schedule and so on), so we can see where churches get stuck. Dates only, no people.
• Emergency alerts (if your church turns them on): which kind of alert was started at which service, by whom and when; never a child's name or description.
• Room checklists (if your church adds them): which room's after-session checklist was done on which Sunday, by whom and when.
• Recurring tasks (if your church adds them): which task, such as disinfecting the toys, was marked done, by whom and when. Kept a year.
• Signed policies (if your church adds them): your church's own documents, such as its child protection policy, and for each person who signed: which version, when, and the name they typed. Nothing else; forms that ask for a Social Security number, birthdate or address stay with your church's screening provider.
• Fire drills (if your church turns them on): when each drill was run and how long it took, which adults were in each room (by Planning Center ID), and how many children: a number from the Check-Ins head count, never a name. Admins see the history.
• Mandated reporters (if your church asks): whether you said you're a mandated reporter by profession, yes or no, by Planning Center ID. Only your admins see it.
• Benchmarks (hosted churches, unless an admin turns them off): your church's monthly totals (rates like the sub rate, never anything about a person), combined with other churches only when five or more take part, so an admin can see how you compare. No church is ever named in the combined numbers.
• Don't schedule (if your admins use it): that an admin paused someone from being scheduled, until when, and which admin, by Planning Center ID. No reason is ever asked for or kept, and only admins see it; to everyone else the person is simply away.
• Onboarding (if your church turns it on): that an admin marked a new volunteer ready to serve, which admin and when, by Planning Center ID. The checklist's other steps (policies, training, background check) are read where they already are, so nothing else is kept. A new volunteer still working through the steps 3 weeks after joining their team gets one reminder of what's left; when they joined is read from Planning Center, not kept.
• Your choices: the emails and texts you turned off, the features about you that you hid, and a break's end date, by Planning Center ID, only if you changed anything (My choices).
• If you step off a team: your leader may be asked once why (moved, a season of life…). Only a yearly count of the answers is kept, never with your name or ID; that the question was asked is kept 120 days, so it isn't asked twice.
• People to ask (if your church turns it on): your admins' marks on a short list of people worth asking to serve (asked, not now, not a fit), by Planning Center ID, and a record of each ask (when, by which admin, and how), kept for one year so nobody is asked again and again. Only admins see the list, and only when they ask for it. If an admin emails someone from it, Arkrooms sends it for them (the address looked up in Planning Center when it's sent, never kept) and counts how many were sent each quarter, with no names. If your admins add parents of children who come regularly, Arkrooms reads Check-Ins and households for it at the moment, and keeps none of it.
• Sign-in sheets: a paper sheet per room of the children who come regularly, for the coming Sunday, made when an admin or that room's leader asks: names and grades read from Check-Ins at the moment, printed, and kept nowhere.

• Instant roster updates (if an admin turns them on): Planning Center's webhook subscriptions for your church, with their secrets encrypted. A delivery only tells Arkrooms to reload your roster; nothing in it is kept.

What Arkrooms never stores

• Anything about children. Check-Ins is read for head counts per room; a room's checked-in children are read only live, for pickup or an incident report, and no child's name or check-in record is kept. If your church turns on the rule about a parent serving in their own child's room, the children's birthdates in a volunteer's household are read to work out which room is their child's, kept in memory only and never written down; the children's names aren't read.
• Pickup. If your church turns it on, the room's checked-in children are shown live to that room's volunteers during the service, to match each parent's tag to the child; nothing about the children is kept. By default nothing is kept about a release either; a church can choose to keep each release for one year, with only the Check-Ins check-in number, who released and when.
• Incident reports. If your church turns them on, they go to your own form or into Planning Center as a note on the child's record (below); Arkrooms keeps no copy, not even which child. To pick the child, the leader filing sees the room's checked-in list, read live with their own Planning Center sign-in and never kept.
• Contact details. No email addresses, phone numbers, street addresses or birthdates. (Birthdates are read from Planning Center to tell teens from adults and, if your church sets one, to check its minimum age to serve; they're kept in memory only.) When Arkrooms sends an email or a text, it looks the address or number up in Planning Center at that moment.
• Photos. If your church turns on photos on the room map, each volunteer's Planning Center profile photo is shown from Planning Center's photo host; Arkrooms keeps neither the photo nor its address. Anyone can hide their own photo on My choices.
• Passwords. Everyone signs in with their own Planning Center account.
• Card numbers. When paid plans start, payments are handled by Stripe; Arkrooms never sees a card number.
• Names beside an ID. Requests, trades, sign-ups, the emails' records and the activity log keep Planning Center IDs; names are looked up when they're shown, so someone renamed or removed in Planning Center is too.
• Email text for long. The subject and text of each email are removed 3 days after it's sent.
• Names in error logs. When something goes wrong, the app's logs keep where in its code it happened and the kind of error, not the error's message, which could carry a name.
• Real people in the source code. Arkrooms' tests and sample data use made-up names; no church's volunteer list is kept in the code.

Who can see what

• Volunteers see their own schedule, their team's Sundays and their own requests.
• Team leaders see their team's schedules, subs and stats, and the Sunday view of the rooms. They see whether each person's training is current, due or expired, not the dates, which only admins and the person see.
• Teens on teams appear to the adults on the schedule as Planning Center shows them, by name and as a teen helper; nothing else about a minor is kept.
• Admins your church chooses see and change everything for your church, and every January get the list of admins to review.
• Roles follow Planning Center. Someone taken off a team, or no longer an admin, loses access at once, not when their sign-in expires. Sessions last 12 hours; a volunteer or leader can choose 30 days on their own phone, admins never can, and your church can turn that option off.
• Other churches can't see yours. Every church's data is separated in the database itself (row-level security), each church has its own address and sign-in, and tests check that nothing crosses between churches.
• Mediocre Technologies, which makes Arkrooms, has one operator who can reach the hosted database, for support and recovery only. The operator's console shows each church's health and counts, never names or schedules, and every look at your church shows in your Activity as "Arkrooms support". Only if one of your admins allows it (Settings, for 24 hours), support can open your church as an admin sees it, read-only, for 2 hours at most: it can't change anything or reach Planning Center, every admin is emailed when it starts, and turning it off ends it at once.

Where it lives

• Amazon Web Services, in the United States (US East, Northern Virginia).
• Encrypted in transit and at rest: HTTPS everywhere (with HSTS), TLS to the database, and the database service encrypts its storage and backups. Planning Center sign-in tokens are encrypted again by the app.
• Backups are the database service's own automatic backups, with point-in-time restore.

The Planning Center connection

Arkrooms connects to Planning Center with OAuth, through an admin's own Planning Center sign-in, and asks for:

• People: the roster, teams and who leads them, training dates (and the dates of any other certification your church lists, from the custom fields it names), and, if your church requires checks, whether each person's background check is clear and when it expires (never the report); a church without a screening provider can instead keep each check's date in a People field it names.
• Services: the teams' schedules and who declined; publishing an approved schedule.
• Calendar: your rooms, so the floor plan and setups match.
• Check-Ins: head counts per room, for ratios and attendance trends (numbers only), from label check-in or Planning Center Headcounts; if your church turns on the welcome, which volunteers checked in today (by Planning Center ID, read and dropped), so each gets their assignment; for an incident report, only the names of the children in that room, read live and never kept (never medical notes or security codes). A church without either can have its leaders count each room in Arkrooms instead: the number is kept for 30 days, then only the Sunday's total.

If your roster comes from a Planning Center Group or People list instead of Services teams, Arkrooms keeps who leads and who teaches each team (those don't say), and nothing else about the team.

If your admins build your teams in Arkrooms (the Team builder), the draft keeps only Planning Center IDs, each person's team and role, until a week after it's applied to Planning Center or thrown away.

Training classes an admin plans are kept a month after the class, with who was invited and their answer; the new training date for those who came is written into Planning Center (as the admin), never kept in Arkrooms.

If your admins turn on Add a family, the people they enter are created in Planning Center People with their own sign-in; Arkrooms keeps nothing from the form.

Someone who uses the Planning Center tools without an Arkrooms account signs in with Planning Center; the sign-in stays in their browser, and Arkrooms keeps only the name, email, church and role they type in, and whether they said yes to follow-up emails. Nothing from Planning Center is kept.

Each admin's email address is kept, taken from Planning Center while the connection works, only to send them the account notices that must reach them when Planning Center can't be asked: that it was disconnected, and that the church is closing or was kept. Someone who stops being an admin is dropped.

Spreadsheets an admin imports (a roster, background check or training dates) are read and shown back, never kept; what they apply is written into Planning Center as them. An email in the file can be looked up in Planning Center to tell two people with the same name apart; it isn't kept either.

If your church keeps background-check dates in a People field, an admin can set someone's date from Teams; it's written into Planning Center as that admin, and Arkrooms records that the field changed, not the date. Only admins see the dates; leaders see only whether someone is cleared.

Away dates a volunteer marks in Arkrooms are kept until they pass; if your church turns it on, they also go into Planning Center as that volunteer's own blockouts, written with their own sign-in.

An admin can send someone else a one-time link to connect Planning Center (it works for 7 days); Arkrooms keeps only the link's fingerprint and who made it, and never the address it was sent to.

Arkrooms reads. It changes Planning Center only when a leader publishes a schedule they approved, or an admin chooses a fix on the discrepancies page or changes someone's training, availability or check date from Teams; each is done as that signed-in person, is previewed first, and never removes anyone. If your church chooses to have incident reports written into Planning Center, the leader filing one adds a note to the child's People record, in the note category your admins chose, as themselves and only with the permissions Planning Center already gives them. An admin can disconnect Planning Center at any time, from Arkrooms or from Planning Center's own Integrations page; disconnecting, or signing out, ends Arkrooms' Planning Center tokens there too.

How long it's kept, and deleting it

• Sub requests, trades and sign-ups: deleted 90 days after the Sunday.
• Email subject and text: removed after 3 days; the record of the send after 90 days.
• Older versions of a schedule and the audit log: deleted after a year.
• Recurring tasks marked done: deleted after a year, except each task's latest.
• Expired sign-ins: deleted.
• Download everything: your admins can download all of your church's data as one file, at any time, from Settings → Your church's data.
• Forget someone: once a person is off every team in Planning Center, an admin can have Arkrooms remove them: their ID comes out of every schedule (their places show as "Former volunteer") and their requests, trades, settings and messages are deleted.
• Close your church: your admins can close your account from the same page. Planning Center is disconnected at once, every admin is told, and a week later everything is deleted, unless an admin keeps the church first.

Who else handles your data (subprocessors)

• Amazon Web Services: hosting, the database and its backups; Amazon SES sends email and AWS End User Messaging sends texts (to leaders and admins who turn texts on). They receive what's needed to deliver each message: the address or number, and the message.
• Planning Center (Ministry Centered Technologies): your church's own account, which Arkrooms reads.
• Stripe: payments, once paid plans start. It receives the billing contact and card details you give it.
• GitHub: feature requests sent from Help → Suggest a feature, in a private tracker, labelled with your church's short name (so we can see how many churches ask for the same thing) and with no name or email attached, and the gaps a policy review finds, when an admin sends them.
• AI (currently Anthropic): the policies an admin uploads for a policy review, only after an admin agrees, feature requests (Help → Suggest a feature, with no name attached), which may be reviewed by an AI model, and floor plan pictures an admin chooses to have drawn automatically (Draw it for me: only the part of the building they picked, with no personal data, and nothing kept). It doesn't train on them. If we add or change an AI provider, we'll update this list first.

Arkrooms has no advertising or third-party tracking, and doesn't sell or share data.

If something goes wrong

• Is Arkrooms up? Live status, checked from outside our hosting every 5 minutes: https://stats.uptimerobot.com/XEmd98RTkF
• Report a security problem through the address in the app's /.well-known/security.txt, or to hello@arkrooms.com.
• If your church's data is exposed, we'll email your admins what happened, what data, and what we're doing about it within 72 hours of confirming it.

What we don't have yet

• No SOC 2 report or other third-party audit.
• No external penetration test yet; results will be summarized here when there is one.
• The hosted service is in early access, with a small number of churches.

Questions this page doesn't answer: hello@arkrooms.com.