Documentation

Action Settings

Explore Govform.com guidance, configuration details and practical steps for action settings.

Template notification email actions

Use the template notification email action when your organisation has a configured notification provider and the email body is maintained as an approved provider template. The service supplies the recipient and the values that fill the template’s placeholders.

This action is a good choice when content must be consistent across several services or when template changes need to be managed outside the individual service. It is not a substitute for designing a clear confirmation page in the service itself.

Prepare the template before the service action

Create and approve the email template in the configured notification service first. Record its template ID, the exact placeholders it expects, whether it supports attachments, and who owns future changes.

flowchart LR
  A[Approved notification template] --> B[Template ID]
  C[Validated service answers] --> D[Recipient and variable mappings]
  B --> E[Template notification email action]
  D --> E
  E --> F[Recipient receives a completed message]

The service cannot compensate for a template whose placeholders are missing or ambiguous. Give placeholders clear business names such as reference, next_step and contact_name, and keep a simple mapping record with the service.

Configure the action in Builder

  1. Open Page actions, choose Add action, then select the template notification email action.
  2. Set an Action ID and name that identify the event, for example send_decision_email.
  3. Enter the configured Notification template ID.
  4. Set the Email address with a fixed value or Liquid expression.
  5. Add the template variable keys and their matching values.
  6. Add attachment variables only where the approved template expects them.
  7. Select a trigger after validation or at completion, as appropriate.
  8. Test the full delivery route in QA with safe representative data.

The recipient address and template ID are required. Treat both as a dependency: an otherwise correct action cannot send a useful email without them.

Map values precisely

The Template variable key is the placeholder name from the provider template. The matching Template variable value is the service value that should replace it. Values can use Liquid, which is useful for fields and results prepared by earlier actions.

Template variable Example value source Check
reference assigned reference number exists before the action runs
name user-provided preferred name optional value is handled gracefully
next_step calculated instruction makes sense for every route that sends the email

Do not put display formatting, data cleanup and delivery logic into one large template expression. Use a preceding Assign action when a value needs transforming; it makes the email mapping easier to review and test.

Attach documents only when needed

Pair an Attachment variable key with the file or generated document that should fill it. The file must exist before this action runs. If it is generated by a preceding PDF or document action, order the actions so generation completes first.

Check that an attachment is relevant to the selected journey, safe for the recipient, and named clearly. Test the route with no attachment as well as the expected attachment route, so that an optional file does not cause a delivery failure.

Avoid duplicate or premature messages

Use After validation when the email confirms a valid page response. Use the completion trigger when it confirms the finished service. Apply execution conditions for route-specific messages, such as only sending a message when a person opted into updates.

Avoid a page-load trigger unless the page is explicitly designed to send on every visit. People can return to a page, refresh it or resume a draft; the service must not produce an unexpected duplicate message.

Test checklist

  • The template ID identifies the approved email template.
  • Every required template variable has a matching service value.
  • Optional values do not create an unfinished or misleading message.
  • The recipient expression resolves to the intended address for each route.
  • Attachments are produced before the email action and are sent only when relevant.
  • The trigger and conditions prevent duplicate or premature sends.
  • The rendered QA email has been checked, including recipient, content and attachments.

Related guidance

Keep exploring

Explore more documentation

View all categories →