Edge Canvas overview

Edge Canvas renders configuration-driven widgets inside Salesforce Lightning record pages. A canvas is a single YAML file — Salesforce queries, an optional JavaScript transform, a Handlebars template, and action definitions — rendered server-side by the Edge platform and displayed by one generic Lightning component. Operational reports, 360 views, action panels, and rooming lists that would otherwise require custom Apex and LWC development become configuration files in your tenant repository.

There is no custom Lightning code per canvas. You configure; the platform queries, transforms, and renders.

All examples in this section come from the Meridian Travel Co. reference implementation — the baseline your tenant is forked from. See How tenants work for the tenant model.

Why Canvas exists

Problem with the traditional approach	The Canvas approach
Every record-page widget needs LWC + Apex development	One YAML file per widget, no code
Apex governor limits constrain complex multi-object reports	Queries run server-side on Edge, in parallel, outside Apex governors
Every change requires a Salesforce deployment	Merge a configuration change; it is live within five minutes
Report logic hidden in code is hard to review and hand over	Declarative configuration with Git history and review

Earlier generations of this idea — org-specific pipeline frameworks that sent data to external rendering services — proved the pattern but ran on infrastructure outside the platform. Canvas is the supported, current-generation implementation: rendering happens inside the Edge platform, with the same hosting, observability, and security model as every other Edge service (see Platform architecture).

The request lifecycle

Lightning record page
  └─ edgeCanvasRunner (LWC)                     one component, reused for every canvas
       1. Resolve the Salesforce org ID
       2. GET /api/v1/resolve/{orgId}           org → tenant + correct Edge environment
       3. GET .../canvas/org/{orgId}/{canvasId}/render?recordId=...
            ├─ load canvases/{tenant}/{canvasId}.canvas.yaml from your config repo
            ├─ run the named SOQL queries in parallel (server-side, tenant OAuth)
            ├─ apply the JavaScript transform (view-model precomputation)
            └─ render the Handlebars template → HTML
       4. The component injects the HTML and wires up action buttons

Two properties of this flow matter in practice:

• Org resolution is automatic. The component sends the org ID; the platform maps it to your tenant and the right environment from your blueprint. The same page layout works in a sandbox and in production with no configuration difference.
• Queries never run in the browser. The Edge platform queries your org server-side using the tenant's stored OAuth connection, so no Salesforce session or data-access credential is exposed to the page beyond what Lightning itself provides.

What a canvas can do

• Operational reports — multi-query, grouped, formatted tables: departure rooming lists, manifests, readiness dashboards, supplier queues.
• 360 views — guest, agent, or booking summaries assembled from many objects in one card.
• Action panels — buttons that create documents, write to Salesforce, trigger payments, or open a prefilled email composer (see Actions).
• Self-service surfaces — the same engine renders customer-facing pages (excursion selection, preference forms) outside Salesforce.

Where to go next

• canvas.yaml reference — every block of the file, with examples
• Actions — buttons, api_call, and compose_email
• Salesforce embedding — the Lightning component and org prerequisites
• Authoring workflow — build, debug, and ship a canvas, by hand or with an AI agent