A declarative rules engine for the Kaptio platform. Fees, surcharges, eligibility gates, acknowledgments, and alerts -- configured by operators, evaluated on Edge, enforced everywhere.
Every tour operator has hundreds of business rules -- booking fees, surcharges, eligibility checks, warnings, approval gates. Today they are scattered across four different layers, each with its own pain.
Custom code that fires on object insert/update. Hard-coded logic.
Developer required to change. Deploy risk. Hard to debug at runtime.
Visual automation built in Flow Builder. One flow per scenario.
Version sprawl. Harder to test. Admin-gated. Difficult to audit logic.
Field-level blocks in Salesforce. One formula per rule.
Cannot explain why a user sees an error. No debugging. Static formulas.
Unwritten rules in operator heads. "We always charge this fee on that channel."
Lost when the person leaves. No consistency. Rules applied unevenly across teams.
Every rule change today involves a developer, an admin, or a veteran operator with context nobody else has. Rules conflict with each other, fire inconsistently, and are nearly impossible to audit. Edge Rules centralizes this layer so operators own it, developers do not gate it, and everyone can see exactly what fired on which booking and why.
Every rule in Edge Rules follows the same structure: WHEN something happens, IF a set of conditions match, THEN do these actions.
Lifecycle events that Edge Rules listens for. Pricing completion, status change, document send, page load.
itinerary.priceditinerary.updatedpayment.requesteddocument.sendingstatus.changedpage.loadedComposable predicates with AND/OR logic. Check fields in the request context or run SOQL against the live booking data.
Total < $1,000Channel contains "Direct"All items are rail-familyDeparture within 14 daysMargin below 5%Passenger count > 6Bounded, auditable effects. Create a line item, set a field, block a workflow, send a notification, prompt a user to acknowledge.
add_itinerary_itemremove_itinerary_itemblock_actionset_fieldsend_notificationrequire_acknowledgmentA rail-only booking fee rule written as declarative YAML.
# Rail-only booking fee on direct channels under $1,000
- id: rail-booking-fee
name: Rail-Only Booking Fee
mode: silent
enabled: true
triggers:
- itinerary.priced
conditions:
all:
- source: context
field: total_sell_price
operator: less_than
value: 1000
- source: context
field: channel_name
operator: contains
value: Direct
- source: query
query: |
SELECT Id FROM KaptioTravel__Itinerary_Item__c
WHERE KaptioTravel__Itinerary__c = :itineraryId
AND Service_Type__c NOT IN (Rail, ManualRail, Transfer, Promotion)
AND Edge_Rule_Marker__c = null
expect: no_results
actions:
- type: add_itinerary_item
params:
item_id: <booking fee catalog item Id>
price_category_id: <price category Id>
sell_price: 50
external_marker: EDGE_RULE_RAIL_BOOKING_FEENo Apex. No Flow Builder. No managed package extension. This is the whole rule.
Not every rule should act silently. Some should block, some should prompt the user, some should alert someone else. Edge Rules offers four distinct modes covering the full spectrum of operator intent.
The rule fires in the background and applies its action. The user never sees it happen -- they just see the outcome on their booking or quote.
User sees the result (e.g. booking fee line) but is never interrupted.
The rule prevents the action entirely. User cannot proceed until the underlying condition is resolved.
User sees a clear block message explaining why the action cannot continue.
The rule stays dormant until it matches. When it does, a dialog requires the user to explicitly acknowledge before proceeding. Creates an audit record.
User sees a confirmation dialog. Reads. Accepts. Continues. The acknowledgment is recorded.
The rule fires an alert through Slack, email, or in-app notifications but does not interrupt the workflow in progress.
User continues their work. A target party receives the notification.
Acknowledge is the mode most travel operators have been unable to build cleanly in Salesforce. It is a soft gate -- not a hard block, not a silent action, but a required moment of explicit awareness, captured as an audit record. Zero-margin quote warnings. Travel advisory confirmations. Visa requirement reminders. Late booking fee notifications. Anywhere you need an agent or a customer to pause and actively confirm before moving forward, acknowledge is the right mode.
Edge Rules renders the acknowledgment inline through a lightweight canvas runner that stays dormant until a rule fires. No interruption when no rule matches. Clear, recorded consent when one does.
Edge Rules is designed to hold every operational rule your business depends on. Here is a catalog of rules that Edge Rules can express today, organized by category. Start with one, add more as you go.
Charges added automatically based on booking composition, channel, or lead time.
Apply fee when all items are rail-family and total is below threshold
itinerary.pricedAdd fee when departure is within configurable days
itinerary.createdCharge fee for changes after confirmation
itinerary.updatedApply different surcharges by booking channel
itinerary.pricedAdd supplement when passenger count is below group threshold
itinerary.pricedApply card-type specific fee at payment
payment.method_selectedEnsure agents and customers see the right warnings, acknowledgments, and required information.
Require acknowledgment for destinations with active advisories
document.sendingRemind agent to communicate visa requirements before send
document.sendingBlock document send if no insurance on booking
document.sendingShow customer that on-request services are not yet confirmed
document.generatingBlock confirmation without passport data
status.changedPrevent payment collection when the booking is not ready or eligible.
Prevent payment until supplier confirms all services
payment.requestedPrevent booking exceeding account credit
itinerary.pricedPrevent payment on quotes past their expiry date
payment.requestedPrevent bookings during operator-defined blackouts
itinerary.createdCustomer confirms they understand the FX fee
payment.requestedNotify the right person when something commercially significant happens.
Slack alert when a booking exceeds threshold
itinerary.pricedAgent confirms low-margin quote before sending
document.sendingEmail rep when quote has been sent for more than X days with no action
page.loadedRequire manager acknowledgment above threshold
status.changedFlag returning customers for loyalty offer
itinerary.createdCatch data issues before they cause downstream problems.
Block document send when lead passenger has no email
document.sendingWarn when phone number does not match E.164
itinerary.updatedBlock child passenger without valid age
itinerary.updatedWarn when passengers exceed room capacity
itinerary.updatedNotify ops when inventory falls below reorder threshold
itinerary.createdA common travel industry scenario: apply a booking fee to rail-only bookings below a configurable threshold, varying by channel. A single rule in Edge Rules delivers it end to end.
Add a booking fee to rail-only bookings below a dollar threshold, configurable by channel. A common travel industry requirement that would traditionally take 3 to 4 weeks of custom Salesforce development.
Written in YAML in about 15 lines. Threshold, channel match, rail-only check. No Apex, no Flow, no managed package change.
A Salesforce Flow on pricing completion calls the Edge Rules evaluator via an Apex Queueable. Evaluates in under one second.
When a matching booking is priced, a line item is created against a pre-configured catalog item. Taxes and commissions calculated by the managed package pipeline. Idempotent, auditable, operator-tunable.
The booking fee appears as a first-class line item on the itinerary, visible in the builder and costings, participating in the total rollup. It prints on customer documents alongside every other service line. The rule is operator-tunable, rerunnable, and fully traceable.
Edge Rules is a horizontal layer consumed by every other Edge service. The same rule can fire from a document, a payment page, a canvas dashboard, or a customer-facing booking flow.
Consumes rules at document.generating and document.sending triggers. Acknowledgments and gates fire before a customer receives the quote.
Consumes rules at payment.requested and payment.method_selected. Gates block ineligible payments; silent rules add surcharges.
Can render acknowledgment prompts inline on any record page, triggered by page.loaded or data.changed events.
Consumes rules during the customer-facing booking flow to apply fees, surcharges, and eligibility checks pre-confirmation.
The platform work has been in development for six months. Phase 1 is production-ready today. Phases 2 through 4 are on the near-term roadmap, shaped by what our first customers need.
Production-ready for fee rules, surcharges, and hard blocks.
The canvas-runner pattern: silent until triggered, then renders a confirmation prompt inline.
A visual builder so operators can create, test, and manage rules without touching YAML.
Rules that understand the lifecycle of the booking and reconcile when conditions change.