Dynamic attachments for Email Templates (auto-attach the latest Document)

[pehoma]

Hi everyone,

we use Email Templates extensively and often need to include standard PDF attachments—e.g., our Terms & Conditions, a price list, or informational leaflets. Today, EspoCRM lets you add attachments to a template, but they’re stored statically. If a file changes, we have to update the attachment in every template that uses it.

Our use case

• We have ~100 templates that all include our T&Cs.
• When the T&Cs change, we must open each template and replace the attached file manually.
• This creates a lot of admin overhead and risks outdated files being sent.

Requested improvement
Allow each Email Template to reference one or more Document records (from Espo’s Documents module) instead of storing the binary file statically. At send time, EspoCRM would fetch and attach the current file from the linked Document(s). In other words, the attachment is resolved dynamically, so senders always include the most up-to-date PDF without editing the template.

Why this helps

• Single source of truth: Update the Document once; all templates use the new version automatically.
• Lower maintenance: No more mass updates across many templates.
• Fewer mistakes: Reduces the chance of sending outdated terms or price lists.
• Auditable & permission-aware: Still respects Document permissions and versioning.

Possible implementation ideas

1. Template–Document link field:
   • Add a relationship on Email Template (e.g., “Linked Documents”).
   • On email generation, Espo collects these Document files and attaches them to the email before sending.
2. Tag/category-based lookup (optional):
   • Template stores a tag like terms-current or price-list-current.
   • At send time, Espo finds the latest active Document with that tag and attaches it.
3. Version handling:
   • Always attach the latest file associated with the Document.
   • Optionally allow “pinning” a specific version when needed.
4. Fallback & validation:
   • If a referenced Document is missing or not accessible due to permissions, show a clear warning in the compose screen (or block send, depending on admin setting).

Minimal acceptance criteria

• Ability to link one/multiple Documents to an Email Template.
• On send, the email includes the current file(s) from those Documents.
• Respects Document ACL/permissions.
• UI clearly distinguishes static attachments from dynamic (Document-based) attachments.

Nice-to-haves

• Support in Workflows/BPM & API.
• Admin setting: block send if a required dynamic Document is unavailable.
• Support for “category/tag” lookups in addition to direct links.

This would dramatically simplify maintenance for teams who rely on standardized attachments. Happy to help test or provide more details about our setup if useful.

Thanks!

[yuri]

Hi,

Just noting that as it's feature request, "Minimal acceptance criteria" does not fit it. The feature request makes sense. BTW we also ask not to heavily use LLMs in the feature request guidelines. I assume that 'the latest document version' concept came from an LLMs, as we don't have document versioning in Espo.

[pehoma]

Hi Yuri,
Thanks for the quick response—and fair points.

• I’ll drop the “Minimal acceptance criteria” phrasing. You’re right: this is a feature request, not a spec.
• Noted on the guidelines about LLM use. I’ll keep future requests concise and written manually.
• Re “latest version”: understood—Espo doesn’t have document versioning. My intent was simply “attach the current file of the linked Document at send time.” No versioning needed.

Restating the request more simply: Allow an Email Template to link to one or more Document records, and when an email is generated, Espo attaches the current file from those linked Documents (respecting existing permissions).

[shalmaxb]

I do not know, if it would meet the complexity of all your requirements, but I would think in creating a custom entity for these documents (doing such process in the default documents could possibly lead to difficulties, because there would be many condition come into play).
A custom entity could mirror all the types of documents for this case and alle the conditions. Then you could relate the documents, also with conditions, to the Email entity and even automate many use cases by formula.
Just a raw idea.