Automating email link click follow-up in EspoCRM for sales teams
Sales and marketing teams that send templated emails often want a specific action when a contact clicks a specific link: a follow-up task for the account owner, or a lead status change that moves the record into the next stage. In EspoCRM, this is built from three parts: a tracked link in the email template, a signal raised when the link is clicked, and a process that listens for that signal and acts on the record. The EspoCRM documentation describes click tracking for links in email templates and a signal that workflows and BPM processes can catch. Before you design around it, confirm the exact behavior in the EspoCRM version you run, because link tracking options, the name and payload of the click signal, and the data fields available to a process can change between releases. Do not rely on a version-specific detail until you have tested it on your own instance.
Teams usually need this when the click is a stronger intent signal than an open. Examples include a pricing page link in a campaign, a request-a-demo link in a renewal notice, or a document download link sent after a call. A single click can then create a task for the owner with a deadline, or move a lead from a nurture status to a qualification status. Treat this as a decision about which clicks count. Decide which templates carry tracked links, which link is the trigger, which user or team owns the resulting task, and what happens when the same contact clicks several times. Also decide how a click from a forwarded email or a security scanner is handled, since a scanner can register clicks a human never made.
The Advanced Pack is the official add-on that provides the Workflows and Business Process Management engine used for this logic. It is included in all EspoCRM Cloud plans, and self-hosted installations need it added to the instance. Build and test the process on a staging copy first. Verify that the click signal reaches the process for a real test contact, that the created task is assigned to the intended user, and that a repeat click does not generate duplicate tasks or status changes. Ask your implementation partner to document the template, the signal, the process and the test results, so that your team can maintain the flow when templates or versions change.
Which click trigger and action fit each follow-up job
This table compares a workflow that reacts to the clickUrl signal with a BPM process that waits on a catch event, across the follow-up jobs most teams start with. Read each row against the job you need, then use the requirement rows to confirm what your instance must have before you build. The main takeaway is that a single task, status change or notification usually fits a workflow, while waits, several clicks over time and approvals usually need a process.
| Follow-up job | Workflow reacting to the click signal | BPM process with a catch event |
|---|---|---|
| Create one follow-up task | Fits one click with a clear condition and no waiting. Creates the task on the clicked record. | Fits when the task should wait for a timer or a later step, such as a second click or a set delay. |
| Update lead status | Fits a status change driven by one click and a simple condition, such as the link identifying the campaign. | Fits when status depends on several clicks or other events over days, because the process instance keeps that state. |
| Notify the record owner | Fits a single notification to the assigned user when one click happens. | Fits when the notification is one part of an escalation or approval path that uses user tasks. |
| Handle repeated clicks | Confirm how each click starts a separate run and whether duplicate runs can cause duplicate tasks. | Confirm how the process instance is matched to the lead so repeated clicks update the same instance. |
| Advanced Pack requirement | Required. Workflows are part of the Advanced Pack, which is included in all EspoCRM Cloud plans. | Required. BPM is part of the Advanced Pack, which is included in all EspoCRM Cloud plans. |
| Formula Script use | Used for conditions and field updates when a field check is not enough. Test each expression on a sample record. | Used in process scripts for the same logic. Confirm which click data the script can read in your version. |
| Signal configuration | Confirm the clickUrl signal name, its scope and that the workflow is set to catch it in your version. | Confirm the catch event uses the same signal name and scope, because a mismatch stops the process without an error. |
| Testing and audit | Check the workflow log after a test click for each condition and action. | Check the process log and instance history for each click, including any waiting steps. |
How a link click becomes a signal that BPM can catch
The chain has four links. A template carries a tracked link, a contact clicks it, EspoCRM records the click and broadcasts a signal, and a workflow or BPM flow catches that signal and runs its actions. The last two links carry the automation logic, so most of the design work sits in the first two. Before building anything, confirm in your target version which entity or log holds the click record, the exact clickUrl signal name, and the payload fields the catching flow will read. Signal names and payload fields can change between versions, so treat what you find in your own instance as the reference, not a general assumption.
Formula Script is where the decisions run. According to the EspoCRM formula documentation, it is used in before-save scripts configured in the Entity Manager, API before-save scripts, workflows and BPM. In this chain, the formula steps in the catching flow read the signal payload, look up the related contact or target, and then set a lead status or create a task. A contact may click the same link more than once, so write the formulas so that a repeated signal does not create duplicate tasks or move a lead backward. Test that case explicitly with a second click on the same link.
Signals are handled through background processing, and that depends on cron or the scheduled task described in the EspoCRM server configuration docs. If the scheduler is not running on your instance, clicks may still be recorded while the flow never fires, so reactions arrive late or not at all. Ask your administrator to confirm the scheduler runs on the target server, then send a test click and measure how long it takes for the task or status change to appear. Record that delay as a baseline before you promise anyone a same-minute follow-up.
Setting up click-triggered follow-up step by step
This sequence takes a tracked link from an email template to a working automation that reads the click, updates the lead and creates a follow-up task. Each step ends with a check in the live instance so the team knows the chain works before real contacts are involved.
Confirm the Advanced Pack and background jobs
Check that the Advanced Pack is installed or included in your plan, since Business Process Management and workflows come from it. Confirm that the cron job or scheduled task required for background jobs is running on the server, because BPM processes and some workflow actions depend on it. Confirm the PHP, database and web server versions against the EspoCRM server configuration documentation for your release. Done when a test workflow or BPM process you create in the administration area saves and runs without errors, and the scheduled job log shows recent executions.
Create the tracked link in the email template
In the email template, add the link you want to track and mark it so EspoCRM records clicks on it. Use a clearly named link for each campaign or intent, such as a pricing page or a booking page, so later logic can tell the clicks apart. Send the template to an internal test address you control. Done when the test email arrives with the link in place and clicking it produces a click record linked to the recipient in EspoCRM.
Define the target entity and lead status values
In the Entity Manager, confirm the entity that will receive the follow-up task and the lead status field, and list the status values the automation may set. Decide whether a click moves a lead from one status to another or only adds a note, and document that rule before building anything. Check that the users who will receive tasks have the required permissions on the target entity. Done when the status options and the task assignee field appear on a test record and a user with the target role can view and edit them.
Build the workflow or BPM catch
Decide whether a simple workflow is enough or whether a BPM process is needed, for example when the follow-up must wait or branch. For a BPM flow, use a signal or message catch that listens for the click event and starts the process from the matching contact. For a workflow, set the trigger to the click record and choose the actions to run. Save the definition and activate it only after the test checks pass. Done when the workflow or process appears as active and the process log shows it is waiting for the event.
Write the Formula Script conditions
Write Formula Script conditions that check the link identifier, the contact or lead type and the current status before any change is made. Use the conditions to skip contacts who are already converted, closed or opted out, so the automation does not create duplicate tasks. Keep the script short and comment each branch so reviewers can follow it. Done when a formula test with a sample click returns the expected branch for each case you defined, including the case where no action should happen.
Test with a controlled contact
Create a test contact and lead that belong to your team only, and send the tracked email to that address. Click the link once, then click it again to confirm the duplicate-handling rule works. Check the click record, the signal or event reception in the process log, the lead status and the created task. Review the activity stream and the task assignee. Done when each expected record exists exactly once and no unexpected changes appear on other records.
Confirm behavior before live use
Repeat the test with a second link and a second contact to confirm the branches behave independently. Ask a team member who will receive the tasks to confirm the task text, due field and notification are what they expect. Record the activation date and the rule owner in your internal change log. Done when the test results are signed off by the business owner and the activated automation is documented with its link identifiers, status values and conditions.
Choosing a workflow or a BPM flow for click follow-up
A workflow fits when one click should produce one result, such as creating a follow-up task or moving a lead to a new status. The Advanced Pack provides workflows that can react to a signal, so one rule can listen for the click and act on the same record without a separate process instance. This is usually the lightest option to maintain, and it is a sensible starting point for most teams.
- Few moving parts: One trigger, one condition and one or two actions are easy to read during review and handover.
- Limited visibility: A workflow shows the outcome on the record, not a path through several stages, so staff see what changed but not the sequence that led there.
- Quick to test: Use one contact, one template and one click, then check the task or status field.
- Hard to extend: Adding a wait or a second decision usually means rebuilding the logic as a process, so settle the scope before you build.
Check whether a click should always produce the same result, and whether anyone will need to explain the contact's path later.
A BPMN 2.0 process fits when a click starts a journey with timers, approvals, branches or several owners. Each running instance keeps its own state, so cases such as a second click, or a click that arrives after a manager has changed the lead status, can be handled explicitly in the model rather than patched afterward.
- Visible state: Each instance records where it sits in the flow, which helps support staff explain why a contact received a task.
- Waits and branches: Timer events and gateways can handle paths such as no click within a set period. Confirm the timer and signal options available in your version's Advanced Pack documentation before you design around them.
- Higher maintenance: Diagrams, formulas and user tasks each need an owner, and changes to the model need a change plan so that instances already running are handled deliberately.
- Longer testing: Test every branch, every timer path and every user task, including the case where a click arrives after the process has ended.
Before the first live send, confirm how your version treats instances that are already running when the model changes.
When one email carries several tracked links, or a campaign sends to a large audience with different links per segment, the design question shifts from individual rules to the link inventory. Each tracked URL needs a defined meaning and a defined reaction, and both should be settled before the send. The automation is only as clear as the link list behind it.
- Link taxonomy: Name each tracked link by intent, such as pricing, demo request or unsubscribe, and keep the mapping in a table that marketing and CRM owners both maintain.
- Repeat clicks: Decide whether a second click on the same link creates a second task, and whether a click after an opt-out is ignored.
- Instance volume: One process per contact multiplies running instances. Ask the vendor or your implementation partner how to measure this in a staging environment using a representative sample of contacts, and confirm the sizing of your hosting plan.
- Template ownership: Campaign owners edit templates, and a changed or removed URL can break a rule without any error on the record, so changes need a review step.
Confirm that every link in a template has a documented owner and expected reaction before the campaign goes live.
Protecting contact data and tracking links
Click tracking turns link activity into personal data, and the automation that reacts to it runs with real permissions. The cards below cover who gets access, how the automation is watched, and how changes and retention are governed so the flow stays accountable after launch.
Dedicated API user for automation
Any workflow or external call that reads or writes EspoCRM records should run under its own API user, not a person's login. Give that user only the entity permissions the flow needs, such as reading Contacts and writing Tasks and Leads. The EspoCRM API docs describe API key, HMAC and basic authentication, and HMAC is the method they rate as most secure. Confirm which method your integration supports before you choose one, and do not use basic authentication for production traffic.
No admin accounts for daily work
Admins who build and edit the click-follow-up flow should keep a separate, non-admin account for everyday selling and service. The EspoCRM security docs recommend avoiding admin accounts for daily work and disabling password recovery for admins. Also require two-factor authentication for anyone who can edit templates or workflows, noting that EspoCRM's own 2FA is not compatible with OIDC sign-in.
IP restrictions for admin and API access
Where your network allows, restrict admin and API access by IP address so that builder accounts and the API user can only connect from approved office or VPN ranges. Confirm with your security team which ranges apply to sales staff, service staff and any external system that calls EspoCRM. Test the allowlist against the workflow's external call path before it goes live, because a blocked call fails silently for the sales user.
Control who edits templates and workflows
Tracking URLs live in email templates, and the workflow decides what a click does, so both are sensitive. Limit edit rights on email templates, workflows and BPM process definitions to a named group of administrators or process owners. Review that list at least once a quarter and after any staff change, since a single editor could change which contacts get tasks or which leads change status.
Monitor the workflow log and keep cron running
Click-triggered automation depends on background jobs. EspoCRM requires cron or a scheduled task for background jobs, so confirm the job runs on every server that hosts the instance and alert when it stops. Review the workflow and BPM logs on a set schedule to spot failed runs, duplicate tasks or contacts that were processed twice, and record who owns that review.
Change control for formula scripts
Click logic often sits in Formula Script inside workflows or BPM, and a small edit can change who receives follow-up work. Store the approved formula text, require a second reviewer, and test changes against a sample of contacts in a non-production instance. Keep a dated record of each change so you can explain behavior to an auditor or to a contact who asks why they were contacted.
Purpose and retention for click data
Treat each recorded click as personal data linked to a named contact. Write down why you record it, such as follow-up on a specific campaign, and set a retention period for raw click events and any task notes derived from them. Ask your privacy or legal team to confirm the purpose and period before launch, then configure deletion or anonymization so stale click history does not stay on contact records.
How much effort and time does click-based follow-up take to build?
What drives the effort of building click-based follow-up in EspoCRM?
The effort rises with the number of tracked links, the number of decision branches after each click, and how clean the lead data is. Each tracked link needs a defined outcome, such as creating a task, changing lead status or notifying an owner. Each branch adds a gateway, a path to test and a rule for what happens when two clicks arrive out of order. Data quality matters because a click that cannot be matched to a clean lead record fails silently or creates duplicates. Consent rules also add work, since follow-up after a click must respect opt-out and marketing preferences already recorded in the CRM. Testing across every email template and mail client is often the largest single item, so ask any partner to list the templates in scope and how each will be verified.
Does click-based follow-up require the Advanced Pack?
Yes. The click-based flow runs in the Business Process Management and workflow features that the EspoCRM Advanced Pack provides. According to the EspoCRM Advanced Pack page, the Advanced Pack is included in all EspoCRM Cloud plans. If you self-host, you need to confirm how you will license the Advanced Pack for your instance and whether it is available to you under your chosen setup. The open-source edition of EspoCRM is free to download and self-host, so the core platform does not carry a license fee, but the add-on decision belongs in your cost model from the start.
What does the cost of EspoCRM Cloud look like before implementation?
According to the EspoCRM pricing page, EspoCRM Cloud costs 15 US dollars per user per month on the Basic plan (minimum 3 users), 25 dollars per user per month on Enterprise (minimum 5 users) and 69 dollars per user per month on Ultimate (minimum 10 users). The Advanced Pack is included in all cloud plans. These are recurring subscription costs that scale with the number of users, so the number of sales and service seats affects total cost more than the number of automation flows. Implementation work is a separate, one-time cost and is not covered by these subscription prices.
What does our team need to provide for this project?
Four inputs shape the build and the schedule. First, a named sales operations owner who decides which clicks matter and approves lead status changes. Second, administrator access to the test environment, including the Entity Manager, workflows and the process designer. Third, sample email templates with every tracked link marked, so the build covers real content rather than assumptions. Fourth, written lead status definitions, including which status a click should move a lead to and which statuses must never be overwritten by an automated click. Clicks from security scanners and mail preview panes can look like human engagement, so also confirm how your team wants those treated.
Can an in-house administrator build a simple click-based flow?
An administrator who already knows EspoCRM can build a simple version with one tracked link, one outcome such as creating a task, and a short test plan. The Advanced Pack documentation and the formula reference cover the building blocks. The effort grows once you add several links, branches, lead status changes that must respect existing data, consent checks and tests across multiple templates. Teams often keep ownership of the simple flows and bring in a partner for the branching logic, the test matrix and the handover documentation. Confirm that your administrator has time for testing, because most delays come from validation rather than configuration.
How is the cost of a click-based follow-up project set?
DeployOpen does not publish a price list. Most engagements are fixed-scope, so the cost follows from a written scope that lists the tracked links, the branches and outcomes, the templates to be tested, the integrations involved, the data cleanup needed and the handover materials. Ask any partner for a quote that separates design, build, testing, documentation and knowledge transfer, and states what is one-time and what is a retainer for ongoing support. Ask whether changes to templates after go-live are covered by the scope or billed separately.
What should we confirm about tracking before we start?
Confirm three points with your team and with the vendor documentation before committing to a design. First, which click events EspoCRM exposes to the process engine in your version, since the signal behavior should be checked against the current docs rather than assumed. Second, how your mail setup handles link tracking and whether any mail gateway rewrites links before recipients see them. Third, how your privacy notices describe click tracking to recipients. Your legal or privacy team should sign off on that wording, because DeployOpen prepares controls and evidence but does not provide legal advice or certification.
Which parts of the work recur after go-live?
Several parts recur. New email templates need tracked links and tests. Changes to lead statuses or sales processes may require updates to the flow. EspoCRM upgrades can change how workflows and BPM behave, so regression tests should be repeated before each upgrade. Mail deliverability and link tracking settings can also change when your email provider changes. Plan for an owner who reviews click-triggered activity each month, checks for unexpected task volumes and confirms the flow still matches your lead status definitions. These tasks can be kept in-house or covered by a support retainer.
What to confirm about click signals before you design the flow
Click-driven follow-up depends on how the installed EspoCRM version tracks clicks, what the signal carries, and how the surrounding mail setup behaves. Each card below is a question to put to the vendor or to test in your own environment before the BPM flow is designed.
Exact tracking behavior in your version
Confirm how the installed version rewrites links in templates, which URL form it generates, and whether the tracking applies to every link type or only to certain templates. Ask the vendor to show the generated link for a test email. Do not assume the behavior described in one release still holds after an upgrade, because the release notes and docs for your exact build decide what the flow can rely on.
Signal payload contents
Ask which fields the clickUrl signal carries, such as the target entity, the contact, the clicked URL and a timestamp, and whether the payload is available inside the BPM flow without extra lookups. Test with one real click on a sandbox record and log what the process receives. The flow design should only use fields you have confirmed in that test.
Bot and prefetch clicks
Mail security gateways and link scanners often request URLs before a person opens the message. Ask whether a scanner request can register as a click, and test it by sending a message through your mail filter and reviewing what is recorded. If scanner hits count as clicks, a follow-up task could be created before any human has read the email.
Repeated clicks
Ask whether each click raises a new signal, whether repeat clicks from the same contact are deduplicated, and how the flow behaves if the same process receives several events. Decide in advance whether a second click should create another task, update a status that is already set, or be ignored. Verify the choice with a short test using the same link several times.
Multi-link templates
Confirm how the signal identifies which link was clicked when one template contains several tracked URLs, and whether the payload separates them clearly. If the answer is unclear, you may need a different template per call to action. Test a template with at least two links before you map different clicks to different follow-up tasks.
Mailbox and deliverability dependencies
Click signals only arrive when the email is delivered, rendered and the recipient interacts with it. Confirm how bounces, spam filtering and image blocking affect the data you rely on, and which mailbox and sending setup your instance uses. Also confirm the cron or background job schedule that processes events, since delayed jobs will delay follow-up.
Workflow and process volume limits
Ask whether the Advanced Pack imposes limits on how many workflow or BPM executions can run per time window, and how a large campaign with many clicks is queued. Test a burst of events in a non-production instance and watch for backlog or failed jobs. Plan the volume you expect against the limits you confirm, not the other way around.
How DeployOpen scopes and delivers click-based follow-up
DeployOpen plans, builds, documents and hands over click-based follow-up in EspoCRM inside infrastructure you control. We start from the link clicks your teams need to act on, then agree the tracking, the BPM flow and the lead or task outcomes in writing before any build begins.
How we scope
- Inventory the email templates and campaigns where tracked links will appear, and which links matter
- Define the click outcomes in writing: task type, owner, due rule and lead status changes
- Confirm your EspoCRM edition, Advanced Pack availability and the BPM process model to be used
- Agree a fixed scope, deliverables and timeline in writing before work starts
How we build
- Configure tracking URLs in templates and check how each click reaches the clickUrl signal
- Build the BPM flow that catches the signal, applies Formula Script logic and creates tasks
- Test with clicks from known test contacts, including repeat clicks and clicks on unmapped links
- Review permissions so the automation runs under a service user with only the rights it needs
How we hand over
- Document each process, its triggers, variables, formulas and the records it changes
- Provide a test script and results so your team can repeat checks after changes
- Walk through the flow with the sales and service owners who will act on the tasks
- Record the configuration steps needed to move the flow between your test and production instances
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer
- Review the flow after each EspoCRM upgrade, since BPM and signal behavior should be retested
- Adjust links, outcomes and task rules as campaigns and sales processes change
- Confirm with your own team how long click and process logs are kept and who can read them

