Attendance

Overview

Attendance is built for live event operations. It helps your team choose the right event, confirm that the event is currently active, check people in quickly, manage attendees during the service, and review high-level attendance numbers afterward.

The page is organized around two working rhythms. First, your team selects an event and runs check-ins while the event is happening. Second, your team reviews attendee records and summary cards so leaders can confirm how many people attended, what mix of members and visitors showed up, and whether any check-outs or cleanup actions are still needed.

The easiest way to think about this module is: pick the event, run check-in, monitor the room, then review the numbers.

Event Selection And Filters

The left side of the page helps operators narrow down the event they want to work on. Holy Resource supports search plus multiple filter layers, including status, event type, service type, and date range. This matters because attendance is often a live workflow. The team needs to find the correct event quickly, especially when there are recurring services, past events, and upcoming events in the same list.

Events with multiple services are treated carefully. If an event stores multiple service times, the page parses those service entries and lets the user work at the service level instead of flattening everything into a single generic check-in view. That is what makes it possible to track one service separately from another when needed.

What The Filters Help You Control

• Search: find an event by name, location, or description.
• Status: narrow the list to active, scheduled, completed, or other event states already in your data.
• Event type: separate recurring events from one-off events.
• Service type: isolate events with single-service or multi-service setups.
• Date range: keep the list focused on today, this week, this month, past events, or a broader operational window.

Quick Check-In Panel

Once an event is selected, the right side of the page becomes the live check-in workspace. The app validates whether the selected event is currently active and shows a clear status alert before letting the operator continue. If the event is not currently happening, check-in is blocked instead of quietly creating bad attendance data.

This is not just a visual rule in the page. The backend also refuses bulk check-ins for events that are not currently happening, which keeps the data model aligned with what staff see on screen.

QR Check-In

For a faster front-door flow, the module supports QR-based attendance. Staff can open the scanner, process a QR code, and record attendance against the selected event. The page also includes an attendance QR generator so teams can display a code for event-specific check-in flows.

When a service is selected inside a multi-service event, the check-in is tied to that service window rather than only the parent event. That keeps service-specific attendance totals cleaner.

There are two practical QR workflows:

• Staff scanner flow: a staff member scans attendee QR content using the in-app scanner.
• Public self check-in flow: attendees scan the generated event QR and open a hidden public check-in page on the docs website (/c/{token}).

The public self check-in route is intentionally not shown in app navigation. It is designed for front-door usage only (via QR), including guests and members who do not want to install the app.

Public Self Check-In (Hidden /c/{token} Route)

When staff generates an attendance QR code, Holy Resource requests a short-lived attendance session from the sync server and embeds that session token into the QR URL. The URL follows this pattern:

• /c/{token}

What happens on that page:

• The attendee enters their full name.
• They can add contact details and an optional note.
• If staff enabled an on-site code gate while generating the QR, the attendee must enter that on-site code.
• The request is validated server-side (token validity, session expiry, optional anti-abuse checks).

Website Link And Embed Code

The Quick Check-In panel also includes actions for church websites:

• Copy Website Link creates a public check-in URL for the selected event.
• Copy Embed Code creates an iframe snippet you can paste into a web page.

These actions are available when the church has:

• a Pro or Network license tier, and
• server sync enabled in General Settings.

If either requirement is missing, the page keeps attendance operations available while website embed actions stay disabled.

Registered Member Matching Guidance

The public attendance page includes a lightweight toggle:

• Are you already a registered member?

When this is enabled, attendees are expected to provide valid contact details (email or phone) exactly as stored in church records. This improves matching quality for member check-ins without forcing app installation.

What to tell attendees:

• If you are a member, turn on the registered-member option.
• Enter a valid phone number or email tied to your church profile.
• Use optional notes only for extra context, not identity.

What staff should expect:

• Better member matching quality when contact data is provided correctly.
• Duplicate submissions may be safely ignored when the server marks them as duplicates.
• If token/session errors appear, regenerate the event QR and retry.

Attendance check-in sequence

Step-by-step explanation:

1. The sequence starts with the front-door or event team choosing the exact event or service that is actively in progress. That matters because Holy Resource does not treat attendance as a generic list. The record has to be tied to the correct live event context.
2. Before anyone is checked in, the Attendance module validates that the event timing is actually active. This is the same guardrail described earlier on the page: the system is designed to stop people from creating attendance records for an event that is too early, too late, or otherwise inactive.
3. After that, staff can display or generate the attendance QR code for the event. From this point onward, the flow splits into two main attendance-taking paths.
4. The first branch is the public QR path. This is the path for guests, first-time attendees, and members who do not want to install or open the app. They scan the QR code and land on the hidden public attendance page.
5. That public page does not blindly accept submissions. It first asks the sync server to validate the token and session details, including expiry and any optional on-site code requirement. This protects the church from using an old or invalid QR session by mistake.
6. Once the page is validated, the guest or non-app member fills in their details. They can provide name and contact information, and if they are already a registered member they can turn on the member toggle so Holy Resource has a better chance of matching the attendance to the existing member record.
7. The public page then submits that attendance request through the sync server. The sync server makes that attendance record available back to the branch, and the Attendance module can show the new attendee in the roster for the event.
8. The second branch is the signed-in app-user path. This is for someone who already uses Holy Resource on their own device and wants to check themselves in from inside the app instead of scanning the public guest page.
9. In that path, the user opens the in-app Check In dialog. The app loads today's active events, reads device location when needed, and lets the user choose the correct event plus reminder settings.
10. Before the check-in is accepted, Holy Resource validates the check-in window, any required geofence, and the device's current online or offline state. This is why the in-app path can support stricter attendance controls than the public guest flow.
11. When the signed-in user confirms, the app creates the attendance record and stores an active check-in session on the device. The user then sees their active check-in state, including timer and checkout path, while the event roster reflects that they are present.
12. In plain language, the big idea is that Holy Resource supports both hospitality-first attendance and member/self-service attendance at the same time. Guests can use the lightweight browser QR route, while signed-in users can use the richer in-app flow with device-aware validation.

Manual Member And Visitor Check-In

The manual flow supports two modes. Staff can search active members and select multiple people for member check-in, or they can switch to visitor mode and capture a guest name for a simpler front-desk workflow.

The member flow is designed for speed. Operators can search the active member list, tick multiple people, and submit them together. The visitor flow is intentionally lighter so a church can capture attendance without forcing a full visitor profile before the person is even seated.

For hybrid operations, churches can run manual check-in at staffed desks while also showing the public QR for self check-in lines. This works well when a mix of members and guests arrive at the same time.

Attendees List And In-Service Management

After check-ins begin, the attendees table becomes the live roster for that event or selected service. It shows who is checked in, whether they are recorded as a member, visitor, or volunteer, how they checked in, and whether they have already been checked out.

This table is where operators correct mistakes without leaving the module. If someone needs to be checked out manually, the row action menu supports that. If a record was created in error, staff can remove it. Some check-out actions may require confirmation, and Holy Resource surfaces that confirmation instead of silently forcing the checkout.

Why Check-Out Confirmation Exists

Checkout confirmation is there to protect operators from ending an attendance record too casually. The attendance command helpers can ask whether confirmation is required before the record is updated, so teams have a safer workflow during busy services or events with longer dwell time.

The platform also exposes automatic checkout support in the attendance command layer for workflows where events ending should trigger a broader cleanup routine.

Event Summary And Reporting View

The summary section is meant for fast operational reading, not deep analytics. It shows total attendees for the selected event and breaks the count into members, visitors, volunteers, and unique families. A simple visual breakdown also helps teams see the mix at a glance without exporting data first.

The top of the page adds a second layer of context through branch-level summary cards. Those cards show total events tracked, total check-ins, average attendance, highest attendance, and current-month values so leaders can spot whether participation is moving up or down.

What The Summary Helps Leaders Answer

• How many people attended this event or this service?
• How many were members versus visitors?
• How many families were represented?
• What is the first and last recorded check-in time?
• How does current attendance compare with the branch's broader attendance trend?

Advanced Rules Behind The Scenes

Some attendance protections are not only page-level conveniences. They are backed by server-side rules so data stays consistent even if different parts of the app call the same commands.

• Attendance records are branch-scoped, so one branch cannot read or write another branch's check-ins.
• Sensitive attendance fields are encrypted at rest and decrypted on read where needed.
• Bulk check-in verifies that the related event is active before records are created.
• Geofence and location validation commands exist for events that require location-aware check-in.
• Ministry attendance statistics can be calculated for reporting windows when the church wants to review turnout for a specific ministry.

Recommended Workflow