Demo

Create an Airline Disruption Recovery application that helps airline operations teams manage passengers affected by cancellations, major delays, airport closures or other disruptions.


Core Workflow

Use Disruption Event as the single parent workflow:

Disruption Received → Review Affected Flights → Segment Passengers → Recover Passengers → Verify Recovery → Resolve

A disruption is received from the Flight Operations System through an Inbound API. The event contains the disruption reason, airport and affected flights. Retrieve the passenger manifest for each affected flight from the Reservation System.

Caseworker Journey

Notify the assigned Disruption Caseworker when a new disruption occurs.

The caseworker opens one operational workspace showing:

- disruption details and recovery progress
- affected flights
- passenger manifest
- passenger segments
- active recovery workflows
- unresolved exceptions

The caseworker can select one or multiple affected flights and view their combined passenger manifest.

Allow passengers to be filtered using simple operational metadata including:

destination, age group, travelling party/family, priority status, cabin class, connection status, special/medical assistance, alternative-flight status, hotel requirement and recovery status.

The caseworker can select filtered passengers and create named Passenger Segments, for example:

- New York passengers needing alternative flights
- Passengers requiring overnight accommodation
- Families travelling with children
- Passengers requiring special or medical assistance

Recovery Actions

For any Passenger Segment, allow the caseworker to trigger one or more child recovery workflows:

Alternative Flight
Search available flights → caseworker selects/assigns flight → book passengers → update recovery status.

Hotel & Services
Search available hotels → allocate rooms → arrange meals/ground transport if required → confirm services.

Passenger Assistance
Review assistance requirement → arrange wheelchair, accessibility, family or medical assistance → confirm service.

Passenger Communication
Send confirmed recovery information through WhatsApp, with SMS/email fallback.

Multiple recovery workflows may run in parallel for the same segment.

Parent/Child Dependency

All recovery workflows must remain associated with the parent Disruption Event.

The parent must remain in Recover Passengers while mandatory child recovery workflows are active.

Use a dependency/wait condition so the parent cannot progress to Verify Recovery until its required child workflows are completed or updated to an accepted final status.

Tracking

Keep tracking simple.

At Disruption level show:

Affected | Recovered | In Progress | Unassigned | Exceptions

At Passenger Segment level show:

Passenger Count | Recovery Service | Progress | Status

At Passenger level use only:

Not Assigned | In Progress | Recovered | Exception

Allow the caseworker to drill from any count directly into the corresponding passengers.

Integrations

Use:

- Flight Operations System: Inbound API for disruption and flight information
- Reservation System: passenger manifests, alternative-flight search and rebooking
- Hotel Service: hotel availability and booking
- Ground Transportation Service: transport booking
- Messaging Service: WhatsApp Business, with SMS/email fallback

Personas

Use only two internal personas:

Disruption Caseworker: manages flights, passengers, segments and recovery actions.

Disruption Supervisor: monitors overall progress, workload and exceptions and can reassign/escalate work.

Keep the application straightforward and operational. Avoid unnecessary workflows, approvals and screens.

The primary experience should remain:

Disruption → Flights → Passengers → Segments → Recovery Actions → Track Completion → Resolve.

Comments

Popular posts from this blog

D2 install

Common Lines Finder Java

D2-Ref