How EspoCRM signals for event-driven automation connect separate processes
Many sales and service steps depend on something that happened in a different process: a quote was approved, a contact clicked a link in a drip email, a case passed its response deadline. When each of those steps lives in its own workflow or BPMN process, the team needs a way for one process to announce what happened and for others to react without being wired into it directly. In EspoCRM, signals do that job: one process or formula broadcasts a named event, and any workflow or BPM process that listens for that signal starts or continues. Signals are a feature of the Advanced Pack's Workflows and BPMN 2.0 process engine, which the Advanced Pack page describes as providing Business Process Management and workflows, and the Advanced Pack is included in all EspoCRM Cloud plans. Self-hosted deployments need to license and install it separately, so confirm its availability and version with EspoCRM before you design around it.
Teams add signals instead of building one long process because a single process becomes hard to change and hard to test once it covers lead capture, approvals, reminders and external calls at the same time. Separate processes keep each job readable: an assignment rule can own routing, a drip campaign can own timed emails, and an approval process can own the decision, with signals passing the hand-offs between them. The same signal can also feed several listeners, so a new reaction can be added without editing the process that raised the event. The trade-off is that the flow is now spread across several definitions, so the design needs a naming convention for signals and a written map of who raises and who catches each one.
This page covers the main signal patterns: built-in and custom signals, the difference between object and regular signals, broadcasting from Formula Script and catching signals in BPM and workflows. The sibling topics show these patterns in concrete jobs such as drip campaigns, approvals, SLA escalations and link-click follow-up. Before building, confirm with your EspoCRM version which built-in signals are available, how your team will name custom ones, and which roles are allowed to edit the processes, because a signal that fires from the wrong record or under the wrong user is hard to trace after the fact.
Which signal type fits which event
This table compares the signal types you will meet in EspoCRM by where each is raised, who defines it and the automation job it suits. Read each row as a design starting point, then confirm exact signal names and scopes in the EspoCRM documentation for your installed version. The main takeaway is that built-in signals cover standard platform events, while custom signals carry business events that only your processes can name.
| Signal type | Where it is raised | Who defines it | When it fits |
|---|---|---|---|
| Built-in signal | Raised by EspoCRM core when a standard platform event occurs | EspoCRM, not your team | Starting a follow-up when a standard record event happens (illustrative) |
| Custom signal | Raised from a Formula script in a workflow or BPM step | Your administrator, named in the process design | Flagging a business event the core does not name, such as a discount needing approval (illustrative) |
| Object signal | Carries the context of one record, so the listener acts on that record | Set by the event source and the listener design | Routing the follow-up of a single lead or case to its owner team |
| Regular signal | Broadcast without a bound record, so any listener in the instance can receive it | Your team, when it names the signal in formula or BPM | Notifying several processes at once, such as pausing a campaign (illustrative) |
| Link click signal | Raised when a contact clicks a tracked link in an email template | EspoCRM, with the link set up in the template | Creating a task or updating lead status after a click; confirm the exact name for your version |
When EspoCRM signals beat direct workflow triggers
A signal decouples the event from the processes that react to it, which helps when several automations care about the same change. A direct workflow trigger is simpler to read and to debug when only one process needs the event. The decisions below help a design team choose between the two and keep the resulting chain of automation manageable.
One event, several processes
When a single record change should start a notification workflow, a BPM process and a follow-up task, a signal lets each process listen independently instead of being chained inside one trigger. The trade-off is that the event now has several consumers, so a change to the event affects all of them. Check in the Advanced Pack configuration which processes catch each signal name before you rename or retire one. Illustrative example: a quote-accepted event feeding billing, a handover task and a renewal reminder.
Keeping processes independent
A signal lets a process be built, tested and changed without knowing which other processes exist. That independence has a cost: the producing process no longer shows which downstream work it starts, so the picture of the whole automation lives outside any single flow. Decide early who maintains the inventory of signals and their listeners, and record it alongside your process models.
Debugging a chain of events
When a signal triggers a process that broadcasts another signal, a failed outcome can be several steps away from its cause. Direct triggers keep the path visible on one record, while signal chains spread it across processes and records. Plan a test sequence for each chain, and confirm in the process log which signal fired, from which record, and which listeners ran.
Cost of unclear signal ownership
Signal names are plain strings, so two teams can pick similar names for different events, or one team can change a name that another team depends on without any error. The result is automation that stops silently or fires on the wrong records. Assign an owner to each signal name, adopt a naming convention, and treat a rename as a change that needs review across all listeners.
Object signals versus regular signals
Choosing between an object signal tied to a record change and a regular signal broadcast from a formula is a decision about where the event originates and who must act on it. Object signals follow the data lifecycle and are easier to reason about for record-level automation. Regular signals suit events that do not map to one record, but they need stricter naming and documentation. Confirm which type each scenario needs before building the first listener.
Direct triggers for single-purpose work
If only one process ever reacts to a change, a direct workflow trigger keeps the design smaller and easier to hand over. Adding a signal in that case creates an indirection with no second consumer to justify it. Revisit the choice when a second process needs the same event, and document the reason for the original decision so the next designer does not have to rediscover it.
Setting up EspoCRM signals step by step
This sequence takes a team from an inventory of business events to a tested pairing of a formula broadcast and a catching process, so that one record change can start the right work in another part of the CRM. Each step ends with a check the reader can run before moving on.
Confirm the Advanced Pack is installed
Check that the Advanced Pack is installed and active on the instance before designing anything, because the Business Process Management and workflow features that catch signals come from that extension. On a self-hosted instance, an administrator confirms this under the extensions area of Administration. On EspoCRM Cloud, the pack is included in all plans, so confirm the plan tier and that the feature appears in the Entity Manager and workflow menus. The step is done when a test workflow can be created and saved by an admin user.
Inventory the events worth broadcasting
List the business events that should start work outside the record where they happen, such as a quote being accepted, a case being escalated, or a contact clicking a tracked link. For each event, name the source entity, the trigger condition, the user or team responsible for the outcome, and the process that should react. Keep the list short at first. The output is a written table agreed by the sales or service owner, and the step is done when every event has a named receiving process or is explicitly dropped.
Define signal names and scope
Choose a consistent name for each signal and decide whether it is an object signal tied to one record or a regular signal that is not bound to a record. Document the naming convention, such as a verb plus the object, and record which built-in signals, such as the link click signal, are reused instead of creating new ones. Confirm the scope with the people who will maintain the flows. The step is done when the signal register lists each name, its type, its source and its catching process, and no two signals share a name.
Add the formula broadcast on the source entity
In the Entity Manager, add a before-save or after-save formula script on the source entity that broadcasts the signal only when the business condition is met. Write the condition explicitly, keep the payload to the record identifiers and fields the receiver needs, and avoid broadcasting on every save. Test the formula logic on a copy of a record in a non-production instance first. The step is done when the formula runs on the intended change and does not fire on unrelated edits in the test records.
Build the catching BPM process or workflow
Create the receiving process in the BPM designer or as a workflow, and add a signal catch event or signal-triggered start that matches the registered name exactly. Attach the actions the business needs, such as creating a task, updating a status field or assigning an owner, and set the target record through the catch context. Use the signal catch for simple reactions and a BPM process when the flow needs gateways, user tasks or timers. The step is done when the flow saves and is published without validation errors.
Test the chain with real records
Run the source change on a few realistic test records in a staging instance, then open the process log for the receiving flow and confirm that the catch appears with the expected record and payload. Repeat with a record that should not trigger the signal to confirm that the condition holds. Check that background jobs run, because the chain depends on scheduled processing, and confirm the job queue is clearing. The step is done when both a positive and a negative case behave as designed and the log shows each catch.
Promote the signals and document operations
Move the formula scripts and processes to production in a controlled change, then run one supervised live case to confirm the catch appears in the process log. Record the signal register, the owners of each flow, and the steps for disabling a signal if it misfires. Ask your administrator to confirm how cron or the scheduled task is monitored for background jobs on your hosting setup. The step is done when the register and runbook are stored with the admin team and a supervised production case has been logged.
Catching signals in BPM or in workflows
In the BPM engine, a signal is modeled as a BPMN event. A process can be started by a signal, or it can pause at an intermediate catch event until a matching signal arrives. This suits long-running flows such as approvals, waiting periods and multi-step sequences. Process models are built in the Advanced Pack's BPM designer, so a process owner usually works with an administrator on them.
- Start and catch options: Confirm which signal start and intermediate catch events your version offers, and whether a process can start on a signal as well as wait for one mid-flow.
- Broadcasting with formula: Formula Script can run in BPM steps, so a script step can send a named signal, optionally carrying record context. Check the exact function and its arguments in the EspoCRM formula documentation.
- Broadcast reach: A signal is received by every waiting process that listens for that name, so one broadcast can resume several instances at once. Design names and conditions so only the intended instances match.
- Model changes: Confirm how running instances behave when a model is edited, since instances already in progress may keep the old version of the flow.
- Audit trail: Use the process log to confirm which signals were sent, received and ignored.
Before release, test that a waiting process resumes only for the intended record, that a signal sent with no listener is handled as designed, and that the process log shows each step.
Workflows are the rule-based automations in the Advanced Pack. They react to record events and scheduled triggers, and administrators configure them through the admin interface without modeling a process diagram. For simple reactions, such as assigning a record or updating a status when a condition is met, workflows are often the lighter option. Their catch options differ from BPM, so confirm in your version whether a workflow can react to a signal directly or only through a related trigger.
- Trigger types: Confirm which trigger types exist in your version, and whether a signal can serve as a trigger for a workflow that runs on a record.
- Formula in actions: Formula Script is available in workflow conditions and actions. Use it to build the data a broadcast carries, and confirm whether a formula action can send a signal.
- Scheduled triggers: Scheduled workflows depend on cron or the scheduled task on the server. A signal arriving on a schedule is only as timely as those background jobs.
- Ownership: Workflows are usually maintained by CRM administrators. They are quick to change, which also means many small rules can overlap or conflict without a shared naming standard.
- Permissions: Confirm which user context a workflow runs under, since it determines what the actions can read and change.
Test each workflow with the signal present and absent, confirm that duplicate signals do not repeat an action, and check the workflow log after a sample record has been processed.
Most signal designs use both engines, with BPM handling long waits and workflows handling short reactions. The two are maintained by different people, so the testing and handover plan should cover both at once. A shared register of signal names, owners and listeners prevents the most common failure, which is a signal that resumes a process nobody expected.
- Signal register: Keep one list of every signal name, the record type it carries, who sends it and which BPM processes and workflows listen for it.
- Negative tests: Send signals with no listener, send duplicates, and send signals for records that no longer match the condition.
- Ownership handover: Assign a named owner for BPM models and for workflow rules, and agree who approves a change that affects a shared signal.
- Upgrades: Retest signal paths after each EspoCRM upgrade, because event and formula behavior can change between versions. Confirm the upgrade notes for your target version first.
- Operations: Monitor background jobs, since both scheduled triggers and some signal handling rely on them, and review logs after each release.
Before go-live, run a full path test with real permissions for each role, and confirm that the signal register matches the configuration in the installed version.
How much do EspoCRM signal automations cost to build?
What drives the cost of an EspoCRM signal automation project?
The main cost drivers are the number of signals, the number of processes or workflows that catch each signal, and the amount of testing and documentation the client needs. Each signal has to be designed, broadcast from a formula or hook at the right point in the record lifecycle, and caught by one or more BPM processes or workflows. A single signal caught by one process is a small job. Ten signals, each caught by three processes with different branches, multiplies the design, build and test effort. Cost also rises with the number of object signals that must be checked against related records, with the number of user roles that see different outcomes, and with the number of integrations the process calls at the end. Ask the provider to list each signal, its trigger, each catching process, and each external system touched, because that list is the basis of any fixed-scope quote.
How long does a scoped EspoCRM signal build usually take?
Duration depends on the same drivers as cost: how many signals exist, how many catching processes depend on them, how many decisions the processes contain, and how much test data and review the client requires. A small set of signals with one or two catching processes is usually a short, contained piece of work. A larger set that touches sales, service and reporting, or that needs careful handling of duplicate or repeated events, takes longer because each path has to be tested. Timelines should come from the written scope rather than a general rule. Ask the provider to split the schedule into design, build, test and handover phases, and to state which client reviews fall inside each phase. Confirm how many review rounds are included before work starts.
What do we need from our admins and process owners during the build?
The build needs named people who can make decisions quickly. An EspoCRM administrator must provide access to a non-production instance, confirm entity and field names, and review the Entity Manager changes that define custom fields the signals depend on. Process owners must describe the business rule behind each branch, such as which outcome counts as a qualified lead or which approver handles an exception. They also need to accept test results. Without these inputs, the most common delay is waiting for a decision about a branch that nobody defined. Agree on a decision log at the start, and name a single approver for scope changes so that new signals do not appear in the middle of testing.
Can an internal EspoCRM admin build a simple signal without a partner?
Yes, a capable admin can build a simple signal that is triggered by a single, well-understood event and caught by one short workflow. The admin needs access to the Advanced Pack's Workflows and BPM features, a clear understanding of Formula Script, and a test instance. Difficulty rises when the signal must fire from a formula at the correct point in the record lifecycle, when several processes catch the same signal, when processes wait on timer or message events, or when the flow calls an external system. Those cases also need careful testing for duplicate triggers and for records that change while a process is waiting. Internal teams should decide early which signals they can own and which need outside review, and they should document each one so another admin can maintain it.
How does an EspoCRM upgrade change signal designs?
An upgrade can change how processes and formulas behave, so signal designs should be reviewed as part of the upgrade plan. Major versions such as 10.0.0, released on July 2, 2026, are a point where teams should retest every signal, catching process and formula in a staging copy before production. The upgrade plan should inventory signals, list the custom entities and fields they use, and record which extensions provide the Advanced Pack features. Confirm which PHP and database versions the target release requires, because the server configuration docs list supported combinations that change across releases. The EspoCRM security docs also note that upgrading through the UI is disabled by default as of version 10.0, so the upgrade procedure must be scheduled as a controlled operation.
What should a fixed-scope quote for signal automation list?
A useful quote lists each deliverable by name. It should include a register of signals with their trigger point, the catching processes or workflows, each branch and its expected outcome, and every external call. It should state the test approach, including test cases per process, the test environment, and who signs off results. It should name the documentation delivered, such as a signal map and runbook for admins. It should list what is excluded, such as data cleanup, changes to other extensions, or support after handover, and it should say whether ongoing support is a separate retainer. Ask for the assumptions the price depends on, the client inputs required and their due dates, and the change request process for signals added after sign-off. Any quote that cannot name its signals is not yet a scope.
Which costs recur after an EspoCRM signal build is delivered?
Most of the cost is one-time build effort, but several costs recur. The EspoCRM Cloud plans, for example, are priced per user per month: the pricing page lists 15 US dollars per user per month on Basic with a minimum of 3 users, 25 dollars on Enterprise with a minimum of 5 users, and 69 dollars on Ultimate with a minimum of 10 users, with the Advanced Pack included in all cloud plans. Self-hosted instances carry infrastructure, backup and staff time instead. Recurring work also includes reviewing signals after each upgrade, adjusting processes when business rules change, and monitoring for failed external calls. Ask the provider whether post-handover support is included, what response expectations apply, and how changes are priced.
Security and operational risks of event-driven flows
Signals let one process trigger another without a direct link between them, which makes the chain harder to see and to govern. The cards below cover the risks that matter most when signals broadcast from formulas and are caught by BPM or workflows, and the control or check that addresses each one.
Who can edit broadcasting formulas
A signal is usually broadcast from a Formula Script in a before-save script, workflow or BPM action. Anyone who can edit that formula can start or stop downstream processes without touching the process itself. Review who holds administrator access to the Entity Manager and to workflow and BPM definitions, and keep a change record for every formula that calls a signal. Confirm in your own instance which roles can edit these scripts before you enable production catching.
Record access for catching processes
A process that catches a signal runs with its own access context, and it can only read or change records that the context allows. Test each catching flow with a non-admin user who has the same role as the people whose records it touches, and confirm that the flow cannot reach teams or records outside its intended scope. Treat any flow that bypasses team or ownership checks as a finding to fix before go-live.
Auditing signal-driven steps
When one process starts another through a signal, the chain of cause and effect can be difficult to reconstruct later. Use the process log to record each BPM step, and confirm that the log shows which signal was caught and which record it referenced. Decide how long you keep these logs and who may read them, since they can contain customer identifiers.
Timing under cron and scheduled tasks
Background jobs in EspoCRM run only when cron or a scheduled task invokes them, so a caught signal may be handled later than the moment it was broadcast. Measure the delay on your own server before you rely on it for time-sensitive steps such as approvals or customer replies. Document the cron interval as part of the design, and alert if the scheduler stops running.
Loops between signals
A signal caught by a process can broadcast another signal, which can trigger the first process again and create an endless cycle. Map every broadcast and catch pair before deployment, and add guards such as a condition on a status field or a counter stored on the record. Test the flow with records that meet the trigger condition repeatedly to confirm the chain stops.
Personal data in signal payloads
Signal payloads and the variables that accompany them can carry names, email addresses or other personal data into logs and downstream systems. Limit payloads to record identifiers where possible, and have the catching process read the fields it needs under the same access rules. Review what external calls send after a signal, and confirm the data handling matches your privacy obligations.
Limits to confirm in your environment before you design signals
Before you design any signal-based process, confirm three things for your deployment: the EspoCRM version, the Advanced Pack release, and the exact signal behavior those two combined provide. Signal behavior is not uniform across releases. The scopes a signal can use, whether one signal can trigger another (chained signals), and how quickly a waiting catch event fires can all depend on the version and extension build you run. EspoCRM 10.0.0 was released on July 2, 2026 and 10.0.10 on October 14, 2026, so a design written against one minor release may need re-checking after an upgrade. Ask the vendor for the signal reference that matches your exact versions, then confirm each point on a test instance before it reaches the design document.
Licensing decides whether BPM and workflows exist in your environment at all. The Advanced Pack provides Business Process Management and workflows, and the EspoCRM pricing page states that it is included in all EspoCRM Cloud plans. The open-source edition can be self-hosted for free, but it does not include the Advanced Pack, so a self-hosted team that plans to catch signals in a BPM flow must license and install that add-on separately. Confirm the current license terms and the plan tier that includes the Advanced Pack with EspoCRM directly, and record which edition each environment (development, test and production) runs. A design that works on a cloud trial can fail on a self-hosted instance without the add-on.
Test each signal path on an instance that matches production, not on a convenience sandbox. Check the scope of each signal you rely on, whether a signal raised by one process starts another, the delay between broadcast and catch, and what happens when no catch is waiting. Record the results with the EspoCRM and Advanced Pack versions beside them, and repeat the tests after every upgrade. The cost of this check is mostly internal test time and one test environment kept at the same version as production, both of which recur with each release cycle.
How DeployOpen scopes and delivers EspoCRM signal automation
DeployOpen plans, builds, tests, documents and supports self-hosted open-source platforms inside your own infrastructure. For EspoCRM signals, we start by mapping which record events should trigger which processes, then deliver the signal and listener design in writing before any build begins.
How we scope
- We list every business event that should trigger a process, such as a status change or a link click.
- We agree which signals are built-in, which are custom, and which object or regular signal type each one uses.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We broadcast signals from Formula scripts and catch them in BPM processes or workflows, per the approved design.
- We test each signal path with sample records, including duplicate events, failed listeners and permission edge cases.
- We check that Advanced Pack licensing and PHP and database versions match the target environment before building.
How we hand over
- We document each signal, its payload, its listeners and the owner responsible for changing it.
- We walk your administrators through the process log and explain how to trace a missed or repeated event.
- We provide a runbook covering cron dependencies, rollback steps and how to add a new signal safely.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We can review signal and process changes when you upgrade EspoCRM or add new official extensions.
- Ask any partner to confirm how they will test signals after an EspoCRM version upgrade in your environment.
