The Trip conversion guide

The Trip conversion guide is a panel on the Lead (or custom enquiry) record page that turns a qualified enquiry into an Account, an optional agent Contact, and a Trip — in one click, with your existing customers and agencies matched first so nothing is duplicated. It is an Edge Canvas driven entirely by the lead_to_trip block in enquiries.yaml.

Use it with either two-stage intake shape — Lead capture or a custom enquiry object — as described in Choosing your intake object. It also works for enquiry records created outside Edge Webforms (imported leads, manually created records): the panel reads the record, not its origin.

What the agent sees

On an unconverted record, the panel shows:

A summary card — name, company, email, phone, status.
A section per conversion path (travel agent and/or direct customer, whichever you enable):
- Matched candidates as cards — agencies matched by company name, customers matched by email — each with a one-click convert button.
- Open Trips per matched account — each with an Attach to this trip button, for enquiries that belong to an existing Trip rather than a new one.
- Fallback actions — create a new agency from the record, or convert as a new direct customer.

Every button states exactly what it will do and asks for confirmation. After converting, the panel shows a converted banner with an Open the Trip link, and the record is marked converted with the Trip reference stamped on it.

The two conversion paths

Path	For	What happens
`business_account`	Travel agent (B2B) enquiries	The agency Account is matched by name (or created), the agent Contact is matched by email within the agency (or created), and the record is converted against that pair
`person_account`	Direct guest (B2C) enquiries	The customer PersonAccount is matched by email (or created), and the record is converted against it

Both paths then either create a new Trip (record type, status, group size, and field mapping from config) or attach the record to an existing open Trip the agent selected.

What the record needs to look like

Matching is driven by the record's fields, so intake quality determines conversion quality:

Field	Direct guest (B2C)	Travel agent (B2B)	Why
First / last name	Required	Required (the agent person)	Names the created records
Email	Required for matching	Recommended	B2C: matches the existing customer. B2B: matches the agent contact within the agency
Company / agency name	Leave empty	Required	Drives agency matching (name contains). On Lead sources, an empty Company is also what makes Salesforce convert to a PersonAccount
Phone	Recommended	Recommended	Carried onto created records; some orgs require a phone on the Trip's primary contact

Configuration: the `lead_to_trip` block

The block lives in enquiries.yaml, next to your form configuration. A worked example for Meridian Travel Co., capturing to the Lead:

lead_to_trip:
  enabled: true
  default_path: person_account

  # Trips offered as attach targets on the panel (per matched account)
  trip_candidates:
    statuses: [Enquiry, Qualification]
    per_account: 3

  lead:
    converted_status: Qualified          # Lead status set by conversion
    converted_trip_field: Trip__c        # Lead field stamped with the Trip id

  paths:
    business_account:
      label: Travel Agent
      account:
        record_type: Agent               # agency Account record type
      trip:
        status: Enquiry
        name_suffix: " — Trip"
        default_group_size: 1            # satisfies org validation rules
    person_account:
      label: Direct Customer
      trip:
        status: Enquiry
        name_suffix: " — Trip"
        default_group_size: 1
        field_mapping:
          Description: Enquiry_Notes__c  # record field -> Trip field

Using a custom enquiry object instead of the Lead

Add a source block naming your object and its fields. Everything else — the panel, matching, Trip logic, guards — is identical:

lead_to_trip:
  enabled: true
  default_path: person_account

  source:
    object: Enquiry__c
    fields:                              # configure each field you use
      first_name: First_Name__c
      last_name: Last_Name__c
      email: Email__c
      phone: Phone__c
      company: Agency_Name__c
      status: Status__c                  # required: carries the converted marker
    converted:
      status_value: Converted            # written on conversion; the idempotency marker
      account_field: Account__c          # optional: stamped with the resolved Account
      contact_field: Agent_Contact__c    # optional: stamped with the resolved Contact

  lead:
    converted_trip_field: Trip__c        # source field stamped with the Trip id

  paths:
    business_account:
      label: Travel Agent
      account: { record_type: Agent }
      trip: { status: Enquiry, default_group_size: 1 }
    person_account:
      label: Direct Customer
      account: { record_type: PersonAccount }   # REQUIRED for custom sources:
      trip: { status: Enquiry, default_group_size: 1 }  # Edge creates new customers itself

Custom-source specifics:

source.fields.status is required — it carries the converted marker. Unconfigured fields are simply not queried, and the matching that depends on them (email → customer, company → agency) is skipped.
No Salesforce lead conversion is involved. The record is marked converted — status value plus the trip/account/contact stamps — in a single update while it is still writable.
New direct customers are created by Edge, so the person_account path must name a person-account record type. Without it, converting an unmatched direct enquiry is rejected with a clear message.

The full field-by-field schema is in the enquiries.yaml reference.

Behaviour guarantees

The conversion engine is deliberately conservative:

Nothing is mutated before the request is coherent. A supplied Trip is verified to exist — and to belong to the selected account — before any record is created or updated. Attaching a Trip to a to-be-created account is rejected outright.
Stamping happens while the record is writable. On Lead sources, the Trip is created and stamped on the Lead before the native conversion (converted Leads are read-only in most orgs). The one exception — a brand-new direct customer, which Salesforce creates during conversion — stamps afterwards, best-effort, and reports a warning if the org rejects it (see Salesforce setup for the permission that removes this caveat). Custom sources have no such constraint.
Converting twice is idempotent. An already-converted record returns its existing Account, Contact, and Trip without creating anything. A converted record that lost its Trip reference can be repaired by converting again with an explicit Trip selected.
Org validation rules surface to the agent. If Salesforce rejects a record (a validation rule, a required field), the panel shows the org's own message rather than a generic error — the agent can fix the data and retry.

The canvas

The panel is a standard Edge Canvas: a lead-to-trip.canvas.yaml in your tenant's canvas folder with a data source for the record context and a convert_lead action. The action carries the agent's choice (path, account, existing trip) as parameters:

actions:
  convert_lead:
    type: api_call
    method: POST
    endpoint: /api/v1/lead/convert
    parameters:
      tenantId: "{{connection.tenant}}"
      sfEnvironment: "{{connection.environment}}"
      leadId: "{{recordId}}"
      conversionPath: "{{formData.conversionPath}}"
      accountId: "{{formData.accountId}}"
      tripId: "{{formData.tripId}}"
      createNewAccount: "{{formData.createNewAccount}}"
    on_success:
      toast: "Lead converted — opening Trip"
      refresh: true
      redirect: "{{result.tripPath}}"
    on_error:
      toast: "Conversion failed: {{error.message}}"

Your implementation starts from the reference canvas — ask your Kaptio team for the current baseline, then adjust labels and confirmation copy to your terminology. Embedding the canvas on the record page is covered in Salesforce setup.

API

The panel is the intended surface, but the underlying endpoints are documented in the API reference for integration testing and automation.

What the agent sees​

The two conversion paths​

What the record needs to look like​

Configuration: the lead_to_trip block​

Using a custom enquiry object instead of the Lead​

Behaviour guarantees​

The canvas​

API​