Skip to content

Event Management

User Scenarios & Testing (mandatory)

User Story 1 - Admin Creates and Publishes Event (Priority: P1)

An admin creates a new conference event with all required details (name, dates, venue, timezone), configures stand packages and artwork requirements, assigns organisers, and publishes the event so sponsors can be invited.

Why this priority: This is the foundational capability - without event creation, no other functionality can exist. It represents the minimum viable feature that delivers value.

Independent Test: Can be fully tested by creating an event, configuring basic settings, assigning at least one organiser, and publishing it. Delivers a functional event ready for sponsor participation.

Acceptance Scenarios:

  1. Given an admin is logged in, When they create a new event with name "Tech Summit 2025", dates (start: 2025-06-15, end: 2025-06-17), venue "Excel London", and timezone "Europe/London", Then the event is saved in draft status
  2. Given an event in draft status exists, When admin adds configuration deadline (2025-05-01) and artwork deadline (2025-05-15) and validates dates are sequential, Then deadlines are saved correctly
  3. Given an event has all required fields completed, When admin assigns an organiser with "admin" permissions, Then the organiser can access the event
  4. Given an event in draft status with all required fields, When admin publishes the event, Then status changes to published and organisers are notified
  5. Given an admin attempts to create an event, When they use a name that already exists for the same organiser, Then system rejects with validation error

User Story 2 - Organiser Invites and Manages Sponsors (Priority: P2)

An organiser views their assigned events, generates secure invitation links for sponsors, sends invitations via email, tracks invitation status, and assigns sponsors to specific stands within the event.

Why this priority: Once events exist, the next critical step is getting sponsors into the system. This enables the core user base to participate.

Independent Test: Can be tested independently by having a published event, generating invitation links, sending emails, and verifying sponsor registration flow. Delivers functional sponsor onboarding.

Acceptance Scenarios:

  1. Given an organiser is logged in, When they view their dashboard, Then only events they are assigned to are displayed
  2. Given an organiser views a published event, When they generate an invitation link for email "sponsor@company.com", Then a unique secure token is created and invitation is sent
  3. Given a sponsor receives an invitation email, When they click the link and complete registration, Then they are assigned to the event and associated stand(s)
  4. Given an organiser needs to resend an invitation, When they select "resend" for a sponsor, Then a new secure link is generated and previous link is invalidated
  5. Given an organiser has a list of 50 sponsors to invite, When they use bulk invitation tool with validated email addresses, Then all invitations are sent with tracking status

User Story 3 - Sponsor Manages Multiple Stands Across Events (Priority: P2)

A sponsor logs in and views all events they are participating in, sees their assigned stands for each event, switches between different stands or events, and views event-specific information (timezone, venue, deadlines).

Why this priority: Sponsors often participate in multiple events or manage multiple stands. This improves user experience and efficiency for the primary end users.

Independent Test: Can be tested by assigning a sponsor to multiple stands across different events, logging in, and verifying stand switching and contextual information display. Delivers enhanced sponsor workflow.

Acceptance Scenarios:

  1. Given a sponsor is assigned to 3 stands across 2 events, When they log in, Then they see all events and stands listed with event details
  2. Given a sponsor is viewing Stand A in Event 1, When they switch to Stand B in Event 2, Then context changes to show Event 2 timezone, deadlines, and venue information
  3. Given a sponsor views an event, When they check submission deadlines, Then they see configuration deadline and artwork deadline in the event's timezone
  4. Given a sponsor has multiple stands in the same event, When they switch between stands within that event, Then stand-specific configuration persists and loads correctly
  5. Given a sponsor attempts to access a stand they are not assigned to, When they try to load it, Then access is denied via permission system

User Story 4 - Admin Archives Completed Event (Priority: P3)

An admin reviews completed events, archives them according to data retention policies, ensures audit logs and historical data remain accessible, and verifies archived events do not appear in active lists but can be retrieved for reference.

Why this priority: While important for long-term system health, this can be deferred until the core event lifecycle is operational.

Independent Test: Can be tested by creating completed events, archiving them, verifying they disappear from active lists, and confirming historical data retrieval works. Delivers data governance compliance.

Acceptance Scenarios:

  1. Given an event has passed its end date, When admin views completed events list, Then they see events eligible for archiving
  2. Given admin selects an event to archive, When they confirm archiving action, Then status changes to archived and soft delete is applied
  3. Given an event is archived, When organisers view their dashboard, Then the archived event does not appear in active event lists
  4. Given an event is archived, When admin searches for it by name or ID, Then they can retrieve it and view all historical data including audit logs
  5. Given an archived event contains sponsor configurations and artwork, When retrieved for reference, Then all data is accessible for seven-year retention period

User Story 5 - Admin and Organiser Monitor Sponsor Progress (Priority: P2)

An admin or organiser views an event dashboard showing all sponsors and their progress through required steps: stand configuration status, artwork upload status, payment status, and proof approval status. They can filter by completion status, identify sponsors who are behind schedule, and take action (send reminders, contact directly) to ensure all sponsors complete their required tasks before deadlines.

Why this priority: This oversight capability is critical for event organisers to ensure all sponsors are ready for the event. Without this, organisers would need to manually track each sponsor individually, leading to missed incomplete submissions and last-minute scrambles.

Independent Test: Can be tested by creating an event with multiple sponsors at different completion stages, viewing the progress dashboard, filtering by status, and verifying progress indicators are accurate. Delivers essential event management oversight.

Acceptance Scenarios:

  1. Given an organiser views an event with 20 assigned sponsors, When they access the sponsor progress dashboard, Then they see a list showing each sponsor with completion indicators for: stand configuration (complete/incomplete), artwork upload (complete/incomplete/pending approval), payment (complete/incomplete), and proof approval (complete/incomplete)
  2. Given an organiser views the sponsor progress dashboard, When they filter by "incomplete artwork", Then only sponsors who have not uploaded artwork or have pending artwork approvals are displayed
  3. Given a sponsor has completed stand configuration but not uploaded artwork, When organiser views that sponsor's progress, Then stand configuration shows green checkmark, artwork shows amber warning icon, and remaining steps show grey pending icon
  4. Given an organiser identifies 5 sponsors with incomplete configurations approaching the deadline, When they select those sponsors and click "Send Reminder", Then reminder notifications are sent to those sponsors via the communication system
  5. Given an admin views the sponsor progress dashboard, When they click on a sponsor's row, Then they see detailed status including: date stand configured, artwork files uploaded with timestamps, payment date, proof approval date, and any outstanding actions
  6. Given a configuration deadline is 3 days away, When organiser views the dashboard, Then sponsors with incomplete configurations are highlighted with urgency indicators based on proximity to deadline

User Story 6 - Organiser Modifies Event Settings and Deadlines (Priority: P3)

An organiser updates event details (dates, deadlines, venue), modifies stand package options, adjusts artwork requirements, updates notification preferences, and notifies affected sponsors of changes.

Why this priority: Configuration changes are important but secondary to initial creation and basic operations. Can be added after core functionality is stable.

Independent Test: Can be tested by modifying various event settings on published events and verifying changes propagate correctly. Delivers flexibility for event management.

Acceptance Scenarios:

  1. Given an organiser views a published event, When they update the artwork deadline from 2025-05-15 to 2025-05-20, Then deadline is validated against other dates and saved
  2. Given an event has 10 assigned sponsors, When organiser changes artwork deadline, Then all sponsors receive notification of deadline change
  3. Given an organiser modifies stand package options, When they add or remove configuration categories, Then changes are reflected for new stand configurations (existing configurations remain unchanged)
  4. Given an organiser updates venue information, When they save changes, Then all sponsors see updated venue details in their event view
  5. Given an organiser attempts to set configuration deadline after artwork deadline, When they save, Then validation error prevents illogical deadline sequence

Edge Cases

  • What happens when an organiser is removed from an event that has active sponsors? (System must reassign primary contact or prevent removal)
  • How does system handle timezone conversion when sponsor and event are in different timezones? (Display all dates in event timezone with clear labeling)
  • What happens when a sponsor invitation link is used after it has been invalidated due to resend? (Show clear error message with instructions to use new link)
  • How does system handle bulk invitation upload with partially invalid email addresses? (Process valid entries, return detailed error report for invalid ones)
  • What happens when an admin attempts to archive an event with pending artwork approvals? (Prevent archiving until all workflows complete, or force-archive with warning)
  • How does system handle concurrent editing of event settings by multiple organisers? (Last write wins, with audit log showing both changes and notification to editors)
  • What happens when deadlines are reached but sponsors have not submitted configurations? (System sends automated reminders, marks submissions as overdue, but allows late submission based on organiser settings)
  • How does system handle a sponsor with 20+ stands across 10+ events? (Implement pagination and filtering on stand/event lists, optimize context switching performance)
  • What happens when sponsor progress status changes while organiser is viewing the dashboard? (Use real-time updates or provide refresh mechanism with visual indication of stale data)
  • How does system handle sponsor progress when a sponsor has multiple stands in the same event? (Aggregate progress across all stands or display per-stand breakdown with configurable view)
  • What happens when deadlines are extended after progress dashboard has calculated urgency indicators? (Recalculate urgency on deadline change and update dashboard in real-time or on next refresh)

Requirements (mandatory)

Functional Requirements

Event Creation and Configuration

  • FR-001: System MUST allow admins to create new events with mandatory fields: name (unique per organiser), description, start date, end date, configuration deadline, artwork deadline, venue, and timezone (IANA format)
  • FR-002: System MUST validate that event dates follow logical sequence: configuration deadline < artwork deadline < start date < end date
  • FR-003: System MUST support three event statuses: draft (initial), published (active), and archived (completed)
  • FR-004: System MUST allow admins and organisers to define stand package options through configuration categories linked to events
  • FR-005: System MUST allow admins and organisers to define artwork requirements through configuration items linked to events
  • FR-006: System MUST support extensible custom fields through event settings for event-specific requirements
  • FR-007: System MUST enforce event name uniqueness per organiser (different organisers can use the same event name)

Organiser Management

  • FR-008: System MUST allow admins to assign organisers to events using the permission system with three access levels: read, write, or admin
  • FR-009: System MUST support three organiser roles: primary contact, contact, or viewer
  • FR-010: System MUST provide organisers with a dashboard filtered to show only events they are assigned to
  • FR-011: System MUST allow organisers with write or admin permissions to modify event settings (dates, deadlines, venue, configuration options)
  • FR-012: System MUST log all organiser actions in the audit logging system for accountability
  • FR-013: System MUST allow organisers to generate unique, secure invitation links for each sponsor via email
  • FR-014: System MUST validate email addresses before sending invitations
  • FR-015: System MUST track invitation status for each sponsor: pending, accepted, or expired
  • FR-016: System MUST allow organisers to resend invitations with new secure tokens that invalidate previous links
  • FR-017: System MUST provide bulk invitation tools that validate email addresses and process valid entries
  • FR-018: System MUST support multiple stand assignments per sponsor within the same event
  • FR-019: System MUST support sponsor participation in multiple events simultaneously
  • FR-020: System MUST provide sponsors with a stand switching interface showing all assigned stands grouped by event

Access Control and Security

  • FR-021: System MUST enforce access control through the permission system for all event, organiser, and sponsor operations
  • FR-022: System MUST validate user permissions before allowing any event modification
  • FR-023: System MUST enforce role-based permissions: admins can create/delete events, organisers can manage assigned events, sponsors can view assigned events only
  • FR-024: System MUST use token-based authentication for API access to event data
  • FR-025: System MUST log all security-relevant actions (access attempts, permission changes, status changes) in audit logs

Event Lifecycle and Data Management

  • FR-026: System MUST implement soft deletes for archived events to maintain data integrity and support seven-year retention policy
  • FR-027: System MUST notify relevant users (organisers, sponsors) via the notification system when event status changes
  • FR-028: System MUST persist sponsor stand context when switching between stands to improve workflow efficiency
  • FR-029: System MUST allow admins to archive completed events while preserving all historical data, audit logs, and configurations
  • FR-030: System MUST prevent archiving of events with incomplete workflows unless admin explicitly forces archival

Event Information Display

  • FR-031: System MUST display all event dates and deadlines in the event's configured timezone
  • FR-032: System MUST show sponsors their event deadlines (configuration and artwork) with clear timezone labeling
  • FR-033: System MUST provide sponsors with venue information and event description for each assigned event
  • FR-034: System MUST display invitation status and tracking information to organisers for monitoring purposes
  • FR-035: System MUST provide admins and organisers with a sponsor progress dashboard showing all sponsors for an event with completion status for: stand configuration, artwork upload, payment, and proof approval
  • FR-036: System MUST display visual indicators for each progress step: complete (green checkmark), incomplete (amber warning), pending approval (blue icon), not started (grey icon)
  • FR-037: System MUST allow filtering of sponsor progress by completion status (all, complete, incomplete, pending approval) for each step type
  • FR-038: System MUST calculate and display urgency indicators based on proximity to deadlines (e.g., deadline within 3 days shows high urgency)
  • FR-039: System MUST allow organisers to select multiple sponsors and send bulk reminder notifications via the communication system
  • FR-040: System MUST provide detailed progress view showing timestamps for: stand configuration completion, artwork upload dates, payment date, and proof approval date
  • FR-041: System MUST aggregate sponsor progress statistics showing counts of complete, incomplete, and pending for each step across all event sponsors
  • FR-042: System MUST link sponsor progress items to the communication system allowing organisers to message sponsors directly from the progress dashboard

Notification and Communication

  • FR-043: System MUST send automated email notifications when: invitation is sent, deadline is approaching (configurable warning period), event settings change, event status changes
  • FR-044: System MUST support customizable email templates for invitations and notifications within event settings
  • FR-045: System MUST notify all assigned sponsors when organisers modify event deadlines or critical settings
  • FR-046: System MUST send reminder notifications for approaching deadlines based on organiser-configured notification settings

Performance and Scale

  • FR-047: System MUST support concurrent access by multiple organisers editing different aspects of the same event
  • FR-048: System MUST handle bulk invitation operations for up to 500 sponsors per batch with progress tracking
  • FR-049: System MUST optimize event listing and search using indexed database queries on name, status, and dates
  • FR-050: System MUST paginate sponsor lists and stand lists when count exceeds 20 items
  • FR-051: System MUST load sponsor progress dashboard with up to 100 sponsors in under 2 seconds using optimized queries

Key Entities

  • Event: Represents a conference or exhibition with name, description, dates (start, end, configuration deadline, artwork deadline), venue, timezone (IANA format), status (draft/published/archived), organiser assignments, sponsor assignments, stand packages, artwork requirements, and custom settings
  • Organiser Assignment: Links organiser users to events with permission scope (read/write/admin) and role (primary contact/contact/viewer), managed through the permission system
  • Sponsor Assignment: Links sponsor users to specific stands within events, supporting multiple stands per event and multiple events per sponsor, managed through the permission system
  • Invitation: Tracks sponsor invitation process with unique secure token, email address, status (pending/accepted/expired), sent timestamp, and accepted timestamp
  • Stand: Represents an exhibition space within an event, linked to a sponsor, with configuration status and artwork status
  • Event Settings: Stores event-specific preferences including notification templates, default values, workflow rules, and custom fields
  • Sponsor Progress: Aggregated view of sponsor completion status containing sponsor reference, event reference, stand configuration status (complete/incomplete with timestamp), artwork upload status (complete/incomplete/pending approval with timestamp), payment status (complete/incomplete with timestamp), proof approval status (complete/incomplete with timestamp), and overall completion percentage

Success Criteria (mandatory)

Measurable Outcomes

  • SC-001: Admins can create a complete event (including all required fields, organiser assignment, and initial configuration) in under 10 minutes
  • SC-002: Organisers can generate and send sponsor invitations at a rate of at least 100 invitations per minute for bulk operations
  • SC-003: Sponsors can view all their assigned stands across multiple events and switch between stands in under 3 seconds per switch
  • SC-004: System maintains sub-second response times for event listing and search operations with up to 1000 active events
  • SC-005: 95% of sponsors successfully accept invitations and access their events on first attempt without support intervention
  • SC-006: System supports concurrent access by at least 50 organisers managing different events without performance degradation
  • SC-007: Event deadline notifications are delivered within 5 minutes of scheduled send time with 99% reliability
  • SC-008: Archived event data remains accessible and retrievable with response times under 2 seconds for seven-year retention period
  • SC-009: Audit logs capture 100% of security-relevant actions (access changes, permission modifications, status transitions) with timestamp and user attribution
  • SC-010: Bulk invitation operations complete successfully for batches of up to 500 sponsors with detailed error reporting for invalid entries
  • SC-011: System correctly handles timezone conversions for events and sponsors in different timezones with zero date/time display errors
  • SC-012: 90% of organisers successfully configure event settings (deadlines, packages, artwork requirements) without referring to documentation
  • SC-013: Organisers can identify incomplete sponsor submissions and send targeted reminders within 2 minutes using the sponsor progress dashboard
  • SC-014: Sponsor progress dashboard loads and displays status for 100 sponsors in under 2 seconds
  • SC-015: Progress indicators accurately reflect real-time completion status with updates appearing within 5 seconds of sponsor action completion

Assumptions (mandatory)

  1. User Management System: Assumes existing user authentication and registration system handles user accounts, passwords, and session management
  2. Permission System: Assumes existing role-based permission system can be extended to support event-organiser and event-sponsor relationships
  3. Email Service: Assumes integration with external email service (e.g., transactional email provider) for sending invitations and notifications
  4. Notification System: Assumes existing notification infrastructure handles scheduling, delivery, and template management
  5. Audit Logging: Assumes existing audit logging system captures user actions with timestamp, user ID, action type, and affected resources
  6. File Storage: Assumes artwork files are stored separately and referenced by event/stand context (not managed within event management module)
  7. Timezone Data: Assumes IANA timezone database is available and maintained for accurate timezone conversion
  8. Database Performance: Assumes database supports indexing on event name, status, dates, and organiser/sponsor relationships for query optimization
  9. Soft Delete Implementation: Assumes database and ORM support soft delete pattern (deleted_at timestamp) for data retention
  10. Concurrent Access: Assumes database supports row-level locking or optimistic concurrency control for conflict resolution
  11. Default Notification Timing: Deadline reminder notifications sent 7 days and 24 hours before deadline unless organiser configures different intervals
  12. Invitation Link Expiry: Invitation tokens expire after 30 days if not accepted unless organiser resends
  13. Event Archival Trigger: Events become eligible for archiving 30 days after end date, subject to admin discretion
  14. Stand Context Persistence: Stand context stored in user session or browser local storage for duration of user session

Dependencies (mandatory)

Internal Dependencies

  • User management system: required for authentication, registration, user profiles, and session management
  • Permission system: required for access control, role assignment, and authorization checks
  • Stand configuration system: required for stand package definitions, configuration categories, and sponsor configurations
  • Artwork management system: required for artwork requirements, submission workflows, approval processes, and progress status tracking
  • Notification system: required for email invitations, deadline reminders, status change notifications, and template management
  • Communication system: required for sending targeted reminders and direct messages from progress dashboard
  • Payment system: required for payment status tracking in sponsor progress monitoring
  • Audit logging system: required for tracking user actions, security events, and compliance reporting

External Dependencies

  • Transactional email service: required for sending invitation emails and notification emails with delivery tracking
  • IANA timezone database: required for timezone validation and date/time conversion
  • File storage service: required for storing uploaded artwork files referenced by event context

Constraints (mandatory)

Business Constraints

  • Event names must be unique per organiser (but not globally unique across platform)
  • Event dates must follow logical sequence: configuration deadline < artwork deadline < start date < end date
  • Stand package options limited to configuration categories and items defined in stand configuration system
  • User access controlled by permission system - cannot bypass role-based access controls
  • Archived events must retain all data (configurations, artwork, audit logs) for seven-year compliance period
  • Sponsors may be assigned to multiple stands within same event and participate in multiple events simultaneously
  • Organisers must belong to at least one event; cannot delete last organiser from published event

Technical Constraints

  • API rate limits: 100 requests per minute per user for event creation/modification operations
  • Bulk invitation operations: maximum 500 sponsors per batch to prevent timeout and memory issues
  • Storage quotas: event configuration data (excluding artwork files) limited to 10MB per event
  • Concurrent user access: system designed to support up to 100 concurrent users per event without degradation
  • Invitation token length: 64 characters (cryptographically secure random string)
  • Database query timeout: 5 seconds for complex event listing queries with filters
  • Event listing pagination: 50 events per page maximum to maintain response time under 1 second

Open Questions

None - all requirements are specified with reasonable defaults documented in Assumptions section.