EspoCRM mail merge for printed letters

What EspoCRM mail merge for printed letters covers and when teams need it

Teams that still send contracts, renewal notices or compliance letters by post want those documents generated from CRM records rather than retyped in a word processor. EspoCRM can produce printable documents from records through PDF templates and through Mail campaigns, but the exact letter workflow depends on the version you install and on which extensions are enabled, so confirm the steps against that version before you commit to a design. The printing itself stays with your team or your print provider: EspoCRM generates the documents, and your existing postal process handles envelopes, franking and dispatch.

Most of the effort in this kind of project is not the EspoCRM configuration screens. It is template design, which means deciding what each letter type needs from each entity type and building one PDF template per entity and purpose, with the fields, addresses and legal wording reviewed by the people who own the content. The second area is target list discipline: a letter batch is only as correct as the list behind it, so you need clear rules for who is included, who is excluded and who approves the batch. The third is data quality. Postal addresses, salutations, company names and contact roles often differ between records, and a merged letter with a wrong name or an outdated address is a visible error. Plan a cleanup pass before the first run.

There is no separate mail server to build for printed letters, so the project scope is smaller than an email campaign rollout. Ask your DeployOpen contact or your own administrators to confirm which template engine features, campaign options and permissions your installed version provides, who will maintain templates after go-live, and how a letter batch is reviewed and logged. Those answers determine whether the work is a few templates and a short test cycle or a broader set of letter types that needs a formal approval path.

Which printed letter approach fits which mailing

This table compares single-record PDF generation, bulk letters from a target list and letters tied to a mail campaign. Read each column as one option and check the availability of each in your EspoCRM edition and version before you commit to a design.

Factor	Single-record PDF from detail view	Bulk letters from a target list	Letters tied to a mail campaign
Typical use	One letter for one customer, such as a formal notice, a quote cover letter or a reply to a complaint	The same letter sent to a defined audience, such as a price change notice or an annual account statement	A mailing that is part of a tracked campaign, where each recipient's letter is logged against the campaign
Data it needs	Clean fields on the record and any linked records the template references	A populated target list with complete postal address fields and an agreed exclusion list	A target list, a campaign record, and address and name fields that the template can resolve for every recipient
Who runs it	Account managers, service staff or back office users with the right record access	An administrator or operations user who builds the list and generates the output	Marketing or campaign owners, with an administrator checking templates and settings
Main risk	Inconsistent letters when users edit records or pick different templates by hand	Wrong or outdated addresses and duplicates on the list, leading to misdirected post	Templates that rely on fields missing for some recipients, and gaps in the campaign log if output is produced outside the campaign
Audit trail	Depends on what is saved to the record; confirm whether generated files are attached	Confirm how the list and generation run are recorded and who can view them	Usually the strongest link to recipients, but confirm what the campaign log stores for printed output
Edition and version check	Confirm that PDF templates and the generation action are available in your edition and version	Confirm the target list and bulk output options in your edition and version, including any extension needed	Confirm whether Mail campaigns produce printable letters in your edition and version before designing around them
Testing effort	Low to moderate; test each template against a sample record with missing data	Moderate; test with a small list and verify a sample of addresses before the full run	Moderate to high; test every template branch against recipients with incomplete fields

Designing PDF templates per entity type

Build one PDF template for each entity type you mail to, such as one for accounts and one for contacts, rather than a single generic letter. Each template is then tied to one set of merge fields that belong to that record type, so a field such as a contact's first name or an account's billing address always resolves from the record it was designed for. A single shared template tends to hide mismatches: a field that exists on contacts but not on accounts renders blank, and nobody notices until a letter goes out. Separate templates are also easier to review. A compliance or marketing reviewer can read one document from top to bottom and check every merge field against the layout, which is far harder when a template branches across several entity types.

Map each template field to a specific record field in the Entity Manager configuration of the entity, and keep a written list of those mappings with the template file. Confirm in your installed version which merge fields and template features are available for each entity type, because template capabilities and the attribute names shown in the editor can change between releases. Formula scripting is EspoCRM's documented scripting language, and it is the usual way to shape text, for example building a salutation from a first name and title, or showing a paragraph only when a field such as a preferred language or a reference number is filled in. Keep formulas short and document each one, since a formula that works for one record can produce an awkward sentence for another. Check the EspoCRM formula documentation for the functions supported in your version before you commit to a design.

Test every template with deliberately difficult records before anyone approves it for printing. Use sample records with empty first names, missing postal codes, company names longer than the address block, names with accents or non-Latin characters, and contacts with no linked account. Illustrative example: a contact with no salutation field filled in should still produce a complete, grammatical greeting, not a line that reads "Dear ,". Review the generated PDFs at print size, check page breaks on long paragraphs, and confirm that conditional paragraphs appear or disappear as intended. Ask the template owner to sign off each test set, and keep those test records in a sandbox so the checks can be repeated after every template or EspoCRM upgrade.

Setup sequence for a first printed mailing

This sequence takes a team from an undefined letter program to a first pilot batch of printed letters that a named owner has approved. Each step closes with a check, so problems surface on a few records before any letter reaches a printer.

Confirm edition and version
Confirm which EspoCRM edition and version you run, and whether the Advanced Pack is available, because the Mail campaign and PDF template behavior you rely on depends on them. Ask your administrator to record the exact version from the instance, and confirm with EspoCRM's current documentation that the mail merge features you plan to use exist in that version. The step is done when the version, edition and add-on status are written into the project record and the team agrees to test only on that build.
Define entity types and address fields
List the entity types that will receive letters, such as accounts, contacts or leads, and identify the address fields each one uses. Check that every address field is populated consistently, that postal fields such as street, city, postal code and country are separate, and that any custom entity has the same fields. Record gaps in the Entity Manager plan so an administrator can add missing fields before the list is built. The check is a field map signed off by the data owner, showing one address source per entity type.
Build and clean the target list
Create a target list for the first mailing, adding records only from the entity types defined in the previous step. Remove or flag records with missing or malformed postal addresses, duplicates and records that should not receive postal marketing or notices under your own consent rules. Keep an exclusion list for records to skip. The check is a list count reconciled against a report run from the source system, with every exclusion reason recorded.
Design one PDF template per entity type
Create a separate PDF template for each entity type, using merge fields that match the address and name fields confirmed earlier. Keep the layout, sender block, footer and legal text in the template so the letter can be reproduced later, and agree the wording with the business owner and, where relevant, the legal reviewer. Confirm that templates reference only fields that exist on that entity type. The check is that each template is saved, versioned in your change log, and its field references have been reviewed against the field map.
Run test generations on sample records
Generate letters for a small set of sample records per entity type, including records with long names, missing optional fields, accented characters and international addresses. Inspect each output for merge errors, empty placeholders, truncated addresses and wrong sender details. Repeat until the output matches the approved wording. The check is a set of generated PDFs stored with their source record IDs, with every defect logged and fixed in the template before the next step.
Agree approval and print handoff
Document who approves the template and the target list, who runs the generation, and how the PDF files reach the print provider, including file naming, retention and access control for files that contain personal data. Confirm the handoff format with the printer before the pilot, and agree how returned or undeliverable letters are logged. The check is a written approval record naming the approver for templates and lists, and a printer confirmation of the accepted file format.
Run a small pilot batch
Generate and print a small pilot batch from the approved list and template, then compare the printed letters with the proof copies on paper. Check addresses on a sample of envelopes, confirm that the record activity or log shows what was generated, and record any returns or print faults. Review the results with the approver before scaling. The check is a pilot review meeting where a named owner signs off the batch or lists corrections that must be fixed and retested.

Matching the mailing setup to your team's situation

A sales team sending a few letters a month usually needs a small set of templates, a clear owner for each one and a quick review before anything prints. The work centers on getting the template right the first time and keeping the audience clean, because a single wrong letter is easy to spot and costly to correct.

Template review: Keep one template per entity type or product offer, and have a named person sign off on the wording, logo, sender block and closing before the first run.
Address hygiene: Check that postal fields on accounts and contacts are filled in the same way, so that address lines, postal codes and country values print correctly on every letter.
Recipient selection: Build a target list for each mailing, then remove contacts who have opted out, left the account or are no longer the right person to write to.
Proof before print: Have a sales manager review a printed proof of the first letter generated from each new template, including records with long names and missing fields.
Light volume testing: Generate a small sample batch that includes records with multiple addresses or incomplete data, and inspect each page.

Ask the internal owner who maintains the templates after the first person leaves, and where proofs and sign-offs are stored.

Protecting personal data in printed mailings

Printed letters carry names and home addresses out of the CRM and into the post, so the controls around templates, generation, exports and stored files matter as much as the letter itself. The cards below cover who can build and run mailings, where generated documents end up, and what record you keep of each mailing.

Restrict template editing by role

PDF templates control what personal fields appear on a letter and which entity types they can pull from. Limit edit rights on templates to a small group of administrators or marketing owners, and keep sales users on read or generate rights only. Review the role matrix after each change to layouts or templates, because a template that prints extra fields can expose data the mailing never needed. Confirm the exact permission names in your EspoCRM version before you finalize the role.

Limit who can generate letters

Generating a letter from a target list can produce hundreds of documents in one action, so generation rights deserve their own decision rather than following from general record access. Decide which roles may run a mailing against which entity types and teams, and test that a user outside the list cannot generate a letter for records they can see but should not mail. Record the owner of each mailing so a later question about who produced a batch has an answer.

Control who can export PDFs

A generated PDF is a copy of personal data that can leave EspoCRM by download, email or a shared drive. Decide whether download of generated documents is open to all users who can generate them, or restricted to the print or fulfillment role. Check whether users with access to the record can also open previously generated files, since that access may be wider than the original mailing. Write the rule down so the print team and the CRM administrator apply it the same way.

Keep generated files in managed storage

Generated letters are stored as attachments in EspoCRM, and where those attachments land depends on how your hosting is set up. Confirm whether files go to local disk, an object store or another external location, and who can reach that location outside the application. Ensure backups of the file store follow the same retention and access rules as the database. Ask your hosting team to confirm this configuration in writing before the first live mailing.

Keep an audit trail of each mailing

A printed batch cannot be recalled once it is posted, so the record of what was sent to whom is your main evidence if a recipient disputes a letter. Keep a log linking each generated document to the recipient record, the template version, the user who ran the mailing and the date. Test that the log survives a template edit and a record update. Confirm which history and activity entries EspoCRM writes by default in your version and where you need to add more.

Limit admin accounts for routine mailings

Mailings should run from ordinary user accounts that hold only the rights the task needs, not from an administrator login. EspoCRM's security guidance recommends avoiding admin accounts for daily work, and the same principle applies to printing. Give mailing operators a standard role with generation rights and require two-factor authentication on every account that can see personal data. Review who holds admin rights quarterly and remove any that are no longer needed.

Running recurring mailings after go-live

The most important habit for a recurring print run is that every batch can be reconstructed later. Put letter templates under change control: each PDF template for a given entity type gets a named owner, a version number and an approval step before it is used in a live Mail campaign. Keep a record of which version produced which batch. When a customer asks why a letter says what it says, or when a regulator or internal auditor asks for evidence of what was sent, the answer should come from the record, not from memory. Record the target list snapshot alongside the template version, so you can show exactly which recipients were in scope at the time of the run, even if the list has changed since.

Before each run, refresh the target list and review it, rather than reusing last month's audience. Records move: people change addresses, accounts are closed, and consent or suppression flags change. Check the records that failed or were skipped during the previous run and decide, for each group, whether to correct the data, remove the record or accept the skip with a documented reason. Confirm how your instance reports skipped records for Mail campaigns, because the exact behavior and log locations should be checked in your own version and environment before you rely on them in a process.

Mailings that depend on queued work need a specific check. EspoCRM requires cron or a scheduled task to run background jobs, as stated in the EspoCRM server configuration docs. If the scheduler stops, generated letters may never appear, or they may appear late. Verify that the scheduled job runs after every server change, PHP update, container rebuild or upgrade, and treat a major version change as a trigger for a test batch on a non-production copy. Confirm with your own administrator which scheduler mechanism your deployment uses, who gets alerted when it fails and how long a run may take before someone investigates.

Limits to confirm before you commit to a letter workflow

Each card below is a check, not a claim. The supplied research does not establish how EspoCRM's mail merge for printed letters behaves in every version or deployment, so confirm each item against your environment and the vendor before you commit to a workflow. Ask the named owner for each item to answer it in writing.

Mail campaigns and letter generation by version

Confirm whether the Mail campaign feature in the version you plan to run generates printable letters, or whether it only produces email. The EspoCRM release line is moving quickly, so check the release notes for the exact version rather than relying on older guides. Ask the EspoCRM vendor or your platform lead to confirm this against the specific release you will deploy, and record the version in your test plan.

Entity types a template can target

Confirm which entity types a PDF template can be attached to in your version, such as accounts, contacts, leads or custom entities created in the Entity Manager. If your mailing needs to address a custom entity or a related record, test that path before design work starts. The platform architect or an EspoCRM administrator should answer this with a working example from a test instance.

Page layout and font control

Confirm how far you can control page size, margins, letterhead, header and footer placement and embedded fonts in PDF templates. Letters often need a fixed letterhead and specific fonts for brand or accessibility rules, so these limits affect design effort. Ask the marketing or communications owner to supply a sample letter, then have an EspoCRM administrator reproduce it on a test instance and compare the output.

Postal address formatting by country

Confirm whether address fields are formatted correctly for each country you mail to, including line order, postcode placement and country names in the local language. Address formatting is a common source of undeliverable mail and returned post. Ask your operations or mailroom lead to provide sample addresses for each country and check the rendered output against the postal rules those countries publish.

Print and fulfillment integration

Decide whether printing, envelope insertion, postage and dispatch stay with an external print provider or are integrated with EspoCRM. Confirm with your print supplier which file format and naming they accept, and whether they need data exports from EspoCRM. The operations owner and the print provider should agree on this handoff in writing before the template is built.

Advanced Pack need for the workflow

Confirm whether your letter workflow depends on the Advanced Pack, for example for Workflows or Business Process Management that trigger letters on a schedule or after a status change. The Advanced Pack is included in all EspoCRM Cloud plans, but self-hosted deployments must confirm licensing and installation. Ask your EspoCRM vendor or licensing contact to confirm which features require the extension in your deployment.

Questions buyers ask before hiring help with EspoCRM letters

What drives the effort and cost of setting up printed letters in EspoCRM?

The main drivers are how many letter types you need, how many entity types they pull data from, and how clean the source records are. A single letter for one entity with a fixed layout is a small job. Letters that combine accounts, contacts, leads and custom entities, need conditional text, or must match an existing branded form take longer. Address quality matters too, because fixing postal fields and merge tags in data is often the largest hidden task. Ask any provider for a written scope that lists each template, each data source, the test cases and who signs off on the output before you compare figures.

Can our team build EspoCRM letter templates without outside help?

Yes, if one or two people are comfortable editing PDF templates and understand the merge fields available on each entity type. EspoCRM lets administrators create PDF templates per entity type and generate letters from target lists through Mail campaigns, so the core mechanics are built in. Where teams usually struggle is in layout testing against a print vendor's requirements, handling formula logic for conditional text, and keeping templates consistent as they multiply. Decide early whether an internal owner will maintain templates after go-live, because that ownership is the part that tends to lapse.

How long does a first pilot of printed letters take to plan?

The planning time depends on the number of templates, the state of the data, and how many approvals sit between a draft and a live mailing. Planning usually covers the letter purpose, the target list rules, the template layout, a test print run and a sign-off step. Each of those can move at the pace of the people who own them, not only the technical work. Ask for a written timeline that names the dependencies, such as legal review or a print vendor's proof approval, instead of a single duration with no breakdown.

What does the work need from our side before it starts?

Three groups of people matter most. Data owners need to confirm which address fields are authoritative, how opt-outs and deceased or invalid addresses are recorded, and which records may appear in a mailing. Legal or compliance reviewers need to approve wording, required disclosures and any consent basis for each letter type. A print vendor or internal print team needs to provide page size, margins, paper, envelope and bleed requirements, and the file format they accept. Gathering these inputs early avoids rework in the template phase.

Does EspoCRM cloud pricing cover the work to set up letters?

Cloud subscription pricing covers the software licence and hosting for each user per month, not the design of your templates or data preparation. The EspoCRM pricing page lists per-user rates for its cloud plans, and the Advanced Pack is included in all cloud plans. Advanced Pack features such as workflows support some automation around mailings, but they do not write your letter layouts for you. Configuration work and any template build are separate costs, so ask a provider to show which items are included in a quote and which are billed by effort.

What changes when the team moves from one letter template to many?

Each additional template adds layout work, test prints, merge field checks and a sign-off step, and it multiplies the number of data combinations that can go wrong. Naming standards, a template register and a shared test dataset become necessary once more than a few templates are in use. Permissions also matter, because not every user should be able to send a given letter type. Ask whether the scope includes a maintenance process for adding or changing templates after handover, since that is usually where costs grow over time.

What should we check in a self-hosted EspoCRM before sending a large mailing?

Check that scheduled background jobs run on the server, because Mail campaigns and bulk generation depend on cron or a scheduled task. Confirm the database and PHP versions match the documented requirements for your EspoCRM release. Review who holds the permissions to create and send campaigns and whether two-factor authentication is enforced for those users. Run a small test batch with a test list before a full run, and keep a record of which template version produced which letters. Your engineers should confirm these settings in their own environment, since the server setup differs between installations.

How DeployOpen scopes and delivers printed letter workflows

DeployOpen treats printed letters as a documented workflow inside your EspoCRM instance, not a one-off export. We scope the entity types, PDF templates, target lists and campaign steps in writing, then build, test, document and hand them over for your team to run in infrastructure you control.

How we scope

Inventory which entity types, such as accounts, contacts or leads, will receive printed letters and who approves each template.
Record the data fields each letter needs and confirm which of them are maintained accurately in your CRM.
Agree the written scope, deliverables and timeline with you before any build work starts, since engagements are fixed-scope.

How we build

Create PDF templates per entity type and test merge fields against sample records in a non-production instance.
Configure target lists and Mail campaigns so printable letters are generated from the agreed audience definitions.
Test edge cases such as missing addresses, duplicate records and opt-out contacts before any production mailing runs.

How we hand over

Document each template, field mapping, target list rule and campaign step so your staff can repeat the process.
Walk your team through a complete mailing run, from audience selection to the generated letter file.
Confirm with your legal or compliance owner which address, consent and retention rules your printed mailings must follow.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Plan template and configuration reviews when EspoCRM releases new versions, so letter layouts keep working after an upgrade.
Ask us to scope any change to templates or audiences as a new written change request before work begins.