Edge Webforms overview

Edge Webforms turns website enquiry forms into qualified Trips in Salesforce — validated, deduplicated, and (optionally) scored with a priority tier — driven entirely by YAML configuration in your tenant. There is no per-customer code; you configure the form fields, field mapping, dedup rules, and scoring rules in two files, and the platform handles the rest.

All examples in this section come from a worked configuration. See How tenants work for the tenant model.

The intake pipeline

A webform submission moves through six stages:

1. The customer's website posts to the intake API. The website backend calls POST /webform/trip with a JSON body containing the form answers and an authentication header. The intake API is option-independent: the same endpoint serves embeddable Web Component forms (Option 1) and customer-hosted forms posting via REST (Option 2).
2. Validation. The payload is validated against a Zod schema. Missing or malformed fields are rejected with a structured 400 response listing the invalid fields.
3. Field mapping. Webform field keys are translated to Salesforce field API names using trip-mapping.yaml. Picklist values are resolved dynamically from the org's metadata. Conditional fields (e.g. "Travel Year Other" only when Travel Year = Other) are evaluated.
4. Dedup check. Configurable rules query the org for existing Trips that match the submission (e.g. same email + same tour within 30 days). A match can reject the submission (409 with the existing Trip ID) or link it to the existing conversation.
5. Person Account matching. EDGE queries the org for an existing Person Account by email (and optionally phone). If found, the Trip is linked to the existing Account at creation. If not found, the Trip is created without an Account link — the Sales Agent creates the Person Account when the Trip advances to Qualified status.
6. Scoring (optional). When intelligence.enabled: true, YAML rules evaluate the form answers, accumulate a numeric score and tags, assign a priority tier (e.g. Urgent, Standard, Quick Quote), and generate routing recommendations. This step is skipped when intelligence is disabled.
7. Salesforce write. A Trip record is created via the admin-backend write proxy with the mapped fields, dedup result, matched Account, scoring fields, and (if B2B) the matched Travel Agent Account.

What you configure

File	What it controls
enquiries.yaml	Form fields, branding, dedup rules, intelligence (scoring rules, tiers, routing), AI analysis, tracker, multi-brand
webforms/trip-mapping.yaml	Webform key to Salesforce field mapping, picklist value maps, conditional population rules

Both files live in your tenant folder in the configuration repository and are editable via the EDGE editor or a merge request.

Authentication

Environment	Mechanism	Header
Local dev	Dev bypass (no key needed)	—
Sandboxes (sf-devs, staging)	Static API key per tenant	x-webform-key: <key>
Production	OAuth2 client_credentials (Keycloak)	Authorization: Bearer <JWT>

Sandbox API keys are issued by Kaptio and stored in the platform vault. Production uses a Keycloak confidential client with short-lived JWTs validated via JWKS on every request.

Capabilities

Capability	Status
Intake API (POST /webform/trip)	Production
Zod payload validation	Production
Configurable field mapping (trip-mapping.yaml)	Production
Configurable dedup rules (email, tour, phone, accreditation number)	Production
Multi-brand support (origin site routing)	Production
B2B travel agent handling (accreditation number, agent Account matching)	Production
Embeddable Web Component (<edge-enquiry-form>)	Available (not required for API integration)
Visitor tracker (page views, scroll depth, return visits)	Available (optional add-on)
YAML-configured scoring and priority routing	Available (enable per tenant)
AI enquiry analysis (intent classification, lead summaries)	Planned
Visual configuration UI (rule builder, score simulator)	Planned