Planning Center Registrations Data Model

OverviewCopy Anchor Link

The Registrations module contains 11 entity tables and 3 relationship tables supporting event registration, attendee management, emergency contacts, and signup tracking.

Complete Schema ReferenceCopy Anchor Link

This guide provides a comprehensive reference for all Planning Center Registrations tables available in Parable. Understanding this data model will help you write accurate queries and build meaningful reports for your event management needs.

Visual Data ModelCopy Anchor Link

Core Entity RelationshipsCopy Anchor Link

Open diagram in new tab →

Key Relationships ExplainedCopy Anchor Link

Registration Structure:

• REGISTRATION defines an event or program accepting signups
• CATEGORY organizes signup options (e.g., T-shirt size, Meal preference)
• SELECTION_TYPE provides specific choices within categories

Signup Flow:

1. Person creates a SIGNUP for a registration
2. ATTENDEE(s) are added (self or others)
3. SIGNUP_TIME(s) specify when attendees will participate
4. SIGNUP_LOCATION(s) define where events occur
5. EMERGENCY_CONTACT(s) provide safety information

Person vs Attendee:

• PERSON is the signup submitter (from People module)
• ATTENDEE can be the submitter or someone else (child, guest, etc.)
• One signup can include multiple attendees
• Each attendee has their own emergency contacts

Time and Location:

• SIGNUP_TIME tracks session/workshop times
• SIGNUP_LOCATION tracks event venues
• Both linked to parent signup, not individual attendees
• Supports multi-day, multi-location events

Generic Relationship Pattern:

Registrations has three relationship tables:

• registrations_signups_relationships — signup → campus, category, signup location, signup times
• registrations_registrations_relationships — registration → signup, created-by person, registrant contact
• registrations_attendees_relationships — attendee → person, registration, selection type, emergency contact

An attendee has no direct Signup relationship. To go from an attendee to its signup, hop through the registration: attendee -[Registration]-> registration -[Signup]-> signup.

AND ar.relationship_type IN ('Registration', 'registration')

Query RequirementsCopy Anchor Link

Schema PrefixCopy Anchor Link

IMPORTANT: All tables in the Planning Center Registrations module are in the planning_center schema. You MUST prefix all table names with planning_center. in your queries.

✅ CORRECT: SELECT * FROM planning_center.registrations_signups ❌ INCORRECT: SELECT * FROM registrations_signups

Row Level Security (RLS)Copy Anchor Link

This database uses Row Level Security (RLS) to automatically filter data based on:

• tenant_organization_id: You only see data for your current organization
• system_status: You only see 'active' records by default

DO NOT add these filters to your WHERE clause - they are applied automatically:

• ❌ WHERE tenant_organization_id = 1 (unnecessary)
• ❌ WHERE system_status = 'active' (unnecessary)

The RLS policies ensure you only access data you're authorized to see, making these filters redundant and potentially causing performance issues.

Entity TablesCopy Anchor Link

registrations_signupsCopy Anchor Link

Event signup forms and their configuration.

registrations_attendeesCopy Anchor Link

Individual attendee records for events.

registrations_registrationsCopy Anchor Link

Registration submissions with the final cost after discounts, payments received, and outstanding balance across every attendee in the registration.

registrations_categoriesCopy Anchor Link

Event categories for grouping and filtering.

registrations_selection_typesCopy Anchor Link

Pricing tiers and registration options.

registrations_signup_locationsCopy Anchor Link

Event venues with geographic coordinates.

registrations_signup_timesCopy Anchor Link

Event date and time slots.

registrations_emergency_contactsCopy Anchor Link

Emergency contact information for attendees.

registrations_peopleCopy Anchor Link

Basic person information for registrations.

registrations_campusesCopy Anchor Link

Church campus locations.

registrations_organizationsCopy Anchor Link

Organization settings and configuration.

Relationship TablesCopy Anchor Link

registrations_signups_relationshipsCopy Anchor Link

Links signups to related entities (categories, campuses, locations, times).

Relationship Types:

• Category - Links to registrations_categories
• Campus - Links to registrations_campuses
• SignupLocation - Links to registrations_signup_locations
• SignupTime - Links to registrations_signup_times

registrations_registrations_relationshipsCopy Anchor Link

Links registrations to related entities.

Relationship Types:

• Signup - Links to registrations_signups
• Person - Links to registrations_people

registrations_attendees_relationshipsCopy Anchor Link

Links attendees to related entities.

Relationship Types:

• Signup - Links to registrations_signups
• Registration - Links to registrations_registrations
• EmergencyContact - Links to registrations_emergency_contacts

System FieldsCopy Anchor Link

All tables include these system fields for data management:

• system_status - Tracks data lifecycle:

  • transferring - Data being synced from Planning Center
  • active - Current, queryable data
  • stale - Outdated data pending removal

• tenant_organization_id - Ensures data isolation between organizations

• system_created_at - When Parable first received this record

• system_updated_at - Last sync timestamp

Row Level SecurityCopy Anchor Link

All tables implement Row Level Security (RLS) policies that:

1. Filter data to only show active records
2. Restrict access to the authenticated organization's data
3. Ensure complete data isolation between tenants

Data Integrity RulesCopy Anchor Link

1. Schema Qualification: Always use planning_center. prefix for all table references
2. Row Level Security: RLS automatically handles multi-tenancy and status filtering - do not add manual filters
3. Monetary Values: Cost and fee columns are stored in cents - divide by 100.0 for display
4. Registration Status Flags: Use booleans like archived, canceled, and waitlisted to control visibility instead of relying on system_status
5. Direct ID Columns: Core tables like registrations_signups expose direct ID columns for performance-critical joins

Common Mistakes to AvoidCopy Anchor Link

1. Missing Schema Prefix

   • ❌ FROM registrations_signups
   • ✅ FROM planning_center.registrations_signups

2. Adding Redundant RLS Filters

   • ❌ WHERE tenant_organization_id = 1 AND system_status = 'active'
   • ✅ Trust RLS to handle this automatically

3. Joining Without Schema

   • ❌ JOIN registrations_attendees a ON ...
   • ✅ JOIN planning_center.registrations_attendees a ON ...

4. Skipping Currency Conversion

   • ❌ SELECT total_cost_cents as total_cost
   • ✅ SELECT total_cost_cents / 100.0 as total_cost

Performance ConsiderationsCopy Anchor Link

1. Indexes: All tables have optimized indexes on:

   • Primary keys and entity IDs
   • Join columns and foreign keys
   • Date columns for time-based queries

2. Query Optimization:

   • Always use the planning_center. schema prefix
   • RLS handles tenant and status filtering automatically
   • Filter registration status flags when relevant
   • Consider CTEs for complex aggregations
   • Join through the *_relationships tables — entity tables carry no foreign-key columns

Best PracticesCopy Anchor Link

1. Always join through relationship tables - Relationship tables capture many-to-many links between events and related entities
2. Trust RLS policies - Skip manual tenant_organization_id or system_status filters
3. Use Planning Center IDs for lookups - The *_id fields (e.g., signup_id)
4. Consider NULL values - Many fields may be NULL if not provided by Planning Center
5. Handle timestamps properly - All timestamps are stored in UTC

Example: Complete Event Details QueryCopy Anchor Link

-- Get full event details with all related data
SELECT 
    s.signup_id,
    s.name as event_name,
    s.description,
    s.open_at,
    s.close_at,
    cat.name as category,
    camp.name as campus,
    loc.name as location_name,
    loc.full_formatted_address,
    tim.starts_at as event_start,
    tim.ends_at as event_end,
    tim.all_day
FROM planning_center.registrations_signups s
-- Join category
LEFT JOIN planning_center.registrations_signups_relationships sr_cat
    ON sr_cat.signup_id = s.signup_id 
    AND sr_cat.relationship_type IN ('Category', 'category')
LEFT JOIN planning_center.registrations_categories cat
    ON cat.category_id = sr_cat.relationship_id
-- Join campus
LEFT JOIN planning_center.registrations_signups_relationships sr_camp
    ON sr_camp.signup_id = s.signup_id 
    AND sr_camp.relationship_type IN ('Campus', 'campus')
LEFT JOIN planning_center.registrations_campuses camp
    ON camp.campus_id = sr_camp.relationship_id
-- Join location
LEFT JOIN planning_center.registrations_signups_relationships sr_loc
    ON sr_loc.signup_id = s.signup_id 
    AND sr_loc.relationship_type IN ('SignupLocation', 'signup_location')
LEFT JOIN planning_center.registrations_signup_locations loc
    ON loc.signup_location_id = sr_loc.relationship_id
-- Join time
LEFT JOIN planning_center.registrations_signups_relationships sr_tim
    ON sr_tim.signup_id = s.signup_id 
    AND sr_tim.relationship_type IN ('SignupTime', 'signup_time')
LEFT JOIN planning_center.registrations_signup_times tim
    ON tim.signup_time_id = sr_tim.relationship_id
WHERE s.archived = false
ORDER BY tim.starts_at DESC;

This query demonstrates how to properly join multiple related entities through the relationship tables to get complete event information.