Problem
When passengers are created via API instead of the Kaptio UI, the KaptioTravel__AllocationId__c (Room Group ID) field is not automatically populated. This means passengers don’t get assigned to room groups, which is required for accommodation bookings.
What We Found
Kaptio’s logic for assigning Room Group IDs (dividing passengers into pairs) runs via JavaScript controllers in the managed package Lightning/Visualforce pages. This code only executes when using the Kaptio UI - it does not run when records are created via API. This is a fundamental architectural limitation of how Kaptio currently works.
Solution
- Customer must develop custom Apex code to assign values to the KaptioTravel__AllocationId__c field when passengers are inserted
- This can be implemented as either an Apex trigger or an Apex action within a Salesforce Flow
- The custom code should mimic Kaptio’s passenger-pair room grouping logic (e.g., assign passengers 1-2 to room 1, passengers 3-4 to room 2, etc.)
- Optionally: Create a custom field to flag passengers created via API if you need to distinguish between API-created and UI-created records
- The API flag is only needed if users frequently change group sizes and room group IDs when creating itineraries manually - otherwise the new logic should not conflict with Kaptio’s
Notes
- Kaptio’s field assignment logic lives in JavaScript controllers for Lightning/VF pages, not in domain-level Apex triggers - this is why API-created records don’t get the defaults
- The majority of itineraries are for 2 passengers, so defaulting room group IDs is important as it saves manual clicks
- Customer confirmed the solution worked in UAT
- This applies to any customer doing API integrations to create passengers - they will need similar custom code
Warnings
⚠️ Ensure your custom logic does not conflict with Kaptio’s UI logic if users also create passengers manually ⚠️ Overcoming this limitation in the core product would require a complete redesign/re-architecture
Source: KHELP-12074