Articles · Data tables

Preview a Kition workflow email without sending it

Inspect the resolved recipient, subject, and body against a sample record while the workflow stays disabled and no email connection is created.

Kition Team·Sep 2, 2026·4 min read

Use preview as a safety boundary

An email workflow combines table data with an external side effect. Preview the resolved message before configuring delivery or enabling the workflow. A successful preview should not send mail, enable the workflow, or create a connection automatically.

Choose a representative record

  • Use a record that contains every field referenced by the recipient, subject, and body.
  • Include realistic punctuation, multi-line notes, and optional values.
  • Avoid real personal data when a controlled example is sufficient.
  • Confirm the sample comes from the table bound to the trigger.

Inspect every resolved field

Read the preview as the recipient will see it. Confirm the To address, subject, labels, spacing, and substituted values. A valid-looking email address in the wrong field is still an incorrect binding.

  • Recipient resolves to the intended address.
  • Subject describes the actual trigger event.
  • Body values belong to the selected record.
  • Missing values are visible rather than silently replaced by unrelated data.
  • Sensitive fields that are not needed are omitted.

Keep the workflow disabled

During preview, the workflow should remain disabled and no SMTP or provider connection should be created automatically. If the workflow already has a connection, preview must still avoid the delivery action.

The Leads Landing Page starter and its notification workflow are documented on the template page and completed example.

Test missing and renamed fields

  • Temporarily select a record with one optional value missing.
  • Confirm a renamed or removed field is reported as unresolved.
  • Do not accept a different similarly named field as an automatic substitute.
  • Ensure preview failure leaves the workflow configuration unchanged.

Configure delivery only after approval

After the owner approves the resolved message, configure the supported email connection, send to a controlled address, and inspect the delivered result. Only then consider enabling the trigger for live records.

  • Start with one controlled recipient.
  • Verify sender identity and reply behavior.
  • Check rate, privacy, and unsubscribe requirements for the use case.
  • Monitor run history after enabling.

Save an approval record for the message template

Before the first controlled send, preserve the workflow name, trigger, selected sample record, resolved recipient pattern, approved subject, required body fields, and reviewer. The purpose is to make later edits reviewable, especially when a form or table schema changes.

Repeat the preview after any change to field names, conditional content, sender identity, recipient rules, or privacy language. A preview approved last month does not validate a newly added field today. If the workflow can notify multiple people, test each recipient rule with synthetic or controlled records and confirm one record cannot unexpectedly resolve to an unrelated address.

  • Keep production delivery disabled during composition review.
  • Use a controlled address for the first real send.
  • Record the exact template version that received approval.

A preview is not proof of delivery

Preview verifies field resolution and message composition. It does not prove provider authentication, deliverability, spam placement, or the final behavior of attachments and rich formatting. Those checks require a controlled send after the preview is approved.

The controlled send should use the same representative record that was approved in preview. Compare the delivered To address, subject, line breaks, substituted values, sender name, and reply behavior with the saved preview. If the provider changes formatting or removes content, revise the message and repeat the controlled test before enabling live delivery.

Also test what happens when the workflow is retried. A provider timeout can leave uncertainty about whether the message was accepted. The run history should make the outcome visible, and the team should have a policy for avoiding accidental duplicate notifications. Preview cannot answer that question, but it can ensure the retry is at least based on the correct recipient and content.

  • Use a non-production recipient for the first send.
  • Check provider logs and the received message together.
  • Keep the workflow disabled until delivery and retry behavior are understood.

Keep reading