Create and customize email templates in Pipefy

Acknowledging every purchase request can mean rewriting the same message, checking the requester's name, and updating the request details. When this work repeats, keeping messages consistent depends on checking each email before it goes out.

By the end of this article, you will know how to choose a message to turn into a template, separate shared wording from individual request details, and plan a useful test. You can then build a message that explains what happened and makes the next step clear.

In Pipefy, a pipe organizes a process and each card represents a request. An email template is a reusable message that combines fixed text with dynamic fields populated with process information. The shared inbox and card emails provide places to exchange messages; the template provides the content foundation.

What you will learn:

Choose a recurring process communication

Start with a message that serves a similar purpose and next step across several requests. Acknowledgments, requests for information, and completion notices can share a common foundation when they accurately describe what happened in each case.

Imagine a purchasing team that needs to acknowledge incoming requests. Its template can explain that the request will be reviewed and ask the requester to wait for an update. Purchase approval will be communicated later, once that decision has been made.

An unusual case may still benefit from shared wording while requiring a review before sending. For example, a support response might depend on a specific assessment. Choose a template based on how much the message needs to change to remain accurate.

The same principle appears in this Community example of candidate communications during recruitment, in Portuguese: acknowledgments, invitations, and feedback address different moments in the process.

Separate shared wording from request details

First, write what applies to every case: the reason for contacting the person, the explanation they need, and the closing instruction. Then identify the details that help each recipient recognize their own request.

For the purchasing example, the requester's name and a reference to the purchase can personalize the email if those details are available in the process. Include only relevant information that will already exist when the message is sent.

An illustrative message might read:

In this fictional example, the name and request description are variable details. The explanation about the review stays the same. Connect the values to fields that exist in your process; typing a label in square brackets does not replace selecting a dynamic field.

Personalization also means recognizing what you can already communicate. Include an expected response date only when the timing is defined and applies to that request. If timing still depends on a review, keep the wording appropriate to the current stage.

You can work on presentation in the visual editor. If your message includes dates, amounts, or times, check its language and time zone settings: language affects date, currency, and number formats, while the time zone affects time information. Write the message in the intended language.

Decide who receives the message and when it is ready

Choose recipients according to the purpose of the message. The requester may need an acknowledgment, while the person reviewing the purchase may need different internal instructions. Copy other people when there is a concrete reason for them to follow the communication.

Before deciding when to send it, ask: will the details used in the message already be available? Does the wording describe a confirmed situation? Does someone need to review the case?

• Manual sending: useful when the content needs an assessment or adjustment before it reaches the recipient.
• Sending through an automation: suitable when there is a defined event and the available information is enough to send the message, such as card creation or entry into a phase.

Creating the template prepares the message. Sending it in response to an event requires a separate automation. For the purchase request, agreeing on that moment with the team helps acknowledge receipt without suggesting that approval has already been granted.

Test the message your recipient receives

Before using the template routinely, run a controlled send with fictional data and a test address your team controls. Use an appropriate environment and avoid triggering messages to real requesters.

Check the received email as well as its appearance in the editor:

• Is it addressed to the intended recipient, with appropriate copies?
• Does the subject explain the reason for contacting them?
• Do variable details match the request used in the test?
• Are dates, amounts, and times clear?
• Do links open the expected destination for that audience?
• Can the recipient understand what happened and what to do next?

Try one case with complete information and another without an optional detail. Observe the result and adjust the wording, data collection, or timing if the message no longer makes sense. Avoid relying on information that may not exist at that stage.

Keep templates aligned with the process

Decide who reviews messages when deadlines, teams, required information, or next steps change. Record what each template is for and when it is used, including any sends through automations.

When organizing names, make the phase, purpose, and internal or external recipient recognizable. This helps another person find the right template without opening every message to understand its use.

Update the existing foundation when the purpose stays the same but the shared wording needs to change. Consider a separate version when the audience, purpose, or closing instruction differs. Check where a template is used before changing its content.

To apply this now, choose one recurring message and write down the situation it communicates, the data it needs, its recipient, and how you will test it. This plan guides both creating and reviewing a template.

Before moving on, confirm that you understand:

☐ The purpose of the message and the next step are clear.

☐ Variable information exists at the chosen sending moment.

☐ The recipient and any need for review have been defined.

☐ Testing covered the received message and its links.