Actions

A canvas is not read-only. Buttons in the rendered HTML trigger actions defined in the canvas file — creating documents, writing to Salesforce, or opening a prefilled email composer. The Lightning component intercepts button clicks and POSTs them to the canvas action endpoint; no Apex is involved.

Button conventions

Actions are wired through data-* attributes on any element in the template:

<button class="slds-button slds-button_neutral"
        data-action="compose_final"        <!-- action id from the canvas file -->
        data-compose="true"                 <!-- compose actions: no new tab -->
        data-confirm="Send the final list?" <!-- optional confirmation dialog -->
        data-targetrecordid="{{hotel.Id}}"  <!-- any data-* becomes formData.* -->
        data-hotelassignmentid="{{hotel.Id}}">
  Send Final Rooming List
</button>

Attribute	Purpose
data-action	Names the action to execute. Required.
data-confirm	Shows a browser confirmation before executing.
data-compose	Marks a compose_email button so no placeholder tab is opened.
data-* (anything else)	Collected into formData and available to the action's parameter templates as {{formData.<name>}}.
class canvas-refresh	A pure client-side refresh button — reloads the canvas without any action.

Every action also automatically receives the record ID, the org ID, and the triggering Salesforce user's ID, name, and email — so downstream services can attribute the work to the person who clicked.

api_call

Calls an Edge API endpoint with substituted parameters. This is how canvases create documents, write Salesforce records, trigger auto-pay operations, and reach any other platform capability.

actions:
  send_confirmation:
    type: api_call
    method: POST
    endpoint: /api/v1/documents/send
    parameters:
      itineraryId: "{{recordId}}"
      docType: booking_confirmation
      sfEnvironment: "{{connection.environment}}"
    on_success:
      refresh: true
      toast: "Confirmation sent"
    on_error:
      toast: "Send failed: {{error.message}}"

• Substitution — parameter values support {{recordId}}, {{formData.*}}, {{connection.tenant}}, {{connection.environment}}, and platform URL placeholders. Substitution is recursive through nested objects and arrays.
• on_success — any combination of refresh (re-render the canvas), toast (message, with {{result.*}} substitution from the response), redirect (open a URL, e.g. {{result.editorUrl}}), and copy (copy a URL to the clipboard).
• on_error — a toast template with {{error.message}} available.
• method: GET sends parameters as query string; other methods send a JSON body.

compose_email

Renders a second canvas server-side and opens the standard Salesforce email composer prefilled with the result. The user reviews the email and presses Send themselves — nothing is sent automatically, and the send behaves exactly like any user-composed Salesforce email.

actions:
  compose_final_standard:
    type: compose_email
    render_canvas: rooming-list-email-final      # the email canvas, same tenant
    target_record_id: "{{formData.targetrecordid}}"
    parameters:                                   # become the email canvas's bind params
      recordId: "{{recordId}}"
      hotelassignmentid: "{{formData.hotelassignmentid}}"
    on_error:
      toast: "Could not prepare the email: {{error.message}}"

The referenced email canvas is an ordinary canvas with two conventions:

1. Its template uses style: standalone and renders the full email body HTML.
2. Its transform sets two extra keys: emailSubject (string) and emailTo (comma-separated addresses). Both are typically derived from the queried data — for example, a subject assembled from the departure dates, package name, and hotel, and recipients drawn from an operations inbox plus the supplier's reservations contacts.

The action responds with the rendered body, subject, recipients, and target record; the Lightning component opens the Global.SendEmail quick action with those values prefilled. Because a human sends the email from the composer, these sends do not consume Salesforce's automated-email allowances.

Splitting the on-screen report and the email letter into separate canvases keeps each one simple, and lets one report offer several email variants (preliminary vs. final, per-hotel vs. combined) as separate buttons.