Summit-Events-App icon indicating copy to clipboard operation
Summit-Events-App copied to clipboard
verified publisher icon SFDO-Community

Appointment Groups

Open rdblake21 opened this issue 6 years ago • 1 comments

Subtask Assigned User Complete?

Feature Request: Appointment Groups

Summary

Implement an Appointment Groups feature that allows multiple Appointment Types to be organized into logical groups with shared parameters and constraints. This will enable more flexible appointment scheduling configurations with group-level capacity management and selection rules.

Key Architectural Decision: Rather than using a traditional many-to-many junction object pattern, this design leverages a simple lookup relationship from Appointment Types to Groups. This approach:

  • Follows the existing app's architecture patterns
  • Replaces the current static Appointment_Category__c picklist with a dynamic, event-specific object
  • Is simpler to implement and maintain than a junction object
  • Provides sufficient flexibility for the expected use cases (an appointment type belongs to one group per event)

Background

Currently, Appointment Types are managed individually, which can lead to complex configurations when multiple related appointment types need to share capacity limits or have interdependent selection rules. Appointment Groups will provide a way to manage related appointment types as a cohesive unit.

Proposed Solution

Data Model

Enhance the existing Appointment_Category__c picklist concept into a proper object-based grouping system that acts as a junction between Events and Appointment Types.

Current Architecture:

  • Summit_Events__c ← Master-Detail → Summit_Events_Appointment_Type__c
  • Summit_Events_Appointment_Type__c has a simple Appointment_Category__c picklist field
  • This picklist is a Global Value Set with values like "Campus Tour", "Admissions Visit", "Faculty Visit", etc.

Proposed New Object: Summit_Events_Appointment_Type_Group__c (Replaces picklist-based categorization)

  • Name (Text) - e.g., "Campus Tour Options", "Interview Sessions"
  • Description (Long Text Area)
  • Event (Master-Detail to Summit_Events__c)
  • Active (Checkbox)
  • Group Capacity (Number) - Maximum total appointments across all types in the group
  • Min Selection Required (Number) - Minimum number of appointment types user must select from group
  • Max Selection Allowed (Number) - Maximum number of appointment types user can select from group
  • Selection Mode (Picklist):
    • Single Choice - User can select only one appointment type from the group
    • Multiple Choice - User can select multiple types within min/max constraints
    • Required - At least one selection required
    • Optional - Selection is optional
  • Display Order (Number)
  • Instructions (Rich Text) - Guidance text shown to users when selecting from this group

Modified Object: Summit_Events_Appointment_Type__c (Enhanced to reference groups)

  • Add new field: Appointment_Type_Group__c (Lookup to Summit_Events_Appointment_Type_Group__c)
  • Keep existing: Appointment_Category__c (preserved permanently for backward compatibility with existing implementations)
  • Add: Group_Display_Order__c (Number) - Order within the group
  • Add: Required_In_Group__c (Checkbox) - If checked, this specific type must be selected when group is shown
  • Add: Group_Capacity_Override__c (Number) - Optional override for this type's capacity when in this group

Why This Approach: This follows the existing app's pattern where configuration objects (like Appointment Types) hang directly off the Event with Master-Detail relationships. Rather than creating a separate junction object pattern, we're:

  1. Replacing the Global Value Set - The current Appointment_Category__c picklist is static and event-agnostic. By creating Summit_Events_Appointment_Type_Group__c as an object with a Master-Detail to Summit_Events__c, groups become event-specific and configurable per event.

  2. Using Lookup instead of Junction - Appointment Types will lookup to their Group, similar to how many other objects in this app reference their parent configs. This is simpler than a many-to-many junction and fits the use case (an appointment type belongs to one group per event).

  3. Consistency with Existing Patterns - This matches how features like Questions (Summit_Events_Question__c) and Fees (Summit_Events_Fee__c) are structured - they're Master-Detail to the Event and contain their configuration.

  4. Simpler Data Model - One new object instead of two, easier to query, and easier for admins to configure via standard Salesforce related lists.

Current vs. Proposed:

CURRENT:
Summit_Events__c
  └─ Summit_Events_Appointment_Type__c
       └─ Appointment_Category__c (picklist: "Campus Tour", "Faculty Visit", etc.)

PROPOSED:
Summit_Events__c
  ├─ Summit_Events_Appointment_Type_Group__c (new)
  │    └─ Capacity rules, selection rules, instructions
  └─ Summit_Events_Appointment_Type__c (enhanced)
       └─ Appointment_Type_Group__c (lookup to group)

Functionality

Group-Level Capacity Management

  • Track total registrations across all appointment types in the group
  • Enforce group capacity limits preventing over-booking
  • Display remaining capacity at the group level
  • Optional per-appointment-type capacity within the group

Selection Rules

  • Enforce minimum/maximum selection constraints
  • Support single-select groups (radio button behavior)
  • Support multi-select groups (checkbox behavior with limits)
  • Mark individual appointment types as required within a group
  • Validate selections on form submission

User Interface

  • Display appointment groups as logical sections in the registration form
  • Show group instructions and capacity information
  • Visual grouping of related appointment types
  • Clear indication of selection requirements (e.g., "Select 1-3 from this group")
  • Dynamic validation messages for selection constraints

Reporting & Analytics

  • Group-level capacity reporting
  • Selection pattern analysis (which combinations are popular)
  • Utilization metrics by group
  • Appointment type popularity within groups

Example Use Cases

  1. Workshop Sessions

    • Create Group: "Morning Workshop Sessions"
      • Event: Fall Open House 2024
      • Capacity: 100 (total across all sessions)
      • Selection Mode: Single Choice
      • Required: Yes
    • Configure Appointment Types to reference this group:
      • "Session A - Engineering" → Appointment_Type_Group__c = "Morning Workshop Sessions", capacity = 40
      • "Session B - Business" → Appointment_Type_Group__c = "Morning Workshop Sessions", capacity = 40
      • "Session C - Liberal Arts" → Appointment_Type_Group__c = "Morning Workshop Sessions", capacity = 40

  2. Campus Tours

    • Create Group: "Campus Tour Options"
      • Event: Spring Visit Day
      • Capacity: 200
      • Min Selection: 1, Max Selection: 2
      • Selection Mode: Multiple Choice
    • Configure Appointment Types:
      • "General Tour" → Required_In_Group__c = true
      • "Academic Tour" → Required_In_Group__c = false
      • "Athletics Tour" → Required_In_Group__c = false
      • "Residence Tour" → Required_In_Group__c = false

  3. Meal Selections

    • Create Group: "Meal Preferences"
      • Selection Mode: Multiple Choice
      • Max Selection: 2
    • Appointment Types:
      • "Lunch Option"
      • "Dinner Option"

  4. Interview Tracks

    • Create Group: "Interview Sessions"
      • Capacity: 50 (total)
      • Min Selection: 1, Max Selection: 3
    • Appointment Types:
      • "Academic Interview"
      • "Financial Aid Interview"
      • "Student Life Interview"

Technical Considerations

Database Schema

  • Master-Detail relationships for data integrity
  • Roll-up summary fields for capacity tracking
  • Validation rules for selection constraints
  • Proper indexing for performance

Salesforce Platform

  • Custom objects with appropriate sharing settings
  • Lightning Web Components for enhanced UI
  • Apex triggers for capacity validation
  • Flow/Process Builder support for automation

Backward Compatibility

Critical Requirement: Existing implementations using Appointment_Category__c must continue to function without any changes or migrations required.

  • Permanent Support - Appointment_Category__c picklist field will be permanently maintained
  • Zero Breaking Changes - Existing appointment types without groups continue to work exactly as they do today
  • Opt-In Enhancement - Groups are an optional enhancement; organizations can choose when/if to adopt
  • Dual-Mode Support - Code must support both categorization methods simultaneously and indefinitely

Migration Path (Optional)

Organizations may optionally migrate from picklist-based categories to object-based groups if they want the enhanced features:

  1. Optional Data Migration - Organizations can choose to migrate when ready:

    • Read current Appointment_Category__c values
    • Create corresponding Summit_Events_Appointment_Type_Group__c records for events that want enhanced features
    • Update selected Appointment Types to reference new Groups via Appointment_Type_Group__c lookup
    • Appointment_Category__c remains untouched and functional

  2. Dual-Mode Operation - Code will permanently support both approaches:

    • If Appointment_Type_Group__c is populated → Use object-based groups with full feature set
    • Else if Appointment_Category__c is populated → Use traditional picklist categorization
    • Else → Ungrouped/uncategorized appointment type
    • Both can coexist within the same Event

  3. No Deprecation - Unlike typical migrations:

    • Appointment_Category__c will NOT be deprecated
    • Organizations can use picklist categories indefinitely
    • New organizations can choose either approach or use both

Performance

  • Efficient SOQL queries to minimize governor limits
  • Bulkification for group capacity calculations
  • Caching strategy for frequently accessed group data

Implementation Phases

Phase 1: Core Data Model

  • Create custom objects and fields
  • Implement basic relationships
  • Build admin UI for group management

Phase 2: Capacity & Validation

  • Implement group capacity tracking
  • Add selection rule validation
  • Create error handling and messaging

Phase 3: User Interface

  • Build registration form components
  • Implement dynamic group display
  • Add client-side validation

Phase 4: Reporting & Enhancement

  • Create standard reports and dashboards
  • Add analytics capabilities
  • Performance optimization

Acceptance Criteria

  • [ ] Admin can create and configure appointment groups
  • [ ] Admin can assign appointment types to groups
  • [ ] Group capacity limits are enforced accurately
  • [ ] Selection rules (min/max) are validated
  • [ ] Groups display correctly in registration forms
  • [ ] Users can select appointments according to group rules
  • [ ] Appropriate error messages display for constraint violations
  • [ ] Capacity is tracked and displayed at group level
  • [ ] Existing Appointment_Category__c functionality continues to work without any changes
  • [ ] Code supports both categorization methods simultaneously (dual-mode)
  • [ ] Orgs using picklist categories are not forced to migrate
  • [ ] Unit tests achieve 90%+ code coverage for both modes
  • [ ] Documentation updated with configuration guide for both approaches

Dependencies

  • Summit Events App package
  • Appointment Types functionality
  • Event registration flow

Open Questions

  1. Should groups support conditional visibility based on user responses?
  2. How should waitlisting work at the group level?
  3. Should there be group-level pricing/fees?
  4. Do we need support for nested groups or group hierarchies?
  5. How should groups interact with appointment time slots?
  6. Can an Appointment Type belong to multiple groups? (Current design: No - single lookup field)
  7. Should we support cross-event groups, or are event-specific groups sufficient?
  8. How do we handle group capacity when individual appointment types have their own capacity limits?

Resources

  • Related to existing Appointment Types functionality
  • May require updates to registration confirmation emails
  • Documentation needed for admin configuration

Labels: enhancement, feature-request, appointments Priority: To be determined Estimated Effort: Large (multiple sprints)

rdblake21 avatar Feb 07 '20 22:02 rdblake21

From St. Thomas, TDX ticket (28652194), I would like to have the ability to limit the number of appointments that registrants are able to select from a list. Ex) Once a guest hits their limit (whatever that may be), they're unable to add more appointments from the list. Maybe a message appears when they try to do so, or everything just greys out.

Currently, if you have multiple appointment options in Summit Events, there's nothing stopping a guest from selecting them all. This causes issues when the appointments must happen at the same time and cannot be stacked next to each other.

This happened a lot with Admitted Tommie Experience last year even with bolded text all around the registration saying only pick ONE appointment.

walt0019 avatar Sep 23 '25 16:09 walt0019