How scheduled report emails fit a weekly manager routine
Managers who export the same EspoCRM reports by hand every Monday are doing work the system can do for them. Scheduled report emails in EspoCRM, part of the Advanced Pack, send a saved report to a set of recipients on a fixed cadence, so the pipeline or support numbers arrive in the inbox before the weekly review rather than after someone has run the export. The Advanced Pack is included in all EspoCRM Cloud plans according to the EspoCRM Advanced Pack page, but if you self-host, confirm the report email options against the version and extension set you run before you design the routine around them.
Scheduled emails suit a fixed, recurring question that does not need interaction, such as opportunities by stage and owner for last week or open cases by age. Dashboards suit managers who want to look at numbers on their own time, and ad hoc exports suit one-off questions. The decision to email is about cadence and audience: if the same people need the same report every week and will act on it without logging in, a scheduled email is the right tool. Also decide early which reports belong in an email at all, since a report that changes meaning week to week, or that depends on filters a recipient cannot set, will generate follow-up questions instead of decisions.
Recipient access is the control that most often goes wrong. A scheduled report is generated under the rules of the access that the report and its recipients have in EspoCRM, so a manager should receive the rows their roles and teams allow them to see, and nothing wider. Before go-live, list each recipient, the team or role they belong to, and the data scope of each report, then test with a non-admin account that represents each recipient type. Confirm how the report owner's permissions are applied in your version, and avoid sending reports built by an administrator to people whose access is narrower than that administrator's.
Which delivery option fits each reporting need
This table compares scheduled report emails, on-screen dashboards, manual exports and a separate BI tool for weekly manager reporting. Read each row as a question you need to answer for your team, such as who maintains the output, who can see the data and what breaks when a report changes. The main takeaway is that scheduled emails keep reporting inside EspoCRM's access rules, but they still need an owner who reviews the report definition.
| Question | Scheduled report email | On-screen dashboard or manual export | Separate BI tool |
|---|---|---|---|
| Who maintains it | A CRM administrator or report owner sets the report, schedule and recipients | Each user builds or refreshes their own view, or an admin maintains the dashboard layout | A data or BI team models the data and maintains dashboards outside the CRM |
| Who can see the data | Recipients see what their EspoCRM user can access when the report runs, so confirm recipient roles | Only users who log in and have access to the report or record can see the data | Access depends on the BI tool's own user model and data connections, which you must configure separately |
| Effect of a report change | A changed report alters future emails, so the owner should retest before the next run | Users see the change at their next refresh, and manual exports reflect the old definition | Changes go through the BI tool's model, which may need a data refresh before results match |
| Format and delivery | Email delivery in the format the report supports, with no login required for managers | Visible in the browser or as a file the user downloads and shares | Depends on the tool's sharing and subscription features, which you should confirm |
| Best fit | Regular summaries managers need in their inbox each week | Users who need live views or one-off analysis | Cross-system analysis that goes beyond what EspoCRM holds |
| Ongoing risk | Emails can reach people who no longer should see the data if recipients are not reviewed | Exports leave the system once downloaded, so sharing rules need a policy | Duplicate definitions across two tools can drift apart over time |
Setting up the scheduled report email step by step
This sequence moves a weekly report from a working Advanced Pack and cron setup to a verified recurring email, with a check at each stage so that problems surface on a test account before managers receive anything.
Confirm the Advanced Pack and cron run
Confirm that the Advanced Pack is installed or included in your plan, and that the cron job or scheduled task required for background jobs is running on the server. The EspoCRM server configuration docs describe cron as a requirement for background jobs, so an administrator should check that the job executes on the schedule defined for the host, using the server's own scheduler logs. Done means the Advanced Pack reports appear in the admin interface and background jobs are processing. Confirm exact menu locations in the admin UI of the version you run.
Configure and test outbound mail
An administrator sets up outbound email for the instance, including the sending address, SMTP or other transport details supplied by your mail provider, and any sender authentication your provider requires. Send a test message to an internal mailbox from the administration area. Done means the test message arrives in the inbox, not the spam folder, with the expected sender name. If it fails, check the mail settings and the server logs before moving on, because every later step depends on this one.
Build and review the report on a test account
Create the report on a test user account using a small sample of records, such as a few opportunities or cases with known values. Check that the grouping, filters, date range and currency display match what you would expect from the source records when you count them by hand. Done means the report output matches the hand count for the sample. Keep the report restricted to the test account until the email content has been reviewed.
Create the schedule and set recipients
Attach the report to a scheduled email using the schedule settings in the Advanced Pack, choosing the frequency, the day and time, the format and the recipient managers. Limit recipients to people whose access to the underlying records matches the report's contents, because the report is generated under the rules that apply to the scheduled user and recipients should not receive data they could not open in the application. Done means the schedule shows the correct recipients, frequency and next run time.
Run a test send to a test recipient
Trigger a test send, or temporarily point the schedule at one internal test recipient, and open the message on a desktop and a phone. Check the subject line, the attachment or inline table, the formatting of numbers and currency, and that no records appear that the test recipient should not see. Done means the message renders correctly and the content matches the test account review. Restore the intended recipient list afterward and confirm the change was saved.
Check the first live send against source data
After the first live send, compare totals in the email with the same report run directly in the application, and spot-check several records against their detail views. Confirm that each manager received the message and that the schedule shows the expected next run. Done means the figures match the live report and the schedule is recorded as operating. Keep a short written record of the setup so that the next administrator can repeat the check after upgrades or mail changes.
Protecting report data in transit and in inboxes
A scheduled report sends pipeline or case data out of EspoCRM on a fixed cadence, often to people outside the CRM's daily user base. The cards below cover who can change schedules, which accounts run them, where the data lands, how the mail is carried and signed, and how long sessions stay valid.
Restrict who can schedule reports
Creating or editing a scheduled report decides what data is sent, to whom, and how often. Limit those rights to a small group of named analysts or admins through roles, and remove them from users who only need to view reports. Review the list of scheduled reports each quarter, checking each recipient list against current managers. Confirm which role permissions govern scheduling in your EspoCRM version before you grant access broadly.
Keep scheduling off admin accounts
Scheduled reports that run under or are edited by an administrator inherit a broad view of the data and the ability to change system settings. Make the scheduling owner a standard user with the report access it needs, and keep administrator accounts for configuration only. The EspoCRM security guidance recommends avoiding admin accounts for daily work, and this applies equally to report scheduling.
Stop data leaving through personal mailboxes
A report sent to a personal address or a forwarding rule can move pipeline values, account names and contact details outside your mail controls. Decide which mailboxes are approved recipients, prefer shared team addresses with managed membership, and check that managers do not auto-forward these emails. Document who owns each recipient address so offboarding removes access.
Confirm relay encryption and sender authentication
Report emails travel from EspoCRM through your outbound mail relay to recipient servers. Ask your mail provider whether the relay uses TLS for connections, and whether SPF, DKIM and DMARC are configured for the sending domain so recipients accept the messages. These controls live in your mail environment, not in EspoCRM, so record the answers in the implementation runbook.
Set session and token lifetimes
Scheduled sends run in the background, but anyone who opens the CRM in a browser or holds an API credential can still reach the reports. Review the authentication token lifetime and session settings in EspoCRM against the security guidance, and shorten them for users who can view sensitive reports. Confirm with your IT team how idle sessions end on shared workstations.
Restrict access by IP address
Where managers read reports from known office or VPN networks, an IP allowlist limits who can open the CRM even if credentials leak. Scheduled emails still arrive regardless of the viewer's network, so the allowlist protects the report data behind the link, not the mail itself. Test the allowlist with a manager on a remote connection before you rely on it.
Recipient access rules by audience
Managers who receive a weekly pipeline report usually hold a role with wide read access to opportunities, often across several teams. For them, the report summarizes the business, and their role decides which rows and totals can appear. A manager may receive figures for records they could not open from a list view if the report is evaluated under the account that sends it. Confirm this behavior in your version before you rely on it.
- Role scope: check which role the manager holds and whether it grants read access to every entity and field the report uses.
- Team membership: a manager in several teams may see totals that differ from what they expect, so test with a named account.
- Aggregated output: grid totals can reflect values from records the manager cannot open one by one, so document that decision with the business owner.
- Sensitive fields: remove fields such as margin or internal notes from the report columns, since a layout change does not alter what the email contains.
Before the first scheduled send, compare the email with the same report run by a test user holding the manager's role.
Team leads usually see only their own team's records. A report sent to a lead should match that scope, so the report must either inherit team-based access or filter explicitly on the team. Team-based access is the common design, but it depends on how teams are assigned to records and on whether the report uses that assignment.
- Team assignment: confirm that records carry the team you expect, because records without a team may fall outside the lead's view.
- One report per team: separate reports keep each email limited to one group and avoid sending one team's pipeline to another lead.
- Shared ownership: opportunities owned by people in more than one team may appear in more than one email, which may or may not be intended.
- Membership changes: when people move between teams, confirm how the next scheduled send reflects the new membership before a reorganization takes effect.
For a sample week, compare the totals in one team's email with the list view filtered to that team.
Administrators can open nearly every record, so any report they can run is the broadest version of that report. The risk is that an administrator account used to build or send reports can also receive, forward or change sensitive data. The EspoCRM security guidance recommends avoiding admin accounts for daily work, so scheduled reports should be configured under a dedicated account with only the access the report needs.
- Dedicated sender: set up schedules under a non-admin account, following the EspoCRM security guidance.
- Admin recipients: keep administrator mailboxes off report distribution lists unless an operational need is documented.
- Change control: record who edits schedules and recipient lists, since one edit can widen an audience.
- Authentication: the security guidance recommends requiring 2FA and limiting token lifetime. If sign-in goes through OIDC, note that EspoCRM's own 2FA is not compatible with OIDC, so the identity provider must enforce the second factor.
Review the schedule list and its recipients at a cadence your access policy sets.
Partners and customers should not receive scheduled report emails built from internal data. Email copies the figures outside EspoCRM's access model. Once sent, the data sits in external mailboxes, can be forwarded, and cannot be recalled. Routing external audiences through the portal keeps the data inside the system, where portal roles define what each user can open.
- Data leaves control: a report email cannot be restricted after it is delivered, so the content has to be safe for every reader.
- Portal routing: give external users access through the portal, where roles determine the reports and records they can see.
- Account-limited data: portal designs can limit records to the portal user's own account, a restriction that email does not enforce.
- Separate sign-in: external users need their own authentication policy, kept apart from the internal sign-in design.
Before adding any external recipient to a schedule, confirm which reports each external role can open in the portal and test them with an external test account.
Why background jobs decide whether reports arrive on time
Scheduled report emails in EspoCRM are not sent by the web request that a user sees. They run as background jobs, and the EspoCRM server configuration docs require a cron job or an equivalent scheduled task to run them. If that scheduler is missing, paused, or failing, the schedule you configured looks correct in the interface while nothing leaves the server. Managers simply stop receiving their Monday pipeline report, and nobody in the CRM sees an error unless someone goes looking. Treat the scheduler as part of the reporting feature, not as server housekeeping, and assign an owner for it during the build.
Before go-live, confirm three things with a test schedule that targets an internal mailbox. First, the cron entry or scheduled task runs on the host you intend to use, under the account EspoCRM expects, at the interval the docs describe. Second, the job queue shows the report job being picked up and completed, not stuck or waiting. Third, the EspoCRM logs record the outcome, so a failed send leaves a trace your team can find. Ask your implementation partner or internal admin to show each step on screen and in the log files. Also agree how a failed send gets reported to the report owner, because the default position is silence.
The scheduler host is still a supported server for this purpose, so the PHP and database versions in the server configuration docs apply to it. The docs list PHP 8.3 to 8.5 and MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15. A host that was upgraded for another application, or a cron environment with a different PHP binary on the path, can run jobs under a version your instance does not support. Confirm the PHP binary the cron job calls, and check it again after any operating system or PHP update, since a version change can break background jobs without touching the web application.
Limits to confirm before promising a weekly send
A weekly report email is only as dependable as the limits behind it. The items below cover what the report can carry, how it is delivered, and what happens when the data or the schedule changes. Confirm each one in your own instance with a test send before you commit a delivery date to managers.
Maximum report size and row count
Large grid reports can exceed what a mail server or recipient mailbox accepts, and the cut-off may differ from what appears on screen. Run the scheduled report against your largest real pipeline or queue, then open the received message and compare the row count with the report view. Ask your vendor or check the instance configuration for any documented limit on rows or file size, and confirm your mail relay's attachment ceiling separately.
Supported attachment and inline formats
Managers may expect a spreadsheet, while others only read a summary in the body of the email. Confirm which export formats the deployed version offers for scheduled sends, and whether tables render correctly in common mail clients. Test a send to a phone and to a desktop client, since column widths and currency symbols often break in one but not the other.
Time zone handling for weekly schedules
A send set for Monday morning may arrive on Sunday night for a manager in another region, or the schedule may follow the server clock rather than the user's time zone. Confirm how the instance and each user's preferences set the send time, and check the time zone of the application server against the expected local time. Verify with a test schedule set a few minutes ahead, and document which zone the business uses for week boundaries.
Bounce and failure notification
A scheduled send can fail silently when the mail transport rejects a message, the cron job stops, or a recipient address bounces. Confirm where failed sends are recorded in the admin area, who receives the failure notice, and whether bounces return to a shared mailbox that someone monitors. Without this check, a manager may assume the report arrived when no one has seen it for weeks.
Effect of report edits on scheduled sends
Changing a report's filters, columns or grouping after a schedule is set can change what recipients receive, sometimes without a visible change to the schedule itself. Confirm whether an edit applies to the next send only, and whether the recipient list and filter values are re-evaluated at send time. Record the report owner in your change process, and send a test after any edit to the report.
Options in the deployed version
Scheduling options, formats and notification settings change between releases, so a feature described in general documentation may not exist in your build. Confirm the exact options in your instance's administration screens and against the release notes for your version. Plan the reporting setup for the version you run, and recheck it before any planned upgrade.
Questions managers and admins ask before setting this up
What does it cost to set up scheduled report emails in EspoCRM?
The software has no license fee for the open-source edition, so the cost is the work to configure and test the sending, plus any mail service you pay for. Setup covers the outgoing mail settings, the background job that sends the reports, the report recipients and the access checks for each recipient. The main cost drivers are how many reports and recipient groups you have, whether your mail server needs new rules, and how many test rounds the team needs. If you use EspoCRM Cloud instead, the pricing page lists 15 US dollars per user per month on the Basic plan (minimum 3 users), 25 dollars on Enterprise (minimum 5 users) and 69 dollars on Ultimate (minimum 10 users), with the Advanced Pack included in all cloud plans. Ask any partner for a quote that lists one-time work and recurring costs separately.
How long does a first scheduled report setup take?
The duration depends on how many reports go out, how many distinct recipient groups exist, and how clean the mail path is. A single weekly pipeline report to one manager group is a much smaller job than a set of role-based reports with different access rules. Delays usually come from waiting on mail server changes, sign-off on report contents, or access questions rather than from EspoCRM itself. Ask for a written timeline that names each dependency, such as the mailbox owner, the report owners and the test window. Any duration you are quoted should be tied to a written scope.
What must our team provide before the work starts?
Your team needs to provide four things before the build begins:
- Access to the outgoing mail server or relay, with the sending address and authentication details your security team approves
- A test mailbox that can receive reports without going to real managers
- A named owner for each report, who confirms the columns, filters and currency basis
- A list of recipients with the access they should have, approved by the person who owns that data
You should also confirm that EspoCRM's background job runner is scheduled, as the EspoCRM server configuration docs require cron or a scheduled task for background jobs.
Can an internal admin set up scheduled report emails alone?
Yes, a capable internal admin can often do this alone if they have admin rights, access to the mail relay and time to test. The work is mostly configuration: setting the outgoing mail, creating the reports, and scheduling delivery. The harder parts are the access rules, since recipients must only see records their role allows, and the mail path, which often needs help from whoever runs the mail server. Admins who work in the same instance daily should avoid using their admin account for everyday tasks, as the EspoCRM security docs recommend. Decide early who will own the schedule after go-live, since a report that breaks silently is noticed only when a manager asks where it went.
How do recipients get the right data in scheduled reports?
Each scheduled report runs with the rights of the setup it is attached to, so recipients should not receive records their own access would hide. Review every recipient group against the roles and teams they belong to, and test with a user in each group before turning the schedule on. Recipients who are not EspoCRM users, or who should see only part of the data, need a separate design that the team agrees on in writing. Treat this check as part of acceptance, not an optional extra, because a misdirected pipeline report can expose customer and revenue data.
What should a fixed-price engagement for this include?
A fixed-price scope should list the reports, the recipient groups, the delivery frequency, the output format, and the mail path that will be used. It should also name what is out of scope, such as new report design, portal access or changes to the mail server itself. Ask for the acceptance test, the number of test rounds included, and who signs off each step. Most engagements are fixed-scope and agreed in writing before work starts, so changes to the list of reports or recipients should go through a written change request. Compare quotes by scope, not by headline price.
What breaks most often with scheduled EspoCRM report emails?
Most failures come from a few predictable causes:
- The background job runner is not scheduled, so emails queue but never send
- The mail relay rejects messages from the EspoCRM server because of sender rules or authentication
- A report's filters change after a schema or layout update, so the numbers shift without an error
- A recipient's role changes, and they either see too little or too much
Add a test run after each of these changes, and keep a short runbook that tells the admin where to check the job queue and the mail log. Logs and job checks are covered in the EspoCRM operations documentation.
Should we confirm the mail setup with our security team first?
Yes. Before configuration, confirm with your security team which mail relay, sending address and authentication method are approved, and whether the EspoCRM server is allowed to connect to that relay. Ask them to review how report content leaves the system, since attachments carry customer data outside the application. Check whether your policy requires encryption in transit for the relay and whether recipients outside your organization are allowed at all. Document the answers, because auditors and security reviewers will ask how scheduled exports are controlled.
How DeployOpen scopes and delivers scheduled reporting
DeployOpen treats scheduled report emails as part of the wider EspoCRM deployment, not a standalone setting. We start from the reports managers actually need, the people who should receive them, and the access rules that decide what each recipient can see, then build and hand over a tested configuration that your own administrators can maintain.
How we scope
- We list each scheduled report, its owner, its audience and the cadence agreed with the business.
- We confirm which EspoCRM instance and Advanced Pack setup the reports run on, and which mail server sends them.
- Engagements are fixed-scope, and the written scope names the recipients, formats and access rules covered.
How we build
- We configure the report email settings, recipient lists and delivery format against the agreed scope.
- We check that each recipient role sees only the records permitted by their team and role settings.
- We test scheduled sends with sample data and review the output against the source report before go-live.
How we hand over
- We document each schedule, its recipients, its access assumptions and the steps to change them.
- We walk your administrators through adding recipients, pausing a schedule and reading the mail logs.
- We record the mail server, cron or scheduled task dependencies so your team can troubleshoot later.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer scope can cover checks after EspoCRM upgrades, since report and mail behavior may change between versions.
- Ask us to confirm the support terms in writing with the quote, including what counts as a change request.
