Use Cases

1. Overview

The Registration Portal supports multiple use cases covering person management, membership registration, and event registration. This document provides detailed scenarios demonstrating how users accomplish their goals, including acceptance criteria for implementation.

Phase 2 Enhancements are marked with the phase2 label and include:

  • Identity Selection (OIDC authentication option)

  • Manual Payment (QR code handoff)

  • Event Cancellation with refunds

  • Communication preference capture

2. Use Case 1: LinkedPerson Management

2.1. Overview

Goal: Manage a group of related people (family, friends, team) for registration purposes.

Actors:

  • Primary User (principal)

  • Related Persons (linked persons)

Preconditions:

  • User has received registration link with userKey

  • User has accessed the registration portal

2.2. Scenario 1.1: Add Family Member by ID Number

Context: Sarah wants to add her 10-year-old son Billy to register for a family membership.

Workflow:

  1. Sarah accesses membership registration page

  2. Clicks "+ Add Family Member"

  3. Navigates to LinkedPerson search page

  4. Selects "Search by ID Number"

  5. Enters Billy’s 13-digit SA ID number: 1001150123089

  6. System validates ID format ✓

  7. System auto-extracts:

    • Date of Birth: 2010-11-15

    • Gender: Male (sequence 0123 < 5000)

  8. System searches existing persons…​ no match found

  9. System displays create person form with pre-populated data:

    • Identity Type: National ID (locked)

    • ID Number: 1001150123089 (locked)

    • Date of Birth: 2010-11-15 (locked)

    • Gender: Male (locked)

    • Country: South Africa (locked)

  10. Sarah enters:

    • First Name: Billy

    • Last Name: Smith

    • Email: (leaves blank)

    • Contact Number: (leaves blank)

    • School: Pretoria High School

  11. Clicks "Save"

  12. System creates Person record

  13. System creates LinkedPerson relationship:

    • Principal: Sarah (ID: 1)

    • Linked Person: Billy (ID: 3)

    • Type: FAMILY

  14. Returns to membership registration page

  15. Billy now appears in person selection table

Outcome: Billy is now linked to Sarah and available for membership registration.

2.3. Scenario 1.2: Add Friend by Date of Birth

Context: John wants to add his friend Mike to register together for a race event.

Workflow:

  1. John accesses event registration page

  2. Clicks "+ Add Person"

  3. Navigates to LinkedPerson search

  4. Selects "Search by Date of Birth"

  5. Selects birth date: 1985-03-15 (year → month → day drill-down)

  6. Clicks "Search"

  7. System finds 3 matches:

    • Mike Johnson - 1985-03-15 - Male

    • Michael Smith - 1985-03-15 - Male

    • Michelle Roberts - 1985-03-15 - Female

  8. John reviews the list

  9. Clicks "Select" next to Mike Johnson

  10. System displays Mike’s details for confirmation

  11. John verifies identity and clicks "Link Person"

  12. System creates LinkedPerson relationship:

    • Principal: John (ID: 5)

    • Linked Person: Mike (ID: 7)

    • Type: FRIEND

  13. Returns to event registration

  14. Mike now appears in participant selection

Outcome: Mike is linked to John and can be registered for the event.

2.4. Scenario 1.3: Edit Existing Linked Person

Context: Sarah needs to update Billy’s school information.

Workflow:

  1. Sarah accesses membership registration

  2. Sees Billy in linked persons table

  3. Clicks "Edit" button next to Billy’s name

  4. System navigates to edit person form

  5. Identity fields are locked (ID number, DOB, gender)

  6. Sarah updates:

    • School: Pretoria High School → Centurion High School

  7. Clicks "Save"

  8. System updates Person record

  9. Returns to registration page

  10. Changes are reflected in the table

Outcome: Billy’s information is updated without creating a duplicate.

3. Use Case 2: Membership Registration

3.1. Overview

Goal: Apply for organizational membership with multiple family members.

Actors:

  • Membership Applicant (principal)

  • Family Members (linked persons)

Preconditions:

  • User received membership invitation email

  • Membership period is open for registration

3.2. Scenario 2.1: Family Membership Application

Context: Sarah applies for a family membership for herself and her two children.

Workflow:

Step 1: Access Registration

  1. Sarah receives email:

    Subject: 2024 Running Club Membership Now Open

Dear Sarah Smith,

Registration for the 2024 Running Club membership is now open.

Click here to register:
https://app.runningclub.com/membership/register/42?u=abc123&h=5d41402a...

Best regards,
Running Club

  2. Sarah clicks the link

  3. System validates userKey and hash ✓

  4. System loads membership registration page

Step 2: Person Selection

  1. System displays linked persons:

    Select Family Members:

☐ Sarah Smith    | 1985-03-15 | Available
☐ Billy Smith    | 2010-11-03 | Available
☐ Emma Smith     | 2013-07-20 | Available

  2. Sarah selects herself and both children ☑

  3. Selected count updates: "3 participants selected"

  4. Pricing preview: "Total: R 1,000.00"

  5. Sarah clicks "Continue"

Step 3: Question Workflow

  1. Question 1: "Does anyone have any medical conditions?"

    ☐ Sarah Smith
☑ Billy Smith
☐ Emma Smith

    Sarah checks Billy (he has asthma)

  2. Question 2: "What is your emergency contact number?"

    Sarah Smith:  [0821234567]
Billy Smith:  [0821234567]
Emma Smith:   [0821234567]

  3. Question 3: "Who will be the primary contact person?"

    (●) Sarah Smith
( ) Billy Smith
( ) Emma Smith

    Sarah selects herself

  4. Question 4: "What are your T-shirt sizes?"

    Sarah Smith:  [Dropdown: M]
Billy Smith:  [Dropdown: L]
Emma Smith:   [Dropdown: S]

  5. Question 5: "I accept the terms and conditions"

    [X] Accept for all members

[X] Sarah Smith - I accept the terms and conditions
[X] Billy Smith - I accept the terms and conditions
[X] Emma Smith - I accept the terms and conditions

Step 4: Payment

  1. System displays summary:

    Registration Complete!

Membership Summary:
- Sarah Smith (Adult)      R 500.00
- Billy Smith (Junior)     R 300.00
- Emma Smith (Junior)      R 200.00
                         ----------
Total:                    R 1,000.00

[Proceed to Payment]

  2. Sarah clicks "Proceed to Payment"

  3. System redirects to payment gateway

  4. Sarah completes payment

  5. Gateway redirects back to portal

  6. System displays confirmation:

    Payment Successful!

Membership Numbers:
- Sarah Smith: M2024-1523
- Billy Smith: M2024-1524
- Emma Smith:  M2024-1525

A confirmation email has been sent to [email protected]

Outcome: Family membership successfully registered and paid.

3.3. Scenario 2.2: Resume Incomplete Registration

Context: John started a membership application but didn’t complete payment. He returns 2 days later.

Workflow:

  1. John clicks original registration link

  2. System detects existing ProcessInstance in SUSPENDED state

  3. System displays dialog:

    Existing Registration Detected

A previous registration attempt was found from 2 days ago.

Would you like to:
[Start Fresh]  [Resume]

  4. John clicks "Resume"

  5. System loads ProcessInstance

  6. System restores state:

    • Selected persons: John, Mike (2 persons)

    • Completed questions: 1-3 of 5

    • Current step: Question 4

  7. System displays Question 4 with previous selections intact

  8. John completes Questions 4-5

  9. Normal payment flow continues

  10. Registration completed

Outcome: John successfully completes registration without re-entering previous answers.

4. Use Case 3: Event Participant Registration

4.1. Overview

Goal: Register participants for an event (race, tournament, competition).

Actors:

  • Event Participant (registrant)

  • Additional Participants (friends, family, team members)

Preconditions:

  • Event registration is open

  • User has received event registration link

4.2. Scenario 3.1: Individual Race Registration

Context: Emma wants to register herself for a 10km fun run.

Workflow:

  1. Emma receives SMS:

    Running Club 10km Fun Run - March 15

Register now: https://app.runningclub.com/register?eventId=15&orgId=8&userKey=xyz789

  2. Emma clicks link

  3. System validates userKey ✓

  4. System loads event registration page

  5. System displays event details:

    Event: 10km Fun Run
Date: March 15, 2024
Location: Centurion, Gauteng
Distance: 10km
Entry Fee: R 150.00
Registration Closes: March 10, 2024

  6. System displays participant selection:

    Select Participants:

☑ Emma Smith    | 2013-07-20 | Female

  7. Emma is automatically selected (only person available)

  8. Pricing: "Total: R 150.00 (1 participant)"

  9. Emma clicks "Register"

  10. System creates EventParticipant record

  11. System creates Order

  12. System redirects to payment gateway

  13. Emma completes payment

  14. System displays confirmation:

    Registration Successful!

Emma Smith - Bib Number: B1523

You will receive your race pack at:
Race Expo: March 14, 2024, 10:00-18:00
Centurion Mall

Race Start: March 15, 2024, 07:00

Good luck!

Outcome: Emma successfully registered for the race.

4.3. Scenario 3.2: Team Registration

Context: Coach David registers 5 team members for a relay race.

Workflow:

  1. David accesses team registration link

  2. System loads his linked persons (team members):

    Select Participants:

☐ David Lee       | 1980-05-12 | Coach
☐ James Brown     | 1995-08-20 | Athlete
☐ Lisa Wong       | 1997-03-15 | Athlete
☐ Tom Anderson    | 1996-11-08 | Athlete
☐ Kelly Martinez  | 1998-01-25 | Athlete
☐ Chris Taylor    | 1999-07-30 | Athlete

  3. David selects 4 athletes for the relay team

  4. System displays team total: "Total: R 600.00 (4 participants × R 150.00)"

  5. David clicks "Register"

  6. System assigns consecutive bib numbers:

    • James Brown: T1001

    • Lisa Wong: T1002

    • Tom Anderson: T1003

    • Kelly Martinez: T1004

  7. Payment and confirmation follow

  8. Email sent with team details

Outcome: Relay team successfully registered.

4.4. Scenario 3.3: Registration with Age Restriction

Context: Billy (age 10) tries to register for an adult-only race.

Workflow:

  1. Sarah tries to register Billy for "Half Marathon 21km"

  2. System validates participant eligibility

  3. System detects age restriction:

    • Race: Half Marathon 21km

    • Minimum Age: 16 years

    • Billy’s Age: 10 years

  4. System displays error:

    Registration Error

Billy Smith is not eligible for this race.

Reason: Participant is under minimum age requirement (16 years)

Please select a different race or participant.

  5. System suggests alternatives:

    • 5km Junior Run (Ages 8-15)

    • 1km Kids Dash (Ages 5-10)

  6. Sarah navigates back and selects "5km Junior Run"

  7. Billy is eligible ✓

  8. Registration proceeds successfully

Outcome: System prevents ineligible registration, guides user to appropriate event.

5. Use Case Variations

5.1. Variation: Free Registration

Context: Organisation offers promotional free membership.

Differences:

  • Pricing shows: R 0.00

  • Payment step skipped

  • Membership activated immediately

  • Confirmation email sent without payment receipt

5.2. Variation: Multiple Registration Attempts

Context: User tries to register person who is already registered.

Workflow:

  1. User selects person who has active membership

  2. Person shows status: "Registered"

  3. Checkbox is disabled (canSelect = false)

  4. Tooltip displays: "Already has active membership"

  5. User cannot select this person

  6. User can view existing membership details

5.3. Variation: Registration Window Closed

Context: User accesses registration link after closing date.

Workflow:

  1. User clicks registration link

  2. System checks membership period:

    • Registration End Date: 2024-01-31

    • Current Date: 2024-02-05

  3. System displays message:

    Registration Closed

Registration for 2024 Running Club membership closed on January 31, 2024.

Please contact the club administrator for late registration requests.

Email: [email protected]
Phone: 012 345 6789

  4. Registration form is not displayed

  5. Contact information provided for inquiries

6. User Journey Maps

6.1. Journey: First-Time Membership Applicant

Stage 1: Discovery
├─ Receive invitation email
├─ Click registration link
└─ Land on registration page

Stage 2: Setup
├─ Review membership benefits
├─ Add family members (if any)
├─ Select persons for membership
└─ Click Continue

Stage 3: Application
├─ Answer question 1
├─ Answer question 2
├─ Answer question 3
├─ Answer question 4
├─ Accept terms
└─ Review summary

Stage 4: Payment
├─ Redirect to payment gateway
├─ Enter payment details
├─ Confirm payment
└─ Return to portal

Stage 5: Confirmation
├─ View membership numbers
├─ Receive confirmation email
└─ Done

Average Time: 8-12 minutes

Pain Points:

  • Adding family members (if not already linked)

  • Answering multiple questions

  • Payment gateway redirect

Improvements:

  • Pre-populate data where possible

  • Progress indicator for questions

  • Save and resume functionality

6.2. Journey: Returning Event Participant

Stage 1: Access
└─ Click event link from SMS/email

Stage 2: Selection
├─ Review event details
├─ Select participants (self already selected)
└─ Click Register

Stage 3: Payment
├─ Redirect to payment
├─ Complete payment
└─ Return to portal

Stage 4: Confirmation
├─ View bib number
├─ Note race pack collection details
└─ Done

Average Time: 3-5 minutes

Pain Points:

  • Minimal friction for returning users

Improvements:

  • Remember payment method for faster checkout

  • Push notifications for race day reminders

7. Error Scenarios

7.1. Invalid Registration Link

Symptoms:

  • User clicks old/expired link

  • Hash validation fails

  • System shows error page

Resolution:

  • Request new registration link

  • Contact organization administrator

7.2. Network Interruption During Registration

Symptoms:

  • Form submission fails

  • User sees timeout error

Resolution:

  • System auto-saves progress

  • User can resume from last completed step

  • No data loss

7.3. Payment Gateway Failure

Symptoms:

  • Payment redirect fails

  • Gateway returns error

Resolution:

  • Registration marked as "Pending Payment"

  • Email sent with payment link

  • User can complete payment later

  • Membership activated upon successful payment

8. Use Case 4: Identity Selection [phase2]

This use case provides scenario examples for authentication flows. For comprehensive authentication requirements including rationale, flow specifications, and matching algorithms, see Authentication Requirements.

8.1. Overview

Goal: Allow users to authenticate via multiple methods while protecting personal information and maximising registration conversion.

Actors:

  • Registration User

  • Identity Provider (external)

Preconditions:

  • User has accessed registration URL (/membership/{membershipTypeId} or /event/{eventId})

  • Tenant configuration determines available authentication options

8.2. Scenario 4.1: Active Session (Automatic Redirect)

Context: Sarah has already authenticated and returns to register for another event.

Workflow:

  1. Sarah clicks event registration link

  2. System detects valid JWT in session

  3. System redirects immediately to Registration Overview (HTTP 302)

  4. No authentication page is displayed

Acceptance Criteria:

  • Valid JWT bypasses Identity Selection screen

  • Immediate redirect to registration (no page flash)

  • User profile and linked persons loaded from session

Outcome: Sarah proceeds directly to registration without re-authenticating.

8.3. Scenario 4.2: Hash-Based Authentication

Context: John receives an invitation email with a secure registration link.

Workflow:

  1. John clicks link: https://app.example.com/event/15?u=abc123&h=5d41402a…​

  2. System validates hash parameters against backend

  3. Backend issues new JWT for John’s profile

  4. System redirects to Registration Overview (HTTP 302)

  5. John’s linked persons are loaded

Acceptance Criteria:

  • Hash-based URLs bypass Identity Selection screen when valid

  • New JWT issued, overriding any existing session

  • Invalid hash shows Identity Selection screen (not error page)

  • Hash parameters cleared from URL after validation

Outcome: John accesses registration directly via secure link with profile loaded.

8.4. Scenario 4.3: OIDC Authentication

Context: Mike wants to register for a race and signs in with his Google account.

Workflow:

  1. Mike clicks event registration link (no hash parameters)

  2. System displays Identity Selection screen:

    How would you like to continue?

[Sign in with Google]
[Sign in with Apple]
[Continue as Guest]

Sign in to access your saved profile and linked persons.

  3. Mike clicks "Sign in with Google"

  4. System redirects to Google OIDC authentication

  5. Mike authenticates with Google

  6. Google redirects back to Registration Portal

  7. System matches OIDC identity to existing user profile (or creates new)

  8. System loads Mike’s linked persons

  9. Registration Overview displays with Mike’s profile data

Acceptance Criteria:

  • Identity providers configured for tenant are displayed

  • OIDC provider redirect initiates correctly

  • Successful authentication returns to registration flow

  • Existing linked persons loaded after authentication

  • Session persists across page refresh

  • Failed authentication shows error and allows retry

Outcome: Mike is authenticated and sees his existing linked persons.

8.5. Scenario 4.4: Guest Access (Quick Registration)

Context: Jane arrives at an event without credentials and wants to register quickly.

Workflow:

  1. Jane scans QR code from event banner: https://app.example.com/event/15?u=G

  2. System detects u=G (explicit guest mode)

  3. System displays guest details capture:

    Quick Registration

Enter your details to continue:

First Name: [Jane        ]
Last Name:  [Doe         ]
Cellphone:  [0821234567  ]

[Continue]

  4. Jane enters her details and clicks Continue

  5. System creates new OrgUser with generated UUID

  6. System searches for existing person matching cellphone + names

  7. Match found: Jane’s existing Person record becomes principal

  8. No match: New Person created with provided details

  9. Registration Overview displays (linked persons NOT shown in guest mode)

Acceptance Criteria:

  • Guest mode triggered by u=G parameter

  • Minimal details captured: first name, last name, cellphone

  • Person matching prioritises cellphone number

  • New OrgUser created with generated UUID

  • Previously linked persons NOT displayed in guest mode

  • User must explicitly add persons via Link Person

Outcome: Jane registers quickly without credentials.

8.6. Scenario 4.5: Guest Access with Relaxed Person Matching

Context: John (existing user) arrives at late registration without credentials, with his wife Jane.

Workflow:

  1. John selects guest mode

  2. John enters: "John Smith", "0821234567"

  3. System identifies John via cellphone + name match

  4. John’s existing Person record becomes principal

  5. John clicks "Add Person" to register Jane

  6. System knows Jane is linked to John from previous session

  7. Link Person screen shows Jane’s name first, unmasked:

    Add Person

Suggested matches (from your previous registrations):
- Jane Smith, Female [Select]

Search for another person:
[Search by ID Number] [Search by Date of Birth]

  8. John selects Jane without needing to enter identifying details

  9. Both proceed to registration

Acceptance Criteria:

  • Known linked persons appear first in Add Person suggestions

  • Known linked persons displayed without masking

  • Relaxed matching applied when principal identified

  • User can still search for unknown persons normally

Outcome: John registers himself and Jane quickly despite not having credentials.

8.7. Scenario 4.6: Deferred Account Creation

Context: Jane completed registration as guest and receives invitation to create account.

Workflow:

  1. Jane completes guest registration and payment

  2. Confirmation screen displays:

    Registration Complete!

Would you like to create an account?
Your linked persons will be saved for future registrations.

[Create Account]  [Maybe Later]

  3. Jane clicks "Maybe Later"

  4. Jane receives email after 24 hours:

    Subject: Save your registration details

Hi Jane,

Create an account to:
- Access your registration history
- Quickly register for future events
- Keep your family members linked

[Create Account]

  5. Jane clicks link and creates account

  6. System detects email matches existing guest registration

  7. System prompts to merge:

    We found existing registrations with this email.
Would you like to link them to your new account?

- 10km Fun Run (March 2024) - Jane Doe
- 5km Family Run (March 2024) - Jane Doe, Billy Doe

[Link Registrations]  [Skip]

Acceptance Criteria:

  • Account creation offered after successful registration

  • Email invitation sent for deferred account creation

  • Existing registrations detected by email match

  • Merge prompt displayed for matching records

  • Guest registrations linked to new account on merge

Outcome: Jane’s guest registration is linked to her new account.

9. Use Case 5: Manual Payment [phase2]

9.1. Overview

Goal: Allow users to complete registration with manual payment at registration desk.

Actors:

  • Registration User

  • Staff Member (separate system, out of scope)

Preconditions:

  • User has completed registration workflow

  • Manual payment option is enabled for tenant/event

9.2. Scenario 5.1: Manual Payment with QR Code

Context: David is at a race expo and wants to pay cash at the registration desk.

Workflow:

  1. David completes event registration questions

  2. System displays Payment Selection screen:

    How would you like to pay?

Total: R 350.00

[Pay Online]  [Pay at Registration Desk]

  3. David clicks "Pay at Registration Desk"

  4. System generates unique reference: REF-2024-8A3F

  5. System displays Manual Payment screen:

    Present this code at the registration desk

[QR CODE IMAGE]

Reference: REF-2024-8A3F
Amount: R 350.00

The staff member will scan this code to process your payment.

[Cancel] [I've completed payment]

  6. David shows QR code to staff member

  7. Staff scans/enters reference on admin system (out of scope)

  8. Staff captures payment details and confirms

  9. Backend receives payment confirmation

  10. David’s screen updates to Confirmation

Acceptance Criteria:

  • Manual Payment option displayed when configured

  • Unique reference number generated

  • QR code encodes reference number

  • QR code and reference clearly displayed

  • Amount shown matches registration total

  • Screen updates when backend confirms payment

  • Timeout/expiry handling for pending payments

Implementation Scope:

Area Component Deliverables

Frontend

Registration Portal (Angular)

Payment selection screen, QR code display component, payment status polling, timeout handling UI

Backend

admin-service (Java)

Payment reference generation API, QR code data endpoint, payment status endpoint, callback webhook handler

Integration

Staff Admin System

Callback integration for payment confirmation (out of scope for portal)

Outcome: David completes registration via cash payment at desk.

9.3. Scenario 5.2: Manual Payment Timeout

Context: Lisa generates a QR code but doesn’t complete payment at the desk.

Workflow:

  1. Lisa selects "Pay at Registration Desk"

  2. System displays QR code with reference

  3. Lisa doesn’t present to staff within session timeout

  4. System shows timeout message:

    Payment session expired

Your registration has been saved. You can complete payment by:
- Returning to this page and generating a new code
- Contacting the registration desk

[Generate New Code] [Return to Registration]

Acceptance Criteria:

  • Session timeout configured (e.g., 30 minutes)

  • Timeout message displayed clearly

  • Option to generate new reference

  • Registration preserved in pending state

  • User can resume and complete payment later

Implementation Scope:

Area Component Deliverables

Frontend

Registration Portal (Angular)

Timeout detection, timeout message display, regenerate code action, resume flow navigation

Backend

admin-service (Java)

Session timeout configuration, reference expiry logic, new reference generation, pending registration state management

Outcome: Lisa can generate new code or complete payment later.

10. Use Case 6: Event Cancellation [phase2]

10.1. Overview

Goal: Allow users to cancel event registrations and receive appropriate refunds.

Actors:

  • Registration User (original payer)

Preconditions:

  • User has existing event registration

  • User was the original payer for the registration

  • Event has not yet occurred

10.2. Scenario 6.1: Cancellation with Refund (≥7 days before event)

Context: Sarah registered Billy for a race but he’s injured. The event is 14 days away.

Workflow:

  1. Sarah accesses event registration page

  2. Registration Overview shows Billy’s registration:

    Registered Participants:

Billy Smith | Bib: B1523 | 10km Run | Registered
[View Details] [Cancel Registration]

  3. Sarah clicks "Cancel Registration"

  4. System calculates refund (14 days before event):

    Cancel Registration

Participant: Billy Smith
Event: 10km Run - March 15, 2024
Original Amount: R 350.00

Refund Calculation:
- Cancellation: 14 days before event
- Refund Policy: 90% refund (10% admin fee)
- Refund Amount: R 315.00

[Go Back] [Confirm Cancellation]

  5. Sarah clicks "Confirm Cancellation"

  6. System processes cancellation

  7. System displays confirmation:

    Registration Cancelled

Billy Smith's registration for 10km Run has been cancelled.

Refund: R 315.00 will be processed to your original payment method within 5-7 business days.

[Return to Event]

Acceptance Criteria:

  • Cancel option visible for registered participants

  • Only original payer can cancel

  • Days until event calculated correctly

  • Refund amount calculated: 90% for ≥7 days

  • Confirmation required before cancellation

  • Registration status updated to Cancelled

  • Refund information displayed clearly

  • Cancellation confirmation shown

Implementation Scope:

Area Component Deliverables

Frontend

Registration Portal (Angular)

Cancel button on Registration Overview, cancellation confirmation dialog, refund calculation display, success confirmation screen

Backend

admin-service (Java)

Cancellation eligibility API (payer check), refund calculation service, cancellation processing endpoint, registration status update

Outcome: Billy’s registration is cancelled with 90% refund.

10.3. Scenario 6.2: Cancellation without Refund (<7 days before event)

Context: John wants to cancel his registration 3 days before the event.

Workflow:

  1. John accesses event registration

  2. Clicks "Cancel Registration"

  3. System shows no-refund warning:

    Cancel Registration

Participant: John Smith
Event: 10km Run - March 15, 2024
Original Amount: R 350.00

Refund Calculation:
- Cancellation: 3 days before event
- Refund Policy: No refund within 7 days
- Refund Amount: R 0.00

WARNING: Cancellations within 7 days of the event are not eligible for refunds.

[Go Back] [Confirm Cancellation]

  4. John confirms cancellation

  5. Registration cancelled, no refund issued

Acceptance Criteria:

  • No refund for cancellations <7 days before event

  • Clear warning about no refund

  • User must explicitly confirm

  • Registration cancelled regardless of refund

Implementation Scope:

Area Component Deliverables

Frontend

Registration Portal (Angular)

No-refund warning display, explicit confirmation checkbox/button

Backend

admin-service (Java)

Refund policy enforcement (0% for <7 days), same cancellation processing as Scenario 6.1

Outcome: John’s registration cancelled without refund.

10.4. Scenario 6.3: Cannot Cancel (Not Original Payer)

Context: Mike tries to cancel a registration that Sarah paid for.

Workflow:

  1. Mike accesses registration showing Billy (Sarah’s son)

  2. Billy shows as "Registered" but Mike didn’t pay

  3. Cancel option is not displayed

  4. View Details shows:

    Billy Smith - Registered

This registration was made by another user.
Contact the original registrant to make changes.

Acceptance Criteria:

  • Cancel option hidden for non-payers

  • Message explains why cancel unavailable

  • Original payer can still cancel

Implementation Scope:

Area Component Deliverables

Frontend

Registration Portal (Angular)

Conditional cancel button visibility, informational message for non-payers

Backend

admin-service (Java)

Payer identification in registration data, eligibility check in cancellation API

Outcome: Mike cannot cancel; Sarah (original payer) must do it.

11. Use Case 7: Communication Preferences [phase2]

11.1. Overview

Goal: Capture user’s preferred notification channels during registration.

Actors:

  • Registration User

Preconditions:

  • User is in registration question workflow

  • Communication preference question configured in ProcessDefinition

11.2. Scenario 7.1: Select Communication Preferences

Context: Sarah is completing membership registration and reaches the communication preferences question.

Workflow:

  1. Sarah progresses through registration questions

  2. System displays communication preference question:

    How would you like to receive updates and notifications?

Select all that apply:

[ ] Email
[ ] SMS
[ ] WhatsApp

Note: We'll use these channels for registration confirmations,
event reminders, and important updates.

[← Back] [Next →]

  3. Sarah selects Email and WhatsApp

  4. System validates at least one option selected

  5. Sarah clicks Next

  6. Registration continues with preferences saved

Acceptance Criteria:

  • Three options displayed: Email, SMS, WhatsApp

  • Multiple selections allowed

  • At least one selection required

  • Preferences saved with registration

  • Back navigation preserves selections

  • Question appears for both Membership and Event registration

Implementation Scope:

Area Component Deliverables

Frontend

Registration Portal (Angular)

Communication preference question component, multi-select checkbox group, validation (at least one), state persistence on navigation

Backend

admin-service (Java)

ProcessDefinition configuration for communication question, preference storage in registration data

Outcome: Sarah’s notification preferences are captured for backend use.

11.3. Scenario 7.2: Communication Preferences for Multiple Persons

Context: Sarah is registering her family and needs to set preferences for each person.

Workflow:

  1. Communication preference question displays for all selected persons:

    How would you like to receive updates and notifications?

Sarah Smith:
[X] Email  [ ] SMS  [X] WhatsApp

Billy Smith:
[X] Email  [ ] SMS  [ ] WhatsApp

Emma Smith:
[X] Email  [ ] SMS  [ ] WhatsApp

[← Back] [Next →]

  2. Sarah sets preferences for each family member

  3. Children default to Email only (no phone)

Acceptance Criteria:

  • Preferences captured per person when multiple registrants

  • Default selection can be configured

  • All persons must have at least one channel

  • UI clearly shows which person each selection applies to

Implementation Scope:

Area Component Deliverables

Frontend

Registration Portal (Angular)

Per-person preference display, grouped checkbox layout, per-person validation, default selection handling

Backend

admin-service (Java)

Per-person preference storage, default preference configuration in ProcessDefinition

Outcome: Individual preferences captured for each family member.

12. Use Case Summary

Use Case Description Phase Azure DevOps Feature

UC-1: LinkedPerson Management

Add, search, link persons to profile

Existing

Membership Registration

UC-2: Membership Registration

Multi-person membership application

Existing

Membership Registration

UC-3: Event Participant Registration

Register participants for events

Existing + Phase 2

Event Registration

UC-4: Identity Selection

Multi-method authentication: OIDC, hash-based, guest access

Phase 2

Membership Registration, Event Registration

UC-5: Manual Payment

QR code payment handoff to staff

Phase 2

Membership Registration, Event Registration

UC-6: Event Cancellation

Cancel registrations with refund rules

Phase 2

Event Registration

UC-7: Communication Preferences

Capture notification channel preferences

Phase 2

Membership Registration, Event Registration

12.1. UC-4 Scenario Summary

Scenario Description Key Feature

4.1

Active session automatic redirect

No page displayed, immediate 302

4.2

Hash-based authentication

Secure invitation links

4.3

OIDC authentication

Google, Apple, organisation IdPs

4.4

Guest access (Quick Registration)

Walk-up registration, minimal details

4.5

Guest with relaxed matching

Known persons shown without masking

4.6

Deferred account creation

Post-registration account invitation

13. Related Documentation