Skip to content

Email + PDF Attachment from Forms

When a PCA form is submitted, the Generic Task Completion Workflow can: 1. Generate a PDF from the Word Connector template 2. Store it in EDRMS under a unique filename 3. Send it as an email attachment to a specified recipient

All driven by platform form items in the Email and DocEx blocks — no workflow modifications needed.

Prerequisites

  • Form has the Email block and DocEx block (copied from an existing PCA form).
  • Form has a Word Connector template configured.
  • Form has a working Submit Request button.

Step 1 — Set the Form Document Name (Unique Filename)

Why: EDRMS and the email attachment both use this name. Must be unique per submission.

Where: Email block → form_document_name (or Form Document Name)

How: 1. Click Form Document Name → remove any static default value 2. Set Value → Formula → Add Calculation → String type 3. Build the expression:

"Component Replacement Request " + [V.QL_PropertyID] + " " + currentDate()

Replace the prefix with your form name.

Tip: Copy the expression from an existing form (e.g., Written Scheme Review, Building Safety Check) and adapt it.

Step 2 — Set the Email Attachment Name (adds .pdf extension)

Where: Email block → form_email_attachment_name

Expression: 

[V.form_document_name] + ".pdf"

Add a space before the + operator. Do NOT add a space inside ".pdf".

Step 3 — Set the Email Subject

Where: Email block → form_email_subject

Expression: 

"Component replacement request for " + [V.QL_PropertyID]

Step 4 — Set the Email Body

Where: Email block → form_email_body

Expression: 

"Attached is the " + [V.component] + " component replacement request for property reference " + [V.QL_PropertyID] + " on " + [QL_StartForm].toString("DD")

Key notes: - Add spaces inside speech marks at text/variable boundaries — otherwise words run together. - Use .toString("DD") when concatenating a date field into a string. - JavaScript expressions are case-sensitive.

Step 5 — Set the Email Recipient

Use environment-aware visibility so Dev/Test don't accidentally send to real staff: - In Dev/Test: send to a test mailbox or your own email - In Live: send to the real recipient team address

Configure via the Email block's recipient form item with a visibility formula that shows the Live recipient field only when the environment is Live (using Z_ImplicitDebug or a resource-based flag).

Step 6 — Activate and Test

  1. Activate the new form version.
  2. Submit the form on a test device.
  3. Check the workflow instance in Management Studio — look for the document generation and email steps.
  4. Verify the PDF was received at the test email address.

Quick Tips

  • Always look at an existing working form before building email/document config from scratch.
  • The currentDate() function is available under Functions in the formula editor.
  • If the document name formula isn't evaluating, check for missing spaces around + operators.

Troubleshooting — Emails Stopped After Saving a New Template

Symptom: Emails were working. After saving a new or updated Word Connector template to the server, emails stop arriving. No workflow errors visible in Management Studio.

Root cause: One or more FormItem fields used in the template have availableForDocumentRendering=False in the form XML. When the template is saved to server, the server-side renderer marks those fields as invalid. On next submission, document generation fails silently and the email step is skipped without logging an error.

Detection: Open the .docx in Word → Server Connection. The dialog will show: "N invalid display items". If N > 0, the template is broken.

Fix procedure: 1. In the form XML (extracted/forms/Forms/<FormName>.form), find every FormItem used as a merge field in the template and ensure it has: 

<Property name="availableForDocumentRendering">
  <Value>True</Value>
</Property>
2. Rebuild the .ftpackage and import it into the environment (see deployment/dev-to-live.md) 3. Re-open the .docx in Word → Server Connection → confirm "0 invalid display items" 4. Click Save to Server 5. Test by submitting the form and verifying the email arrives

Quick fix (if template worked before): Temporarily re-save the previous known-good template to the server. This immediately restores email delivery while you fix the form XML.

This failure mode is especially common when adding new z_* String fields to a form via XML patching — the default value for availableForDocumentRendering is False, so any new field added without explicitly setting it True will break the template.