RSVP Module Guide

Purpose

The RSVP module is the attendance layer for Tov+. It sits on top of the Occasion-first model and lets planners manage who is invited to which Events, while guests respond through one low-friction flow that can cover a person, household, or group.

Core behavior

• RSVP is installed at the Occasion level.
• RSVP is enabled per Event through the shared module platform.
• Eligibility is invitation-driven.
• Responses are stored per invited Event.
• Shared-response control is defined by response_scope plus the invitation unit actor.

Invitation model

• rsvp_invitations is the RSVP-owned invitation record.
• It can link back to the broader guest-access invitation through occasion_invitation_id.
• primary_actor_id identifies the main invited actor.
• invitation_unit_actor_id identifies the household/group controller when the response should cover multiple people.
• invited_event_ids is the planner-defined eligibility set.
• Guests only see RSVP-capable Events that are both invited and allowed by their guest token.

Response model

• rsvp_responses stores one response per invitation unit and Event.
• Baseline statuses are pending, attending, and declined.
• Responses include event scope, response scope, participant actor ids, responder actor id, source, optional notes, and optional linked form ids.

Shared and group response behavior

• actor scope means the guest responds only for themselves.
• household scope means the invitation unit actor controls the response for its child memberships.
• group scope is the same baseline pattern but for non-household group actors.
• This supports one spouse responding for both spouses, a parent responding for household members, or a single guest responding only for themselves.

Forms integration

RSVP uses dedicated attendance primitives plus optional linked guest Forms.

• RSVP status stays in RSVP records.
• Event-specific questions stay in Forms.
• Event RSVP enablement can declare linked_form_id.
• Guest submission writes RSVP state first-class and stores the linked form submission alongside it.

Planner flow

• Review Event-level RSVP summaries.
• Create or edit invitation units.
• Choose the response scope and invited Events.
• Inspect existing responses per invited Event.
• Apply planner overrides when a response record already exists.
• Review linked-form configuration through Modules and Forms surfaces.

Guest flow

• Guest access remains token-first and occasion-first.
• The guest RSVP route shows only invited Events that the current token may access.
• A guest can answer all invited Events in one flow.
• Linked RSVP questions appear inline for the matching Event.
• Saved responses can be reopened and updated.

Permission rules

• rsvp:view allows planner-side response visibility.
• rsvp:manage allows invitation management.
• rsvp:override allows planner-side response corrections.
• Guests can only view and submit through a valid token tied to the Occasion and invitation unit.
• Vendors and unrelated actors do not receive RSVP visibility by default.