Safeguarding
Who may collect a child, decided in the database.
When your church turns on check-in, staff record who may and may not collect each child. The gate re-runs at release. A deny always wins.
- Deny overridable
- Never
- Decision re-run
- Inside the release
- Clearances
- Attestations, with expiry
What it does
The decision is made at the door, in the database
When your church turns on check-in, staff record who may collect each child and who may not. The gate runs again inside the same write that releases the child, so a restriction added after the screen was drawn still applies.
A deny always wins
Not by a volunteer, not by staff, not by merging two member records: a deny is never overridable. Someone who is simply not on the list can be approved only by an owner or admin, with a note, and that is recorded.
Nobody learns another family’s arrangements
To the person at the door, not on the list and denied look identical. The reason behind a restriction never leaves the database, and a parent sees only their own child’s approved list.
A restriction survives
Merging two records moves every restriction across unconditionally, revoked rows included, and a merge that would collapse a restriction into a self-deny is refused. Erasing the restricted person does not erase the restriction.
Volunteer clearances with an expiry
Your church declares which clearances its policy requires. A named staff member records that a verification completed elsewhere, with an expiry date. The platform stores no result: a record inside its window means cleared, its absence means not cleared.
The door refuses a lapsed clearance
A group leader may operate a check-in session only while every required clearance is current. That eligibility is re-checked inside the check-in and check-out writes themselves, so a clearance revoked between the screen and the door still stops the action.
See who would be blocked before you enforce
The safeguarding dashboard lists each clearance kind and each volunteer’s status, and the This week dashboard surfaces leaders whose clearance is missing or expiring, so nobody discovers a gap at the door.
A schedule is a plan, not an authorisation
Putting someone on the nursery rota does not let them through the check-in door. The door is gated by a current clearance and an active leader role, never by the rota.
A closer look
The short answers.
What is a volunteer clearance?
A record that a verification completed elsewhere, with an expiry date. A named staff member records it; the platform stores no result, status or outcome, only a pointer to the system that holds the case. Inside its window the volunteer is cleared to operate check-in; outside it, the door refuses.
How does pickup authorisation work?
When your church turns on check-in, staff record who may collect each child and who may not. The decision is made in the database as the child is released, so it reflects the records as they stand at that moment rather than when the screen was drawn. A deny is never overridable, and only an owner or admin can approve someone who is not on the list, with a note.
What happens if a restriction is added after the child was checked in?
It applies. The gate re-runs inside the check-out write itself, not only on the screen, so a restriction recorded minutes earlier still blocks the release.
Can a parent see who is restricted?
No. A parent sees only their own child’s approved list. Restrictions, and the reasons behind them, are never shown to parents and never leave the database.
Does rostering a volunteer on the children’s team clear them?
No. A schedule is a plan, not an authorisation. Operating a check-in session requires a current clearance of every kind your church declares, plus an active leader role on that group, and both are re-checked inside the write.
Which plan includes check-in?
Check-in with the custody gate is on the Team and Enterprise plans. Custody records and volunteer clearances live in the directory on every plan. During early access every church gets every feature free.