How EspoCRM scheduled workflows for renewals work
Scheduled workflows with the Advanced Pack run on a timer, select the records that match a list report, and act on each record that comes back. A renewal notice, a follow-up task or a stale-opportunity alert then happens without someone opening a list and checking dates by hand. The workflow itself is built in the Advanced Pack's Workflows module, and the report it reads is a list report, so the same filter logic your sales or customer success team already uses on screen decides who gets notified. Teams need this pattern when the trigger is the passing of time rather than an edit: a license reaches 30 days before expiry, an opportunity has sat in one stage for two weeks, or a customer has had no activity since the last review. A record-level trigger only fires when someone changes a field, so it cannot catch a record that nobody touched.
Use a scheduled workflow when the condition is a date window or an inactivity period across many records, and keep a record-level trigger for reactions to a single change, such as a status moving to Won. Before you build, confirm two things in your own environment. First, the scheduled jobs depend on cron or a scheduled task on the server, as the EspoCRM server configuration documentation requires for background jobs, so an unscheduled host means no reminder runs at all. Second, confirm who owns the list report and whether its filters use fields that are kept current, because a workflow acts on whatever the report returns on that run. Ask the implementation partner to document both checks in the acceptance test.
Which scheduled trigger and action fits each reminder
This table compares the scheduled trigger, list report filter and action options for common renewal, follow-up and stale-opportunity jobs. Read each row as a decision: match the reminder's urgency and volume to a frequency and filter width, then pick the action the recipient will actually act on. The main takeaway is that narrow filters and daily runs suit time-critical notices, while broader weekly digests suit review work.
| Reminder | Frequency and filter | Action to use | Watch for |
|---|---|---|---|
| License expiry notice | Daily run over a report of licenses expiring within a set window, filtered on status and renewal date | Send email to the account owner, with a task created only for accounts with no reply | Duplicate emails if the report filter does not exclude records already notified |
| Renewal follow-up task | Weekly run over opportunities or contracts renewing in the coming quarter | Create a task assigned to the account owner using the record's owner field | Task volume can grow quickly if the window is wide and no task-exists check is applied |
| Stale opportunity alert | Weekly run over open opportunities with no activity for a defined period | Field update to flag the record, plus an email digest to the sales manager | Field updates trigger other workflows, so test the chain before turning it on |
| Overdue follow-up reminder | Daily run over tasks past their due date and still open | Email to the assignee, with escalation to a manager after a second run | Users who ignore daily emails may need an in-app or weekly summary instead |
| Manager weekly summary | Weekly run over a broad report grouped by owner or team | Email with report attachment or link, no record changes | Broad reports take longer to evaluate and may need a team filter to stay readable |
| Outbound status sync | Daily run over records changed since the last run, filtered on a modified-date or status field | Send HTTP request to a billing or ERP system, with keys held in App Secrets | Failed calls need a retry plan, and repeated runs must not resend unchanged data |
| Trigger choice | Scheduled run for batch jobs over many records, versus a field-change trigger for single record events | Use the scheduled option when timing depends on dates rather than user edits | Scheduled runs evaluate the whole list each time, so keep filters narrow for large datasets |
Setting up a scheduled renewal workflow step by step
This sequence takes a renewal or reminder rule from an idea to a scheduled workflow that runs on its own, with checks at each stage so that the first live run only touches the records you intended. The output is a tested, monitored automation that your administrators can explain and maintain.
Confirm background jobs run on schedule
Before building anything, the administrator confirms that cron or the scheduled task is running the EspoCRM background jobs on the server, as the server configuration documentation requires. Scheduled workflows depend on this job runner, so a missing cron entry means nothing fires, even when the workflow looks correct. Check the scheduled job status in the administration area and confirm that the job runner is active on the same PHP version the instance uses. The step is done when a test scheduled job runs and records a recent execution time.
Define the list report and its filter
Next, the administrator builds the list report that selects the target records, such as contracts with an expiry date within a chosen window or accounts with no logged activity for a set period. The filter should use the exact field and operator the business rule needs, and any reliance on relative dates should be checked against the report's own definition. Ask the business owner to review the logic in writing, since the report decides who gets contacted. The step is done when the report lists the records the owner expects, and the owner signs off on the filter.
Create the workflow with a scheduled trigger
The administrator creates a workflow in the Advanced Pack, sets the trigger to a scheduled run, and points it at the target entity and the list report. The schedule should match the business cadence the owner agreed, for example daily for expiry notices or weekly for stale opportunity alerts. Leave the workflow inactive while it is being built so that no run can start by accident. The step is done when the workflow saves with the chosen schedule and the report reference, and its status shows inactive.
Add conditions and actions
The administrator adds the actions the rule requires, such as creating a follow-up task, sending an email notice from a template, or updating a status field. Each action should use only the fields it needs, and any message content that depends on formula logic should be tested on a sample record first. Limit each run to actions that are reversible or easy to correct, because an email sent to the wrong audience cannot be recalled. The step is done when a sample record in a test copy shows every action output exactly as designed.
Test against a copy of the data
The administrator runs the workflow against a copy of production data rather than the live instance. This copy should contain records that match each branch of the rule, including edge cases such as records already notified or records with missing dates. Compare the report row count with the number of tasks, emails and field changes the workflow produced. The step is done when every expected record produced exactly one outcome and every excluded record produced none.
Review the workflow log before enabling
Before the workflow goes live, the administrator reviews the workflow log from the test runs and checks for errors, skipped records and unexpected repeats. A repeated notice on the same record usually means the rule lacks a condition that marks the record as already handled. Share the log and the row counts with the business owner so that the expected behavior is confirmed in writing. The step is done when the log shows no unexplained errors and the owner approves the enable decision.
Enable for a limited group, then all users
The administrator activates the workflow first for a limited set of records or a pilot team, then monitors the first scheduled runs in the workflow log and the scheduled job history. Confirm that the run time matches the configured schedule and that the record counts stay within the expected range. Once the pilot runs are clean, widen the scope to all users and record the decision and the owner in the change log. The step is done when several consecutive scheduled runs complete without errors and the scope is widened under documented approval.
How the timer, report and action interact
The scheduled trigger decides when a run starts, but the records it acts on are set by the conditions you attach to the workflow, usually expressed as a list report or filter. Each run re-evaluates those conditions when it fires, so a contract that enters the renewal window today is picked up on a later run without anyone editing the workflow. Confirm in the Advanced Pack documentation for your version whether the target is a report or a condition set on the entity, how many records one run processes, and whether a record that stops matching is dropped from the queue. Background execution depends on cron, as the server configuration docs describe, so a missed cron entry means a missed notice.
Formula Script handles the date work that a static filter cannot. Use it to compare a renewal date with the run date, count the days remaining, and build the text or payload the action sends. The formula documentation covers where scripts run, and the same language is available inside workflows, so the date logic can sit in the workflow itself. Test the boundaries with records due today, due tomorrow and already past, and confirm how the server time zone affects what counts as today. Keep payload construction in one step so a change to the notice wording does not require touching the selection conditions.
Repeated runs are the main risk. A daily timer will select the same record every day until its condition changes, so the workflow needs a state that the action itself updates. Add a field such as a notice stage or a last-notified date to the entity, have the action set it, and exclude records already at that stage in the conditions. Decide the order of the steps: writing the state only after the notification succeeds avoids silent gaps but can produce duplicates if the write fails, so choose the trade-off for each notice type. Then run the workflow twice against the same test data and confirm the second run sends nothing. Keep the stage transitions in your test notes so the history for each customer is traceable.
Security and operational risks in scheduled automation
Scheduled workflows send customer-facing messages and call other systems without a person watching each run. The risks below share one pattern: a mistake in recipients, visibility, permissions or credentials stays silent until a customer or auditor finds it. Each card names a control you can check before go-live and after every change.
Wrong recipients on expiry notices
A renewal notice that resolves its recipient from the wrong field or a stale account owner reaches a person who should not see a customer's license terms. Check which field the workflow uses for the recipient, and test it with records whose owner was changed recently. Confirm that the email template and recipient logic were reviewed by the people who own the customer relationship, not only by the person who built the rule. For a mail-based notice, also confirm how bounces and replies are routed back to the team.
Over-broad report visibility
Scheduled reports and list-based targets run with the permissions of the account that owns them, so a report built by an administrator can pull records a sales user should never see. Review the owner of each scheduled report and the roles and teams that apply to the records it returns. Use a dedicated service user with the narrowest role that still returns the needed rows, and re-test after role changes.
Over-permissioned API users for outbound calls
A workflow that posts renewal data to a billing or ticketing system usually authenticates as an API user. If that user can read or write far more than the call needs, a single misconfigured rule can change records in other systems. Prefer HMAC authentication over basic authentication, give the API user only the entity permissions the payload requires, and document which workflows depend on each user.
Silent failure when cron stops
Scheduled workflows depend on cron or a scheduled task running background jobs. If cron stops, is misconfigured after a server move, or the PHP process fails, the daily expiry notice simply does not go out and nothing in the CRM says so. Confirm that cron runs under the web server's user, check the job queue and logs after every deployment, and set an alert that fires when scheduled runs stop appearing for a day.
Credentials stored outside App Secrets
A workflow that calls an external API needs a token, and pasting that token into a workflow action or a template leaves it visible to anyone who can edit rules. Store every API key and token in App Secrets, restrict who can view or change them, and rotate them on a schedule. Check that exported workflow definitions and logs do not contain the raw value.
Unreviewed changes to live rules
A small edit to a schedule, a list filter or a formula can change which customers receive notices, and without a change record the team cannot explain the difference later. Keep a written list of active scheduled workflows with their owner, schedule, recipients and purpose. Require a second person to review each change, and test in a non-production instance before editing the live rule.
What do scheduled EspoCRM reminder workflows cost and take to build?
What drives the licensing cost of scheduled reminder workflows in EspoCRM?
The workflow engine sits in the Advanced Pack, which is included in all EspoCRM Cloud plans, so cloud licensing is the main recurring line. According to the EspoCRM pricing page, Cloud Basic costs 15 US dollars per user per month with a minimum of 3 users, Enterprise costs 25 dollars with a minimum of 5 users, and Ultimate costs 69 dollars with a minimum of 10 users. If you self-host the open-source edition, the software itself is free to download, but you must confirm with EspoCRM how the Advanced Pack is licensed for your own servers before you assume it is included. Ask your vendor to state the license terms in writing.
What does a DeployOpen engagement for reminder workflows include?
A typical engagement is fixed-scope and covers the work that makes reminders reliable: reviewing which expiry, renewal and follow-up events matter, designing the list reports the workflows will run over, configuring the scheduled workflows and their actions, testing against sample records, and handing over documentation. Scope, deliverables and timelines are agreed in writing before work starts. Recurring work such as ongoing support, upgrades and continuous testing is available as a separate retainer, so ask for those lines to be quoted separately.
How long does it take to build scheduled reminder workflows?
Duration depends mainly on the number of reminder types and the integrations they touch. A single expiry notice driven by one report is a small job. Each additional reminder type adds a report definition, a workflow, email templates, and test cases, and each external system adds mapping and failure handling. No duration is fixed in advance, so ask for a timeline tied to a written list of reminder types, data sources and recipients. Your own review cycles for report definitions and email wording also affect the calendar.
What do we need to provide before a reminder workflow build starts?
The build needs decisions and data from your side more than from the vendor. Name a data owner for each entity and field used in a reminder, such as contract end date, renewal owner or account status, and confirm who may change them. Provide written report definitions describing which records qualify, how often each reminder should run, and who receives it. Supply sample data that includes edge cases such as expired records, missing dates and inactive accounts. Finally, provide the mail settings: the sending mailbox, the sender name, and whether your mail relay requires specific authentication or allowlisting.
Can a competent EspoCRM administrator build simple reminders in house?
Yes, a simple reminder is a reasonable in-house task if the administrator has time and access to the Advanced Pack. A single scheduled workflow over one list report, sending one email to one owner, is well within the reach of an administrator who understands entities, fields and roles. The effort rises when reminders depend on several entities, need branching logic, or must run reliably in production. Those cases also need background jobs confirmed on the server, since EspoCRM requires cron or a scheduled task for background jobs. Test the workflow with sample records before enabling it for live data.
What recurring costs should we budget after the reminder workflows go live?
Recurring costs include the cloud subscription or the cost of hosting and maintaining your own server, the cron or scheduled task that runs background jobs, mail delivery, and administrator time for changes. When report definitions or reminder rules change, someone must retest the workflows. Platform upgrades also need planning, because each major release can affect extensions and customizations. Ask any partner to separate one-time build fees from retainer fees for support and upgrades, and confirm which items are covered by each.
What should a quote for reminder workflows contain?
A useful quote lists each reminder type with its trigger, report definition, recipients and email template, plus the systems involved and the test plan. It should state the EspoCRM edition and Advanced Pack assumptions, the hosting model, and which items the client provides. Ask for acceptance criteria for each reminder, the handover documents, and the support terms after go-live. Also ask what happens if the number of reminder types grows, and how a change request is priced and approved before work continues.
Limits to confirm in your environment
Scheduled renewal and reminder automation depends on five things that sit outside the workflow design itself: the Advanced Pack version, how often scheduled runs can fire, how many rows a report can hold, how fast your mail provider accepts messages, and whether your hosting runs the cron setup EspoCRM needs. Confirm each one against your own release and environment before you commit to a design.
Advanced Pack version compatibility
Scheduled workflows that filter list reports depend on the Advanced Pack matching your EspoCRM release. Ask whether the Pack version you plan to use supports the core version you will run, and whether that pairing is current for any upgrade you expect in the next year. Test the exact report and workflow on a staging copy with the same versions before you rely on it for renewal notices.
Scheduled run frequency
Confirm how often a scheduled workflow can fire in your deployment and whether your team's daily or weekly rhythm fits within that limit. Ask the vendor whether any minimum interval applies to scheduled triggers, and check how a run behaves when the previous one has not finished. Overlapping runs can send duplicate reminders, so verify that the workflow skips records it has already processed.
Report row limits for large datasets
Renewal reminders are only as complete as the list report that feeds them. Test how many records the report returns at your expected volume, and confirm whether a row cap or pagination affects the workflow when it runs unattended. A licence book with tens of thousands of contracts may return a partial set without any visible error, so compare the scheduled result with a manual count.
Email sending limits from your provider
Your mail provider sets the real ceiling on how many expiry notices and follow-up emails leave in a day or an hour. Ask the provider for its sending quotas, rate limits and bounce handling, then confirm how EspoCRM queues messages when the limit is reached. A burst of reminders on a single morning can trigger throttling or spam filtering, so spread scheduled sends across the day where possible.
Cron support in your hosting
EspoCRM needs cron or a scheduled task to run background jobs, so the scheduled workflow will not fire without it. Confirm with your hosting team or provider that the system can run the EspoCRM job runner at the interval you need, and that the schedule survives container restarts and server patches. For managed or shared hosting, ask whether you have shell or scheduler access before you design around it.
When to use scheduled workflows instead of event-driven automation
Use a scheduled workflow over a list report when the condition is about time passing rather than a single record changing. Renewals 30 days out, opportunities that have sat in one stage for a set period and tasks that are overdue are all states that build up quietly. Nothing in the record fires at the moment the condition becomes true, so an event-driven trigger would never see it. A scheduled workflow runs on the cron-driven job queue, selects the matching records from a saved list report, and applies the action to each one. The scheduling itself lives in the workflow's own settings, so the sweep is easy to review, pause and change without touching the entities.
Use event-driven automation when the reaction must be immediate or depends on a specific change. A status moving to Closed Won, a quote being approved or a case being reassigned should start work at once, and a sweep running once a day would be too late. Event-driven workflows and BPM timers also suit per-record sequences such as the drip campaigns and SLA timers covered in the sibling topics. Those are better than a nightly sweep when each record needs its own clock that starts at its own event, because a list report only sees the current state, not when a record entered it.
The practical test is to ask what the reader must see to act. If the answer is a record that has crossed a threshold, a scheduled sweep fits. If it is a moment someone changed something, use a trigger. Many deployments combine both: a trigger sets a date field when a contract is signed, and a daily scheduled workflow sends the renewal notice when that date is 30 days away. Before building, confirm the workflow trigger options and the scheduled-job setup in your EspoCRM version, and confirm that your server runs the cron job that background processing depends on.
How DeployOpen scopes and delivers scheduled EspoCRM workflows
DeployOpen plans scheduled EspoCRM workflows around your renewal dates, reminder rules and stale-record criteria before anything is configured. Work is delivered inside your own infrastructure, with the Advanced Pack's workflow engine and cron-driven background jobs checked end to end. Each engagement is fixed-scope, so the triggers, list reports, recipients and expected volumes are agreed in writing before the build begins.
How we scope
- We list each reminder type, such as license expiry notices or stale opportunity alerts, with its trigger date and owner.
- The written scope names the list reports, filters, recipients and schedule frequency that each scheduled workflow will use.
- Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before any configuration starts.
How we build
- We model the reminder logic in the Advanced Pack workflow engine, using Formula Script for date arithmetic and recipient rules.
- We test each schedule against seeded records in a non-production instance, including boundary dates, empty lists and duplicate triggers.
- We confirm cron runs on the host so background jobs fire on the planned cadence and time zone.
How we hand over
- We document each workflow's trigger, conditions, actions, owner and dependent list report in a runbook.
- We walk your administrators through the process log so they can see which records a schedule touched and why.
- We confirm the handover checklist with you, including who approves changes to recipients, dates and frequencies after go-live.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so schedules are reviewed as EspoCRM releases arrive.
- We review schedule volumes, failed runs and log output with your admins when a retainer is in place.
- Changes to reminder logic after handover are quoted from a written scope, so recurring costs stay visible.
