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.

For non-technical users, 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).

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.

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