Why teams put EspoCRM report filters and panels on everyday screens
Report-based list filters and record panels let sales and service staff see a report-defined subset of records without leaving the list or the record they are working on. In EspoCRM, the Advanced Pack adds reports, and a report can be used as a filter on a list view or shown as a panel on a record detail view, so the same definition of, for example, open opportunities above a certain amount or support cases awaiting a reply, appears wherever the user works. The Advanced Pack is an official add-on that the EspoCRM Advanced Pack page describes as included in all EspoCRM Cloud plans, and self-hosted deployments need it licensed separately, so confirm your edition and pack status before designing around it.
Teams need this when the same subset is used by many people across list and detail screens, and when the logic is too involved for a saved filter, such as conditions spanning related entities or grouped criteria maintained in one place. A plain saved filter or a layout change is enough when the condition is simple, applies to one list, and only one role needs it. Reports add a second copy of the logic to maintain, so a report-based filter is worth its upkeep only when the definition must stay consistent across screens. Before committing, confirm in your EspoCRM version which report types can drive list filters and which can appear as panels, since the documented behavior can differ between releases.
The decision that matters most is access. A report panel or filter only shows records the viewing user is allowed to see, so a manager's panel can look empty to a frontline user with narrower team or role permissions. Test each role that will use the screen with its own account, not an administrator account, and check the results against the report's own output. Document which reports drive which screens, because a later change to a report will affect every list and record that depends on it.
Choosing between a list filter, a record panel and a dashboard
Use a list filter when the question is which records match a condition, such as open cases in a support queue or accounts with a renewal date in the coming months. The output is a set of records the user can open, sort and act on one at a time. Because the list is the working surface, the access question starts with record visibility: a user sees the entity rows their role and team scope allow, and the report only narrows that set further.
- Who sees it: users whose role can read the entity, limited to the rows their ownership or team scope permits.
- What it shows: matching records in list form, with the columns the list layout exposes.
- Maintenance: the filter logic depends on field names, stage values and status options. A renamed option can make a filter return fewer rows without any error, so recheck filters after schema changes.
- Access review: confirm that the filter reveals no fields or records the role cannot already open through the normal list.
- Best fit: working queues where the next action is taken on each record.
For each filter, identify the role that uses it and have a test user with that role confirm the expected rows and nothing more. Confirm the exact filter behavior in your EspoCRM version before you commit to the design.
Use a record panel when a user is working on one record and needs related information beside it, such as the open opportunities linked to an account or the recent tickets for a contact. The panel answers a question about that single record, so it is shown only where the parent record is opened. Its contents depend on the permissions the viewer holds for the related entity, which means the same panel can look different for two users on the same account.
- Who sees it: users who open the parent record and hold read access to the related entity.
- What it shows: a compact, record-specific set of related items, placed in the detail layout of the parent entity.
- Maintenance: each panel is configured per layout. A layout copied to a new entity or changed for a new team needs its panels reviewed as well.
- Access review: test the panel with a user who can open the parent but not the related entity, and confirm the panel stays empty or hidden.
- Performance: many panels on one layout add load to every record view, so keep the number to what users need on each visit.
When a question needs data from many records, move it to a list or dashboard instead of stacking more panels. Confirm in your own instance how panels behave for users with partial access before you publish them to the team.
Use a dashboard when the question is about totals, trends or distributions across many records, such as how many open cases each queue holds or how pipeline value is spread across stages. Dashboards are built from dashlets placed on a user's own layout, so the view is personal and each user's setup has to be maintained. The figures are only as trustworthy as the reports behind them, so the report's access and filter logic travels with the dashboard.
- Who sees it: the user who owns the dashboard, and only the data that user's role allows through the underlying reports.
- What it shows: aggregated counts, totals or charts rather than individual records to act on.
- Maintenance: each dashboard is a separate configuration. Changes to a shared report need every dependent dashboard checked, and default layouts for new users need their own review.
- Access review: confirm which roles can see each dashboard and whether any admin edits to user dashboards are logged in your process.
- Best fit: team overviews, manager reviews and monitoring where users move on to a list when a number needs action.
Dashboards multiply the number of places a figure can be read, so keep the set small and assign an owner to each one. Confirm the dashboard sharing, locking and default-layout options in the version you run before you write the access policy.
Choose the smallest surface that answers the question, then record who owns it and how its access is checked. A common pattern is a list filter for the work queue, a panel for the context on the record and a dashboard for the summary for managers. Each surface adds maintenance, so a team that adds all three for the same data usually creates three places to fix when a field changes.
- One question, one surface: map each business question to a single primary view before building it. (Illustrative: a support lead needs the queue and the weekly count, so the queue is a list filter and the count is a dashboard dashlet.)
- Owner per report: name the person who maintains each report that feeds a filter, panel or dashlet.
- Role-based test accounts: keep one test user per role that uses these surfaces and rerun them after upgrades or schema changes.
- Access inventory: list every filter, panel and dashboard with the roles that can see it, and review that list on a fixed schedule.
- Change control: route report and layout changes through the same review as other permission changes.
Before sign-off, ask for a written list of every surface, its owner, its audience and its test results. Confirm the review cadence with your internal audit or compliance team so the inventory stays current.
Configuration options and when each fits
This table compares the main setup choices for report-based list filters and record panels: the report source, the entity it reads, and how the panel is shared. Read each row as a decision the admin makes once, then check the labels and behavior in your own EspoCRM version before you commit. The main takeaway is that every choice that is shared across teams or entities adds a maintenance point that someone must own.
| Option | When it fits | What it changes for maintenance |
|---|---|---|
| Report feeding a list filter | Teams need the same narrowed view of a list, such as open opportunities for their own pipeline, and the logic can be expressed as one report. | The filter depends on the report. Renaming, deleting or changing the report's columns or conditions changes what users see in the list. |
| Report feeding a record panel | Users need a summary or related records on a detail screen, such as open tasks or recent cases for the account they are viewing. | The panel is tied to the record type and layout. Changes to the source report or the layout must be checked on every screen where the panel appears. |
| Report on the record's own entity | The panel should show records linked to the current record, so the report filters on the relationship to that record. | Relationship and field changes on the entity can break the filter silently. Test with a record that has linked data and one that has none. |
| Report on a different entity | The list or panel needs data from another entity, such as accounts summarized on a contact screen. | Two entities must stay aligned. Field renames or relationship changes on either side need a retest of both views. |
| Panel shared through the layout | All users who can open the detail view should see the same panel with the same content. | One change applies to everyone. Fewer objects to manage, but there is no per-team variation without a second layout. |
| Panel limited by role | Sales and service users should see different information on the same record type, based on their access. | Each role's access must be reviewed when permissions change. Confirm the exact access settings in your version, since users who lack access to the report's data will see nothing or an error. |
| List filter for a single team | Only one team needs the narrowed list, and other users should keep the standard view. | Each additional team filter is another report to name, document and retest after upgrades. Confirm where filter visibility is configured in your version. |
How to set up a report-based filter and a record panel
This sequence takes a report from design to a verified list filter and record panel, so that a non-admin user sees the same records in the list and in the report. Each step ends with a check that the result matches before the next step starts.
Confirm the Advanced Pack is installed
An administrator opens the Administration area and checks that the Advanced Pack is installed and active, since reports and report-based panels depend on it. Confirm the version matches the EspoCRM core version in use, and note that the Advanced Pack is included in all EspoCRM Cloud plans for self-hosted teams to plan around. Done when the Reports menu appears in the navigation for an admin user and the Advanced Pack shows as enabled in the extension list.
Build and test the report
Create the report in the Reports module against the target entity, such as Opportunity or Case, and set the filters that define the business rule, for example open records owned by the user's team. Keep the report scope narrow and explicit so the same logic can be reused in a list filter and a panel. Run the report as an admin and record the count and sample records. Done when the report output matches a manually checked set of records in the database or the list view for the same criteria.
Configure the list filter
In the Entity Manager or the list view settings for the entity, add the report as a list filter option so users can apply it from the list view. Give the filter a clear label that describes the business rule. Save the layout and reload the list. Done when the filter appears in the list view filter menu and applying it returns the same record IDs as the report run in the previous step.
Configure the record panel
On the detail layout of the related entity, add a panel that displays the report results for the current record, such as related opportunities for an account. Set the panel title, the number of rows shown and the link target so users can open the full report. Save the layout. Done when opening a record with known related rows shows the same rows in the panel as the report filtered to that record.
Assign role permissions
Create or update a role for the target users and grant read access to the entity, the report and the scope the panel needs, such as own or team records. Check that the role does not expose fields or records beyond the business need. Assign the role to a teams or user group, not to individual admin accounts. Done when the role is saved and the permission matrix shows the intended scope for each entity used by the report and the panel.
Test as a non-admin user
Create a test user with the new role, and sign in as that user in a separate browser session or private window. Apply the list filter and open at least two records, one with related rows and one without. Compare the list count and the panel rows against the admin report result filtered for that same user. Done when the counts and record IDs match, and records outside the user's scope do not appear in either the filter or the panel.
Document the filter and panel for operations
Record the report name, the filter label, the layout change, the role assigned and the test user results in the change log or runbook kept by the administrators. Note which changes will need to be retested after an EspoCRM upgrade or an Advanced Pack update, and confirm who owns those checks. Done when the runbook entry is complete and the owner has acknowledged it, so the filter and panel can be reviewed with the next release.
What role access the filters and panels need
A report-based list filter or record panel only shows what the viewing user is allowed to see, so the report result depends on the user's role, teams and report permission. The checks below cover the access layers that most often produce a filter or panel that looks empty, or worse, shows records to the wrong people.
Record-level scope in the role
The role decides whether a user sees all records, only their own, only their team's, or none for each entity the report reads. A report can be configured correctly and still return nothing for a sales rep whose role scope is set to own records. Check the role for every entity the report touches, using a non-admin test account that matches a real job role. Confirm that the scope on the related entity, such as Account or Opportunity, is also what the panel needs.
Team membership drives visibility
When a role uses team-based scope, a user sees records only through the teams they belong to, so a report filter can drop records silently after a reorganization. A new hire added to the wrong team sees a shorter list with no error. Before go-live, compare the team list of each test user with the teams that own the records the filter should show. Record who approves team changes, because those changes alter report output without touching the report itself.
Report read permission
Being able to open a list view or record does not automatically mean a user can read the report that feeds a filter or panel. If the report is hidden from a role, the filter may be missing or the panel may fail for that user. Check the report read permission for each role that will use the screen, and confirm the behavior in a test account rather than assuming it from the admin view.
Admin testing hides real access
Administrators bypass most role restrictions, so a filter or panel that looks correct when an admin opens the screen may be empty or incomplete for everyone else. Test every filter and panel with non-admin users from each affected role, and keep those test accounts separate from daily admin logins. Admin accounts should not be the sign-off tester for access behavior.
Verify with a written access matrix
Turn the checks into a short matrix that lists each filter and panel, the roles that should see it, the scope each role needs, and the test account used to confirm it. Re-run the matrix after every role change, team change or report edit. A matrix gives reviewers a clear basis for approving access and makes it obvious which screens need retesting after an upgrade.
How report results reach list views and record screens
The core point is that a report in EspoCRM only defines criteria. It does not store a copy of the data for each screen. When a user opens a list view with a report-based filter or a record detail view with a report panel, the screen asks the server for the rows that match the report's criteria, for the user who is logged in. Permissions are applied at that moment: the user only sees records their role and team membership allow, so the same report can show different rows to a sales rep, a manager and an admin. Plan your roles with this in mind, because a filter that looks correct for an administrator may be empty or partial for a standard user.
Refresh behavior is the detail to confirm before you promise anything to users. Scheduled background jobs are part of EspoCRM's operating model (the server configuration docs require cron or a scheduled task for background jobs), but do not assume that every report view depends on a job. Check the EspoCRM docs and test in your version whether list filters and panels reflect a new record immediately after it is saved, and what happens after a bulk import or a change to a related record. Record the result in your test plan, since the answer determines whether managers can trust a panel during a live sales review.
Test the path with at least two real user accounts that differ in role and team, and with the report's own access settings checked for each. Confirm that a filter built from a report returns the same rows for a user as the report itself does when that user runs it. Also confirm that a panel hides rows the user cannot open, and that the panel count and the visible list match. If the results differ, check record-level permissions first, then team assignment, before changing the report criteria. Document which account types you tested, so the sign-off covers the access model you actually run.
Security and operational risks to control before rollout
Report-based filters and panels look like read-only convenience, but they expose data through screens many users never think of as reports. The cards below cover the access, change and upgrade risks that most often surface after go-live, and the checks to run before users see the first panel.
Over-broad roles exposing rows through panels
A report panel runs with the permissions of the report's scope and the viewer's role, so a panel can show records a user could not open directly if the report filter is looser than the record view. Check each role that sees the panel against the entity's access level, team and ownership settings. Test with a standard user from each team, and confirm that the panel returns the same rows as the list it sits beside. Watch for the panel showing counts or fields the role cannot read on the detail record.
Admin accounts used for testing
Building and testing filters while signed in as an administrator hides exactly the access problems you need to find, because admins bypass most role restrictions. Follow the EspoCRM security guidance to keep administrator accounts out of daily work, and create dedicated test users with the real roles your teams hold. Record which account produced each test result so a passing check is not mistaken for proof that a role is safe.
Restricting access by network
Report panels often surface sensitive customer or pipeline data, so the instance itself should not be reachable from networks that have no business reason to see it. Review the IP allowlist settings in the EspoCRM security guidance and decide which networks, VPN ranges or identity provider paths may reach the application. Confirm that API users and integrations are included in that decision, because they bypass the browser screens where you would normally notice a problem.
Shared layout changes reaching every user
Adding a report panel to a record layout changes the screen for every role that uses that layout, not only the team that asked for it. Before editing a shared layout, list the roles and teams that see the entity and decide whether a separate layout or a dynamic condition is the safer choice. Keep a record of layout changes and who approved them, and test the affected entity with users from each group that could see the new panel.
Report edits breaking filters after upgrade
A saved report that drives a list filter or panel depends on entity fields, report definitions and scopes that can change between versions, so a successful build does not guarantee a working screen after an upgrade. Export or document each report and its place in layouts before an upgrade, then rerun the same test cases on the upgraded staging copy. Treat a filter that returns zero rows after an upgrade as a failure to investigate, not as an empty result. Plan these checks as part of the EspoCRM upgrade plan rather than after users report problems.
Ownership of report logic after go-live
A filter or panel built by one administrator often becomes a dependency for several teams, and nobody owns it when the original builder moves on. Assign an owner for each report used in a filter or panel, record which entities and layouts it touches, and set a review date. Ask your implementation partner to hand over this inventory as part of the documentation, so that changes after rollout pass through the same review as the original build.
Questions buyers ask before building report filters and panels
What drives the cost of building report-based list filters and panels in EspoCRM?
The cost depends mostly on how many reports, roles and layouts are involved, and how much testing each one needs. A single list filter on one entity with one role is a small job. Several reports feeding filters and panels across sales, support and management roles, each with its own access rules, multiplies the design, build and verification work. Ask for a quote that lists each report, each layout change and each role separately, so you can see which items drive the total. Costs are one-time for the build and recur only if you buy ongoing support or retainer work.
How many roles and layouts change the effort most?
Roles and layouts usually add more effort than the reports themselves. Each role that should see a filter or panel needs its access checked against the report's data, and each record layout that gains a panel needs to be reviewed on every entity it touches. A panel that looks correct for an administrator can expose or hide records for a standard user, so every role needs a test pass. Ask the quote to state how many roles and layouts are in scope and whether role testing is included.
Can our own admins build report filters and panels in-house?
Yes, a team with an administrator who knows the EspoCRM Entity Manager, layouts and roles can build simple filters and panels in-house. The Advanced Pack provides the reports these features rely on, and it is included in all EspoCRM Cloud plans. Harder cases include reports that depend on formula logic, multiple roles with different visibility, and changes that must be tested before release. Decide which group owns the work after the build, because someone must keep reports and role access correct when the business changes.
What do we need from our admins and data owners?
You need an admin who can make configuration changes and a data owner who can confirm which records, fields and statuses each report should show. The data owner settles definitions such as what counts as an open case or an active account, which is often the slowest step. The admin provides access to a test instance, the current role matrix and any existing layouts. Without these inputs, filters look correct but return the wrong records, and that error is hard to spot later.
What makes the timeline longer or shorter?
The timeline depends on the number of reports, how settled the business definitions are, and how many approvals and test cycles your organization requires. Work moves quickly when definitions are agreed and the role matrix is documented. It slows when data owners disagree on definitions, when roles change during the build, or when a change must pass a formal review before it reaches production. Ask for a written schedule in the scope, because durations depend on your environment and are not something this page can state.
How do Cloud and self-hosted EspoCRM differ for the Advanced Pack?
The Advanced Pack is included in all EspoCRM Cloud plans, according to the EspoCRM pricing page. Cloud pricing is listed at 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). The open-source edition can be downloaded and self-hosted for free, according to the same pricing page, but the Advanced Pack is an add-on, so confirm its current licensing terms for a self-hosted instance on the EspoCRM Advanced Pack page before you plan the build.
What breaks after go-live, and what should we check first?
The most common problem after go-live is a filter or panel that stops matching the data because a status value, field or role changed. Check the report output against a known set of records for each role after every configuration change. Keep a short list of which filters and panels depend on which reports, so an edit to one report does not silently change a screen that other teams use. Ask whether the quote includes a post-launch review period and who owns fixes afterward.
How DeployOpen scopes and supports report-based views in EspoCRM
DeployOpen plans, builds, documents and supports report-based list filters and record panels inside your own EspoCRM instance, whether it runs in your cloud account, a data center or an air-gapped network. Work starts from a written scope that names each report, screen and role involved, so access rules are settled before anything appears on a shared screen.
How we scope
- We list every list view and record detail screen that should show report-based filters or panels, and who uses each one.
- We map the report, its filters and the role permissions each user group needs to see the results.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and a quote follows from that scope.
How we build
- We configure list filters and record panels through the Advanced Pack reports and the layout settings in your instance.
- We test each view with a user from every role, checking that records outside a user's access never appear in a filter or panel.
- We review report permissions against the role model and flag any report that exposes fields a role should not read.
How we hand over
- You receive a written record of each report, the screen it feeds, the roles that can see it and the test cases used.
- We walk your administrators through how to change a filter or panel without breaking the underlying access rules.
- Configuration is exported and documented so your team can rebuild or review the setup on another instance.
How we support
- After handover, changes to reports, roles or screens can be handled under a support or maintenance retainer.
- Upgrades to later EspoCRM versions are planned with the report and panel setup checked as part of the change.
- Ongoing support and continuous testing are available as retainers, with scope and terms agreed in writing.
