Why EspoCRM dashboards for sales and support need a design before they need widgets
A team lead wants a sales rep and a support agent to land on the screens they actually use at first login, not a generic home page they must rearrange. In EspoCRM, that outcome is a design decision made before anyone adds a widget. A dashboard is the home screen a user sees, made up of *dashlets*, which are the individual panels such as a list of open opportunities, a chart, or a list of cases waiting for a reply. A *tab* is a separate dashboard page a user can switch between. Each of these can be set for one user, but the reason to design them is that sales and support work from different queues, different records and different targets, so one shared home screen serves neither group well.
Role-specific dashboards pay off when a team has several distinct jobs that share one CRM. A sales manager needs pipeline totals and deals closing this month, a sales rep needs their own open opportunities and follow-ups, and a support agent needs cases that are unassigned or approaching a response deadline. Before building anything, list the three or four questions each role asks every day and map each question to one dashlet. Decide which tabs group those dashlets and which role should see each tab. Many of the dashlets that show numbers or charts display the results of reports, and in EspoCRM those reports come from the Advanced Pack. Confirm that the Advanced Pack is installed and that each role can see the reports a dashlet depends on, because a dashlet that cannot read its report will not show useful data.
Dashboard options and when each one fits
This table compares the main ways to build EspoCRM dashboards: report-based charts, record lists, calendar and activity feeds, tab-based dashboards, shared default layouts and per-user layouts. Read each row for the team it suits and the upkeep it creates. The main takeaway is that shared layouts are cheap to maintain but leave users free to drift, while per-user layouts give control at the cost of ongoing admin effort.
| Option | Best fit | Maintenance and access trade-off |
|---|---|---|
| Report-based chart dashlet | Sales managers tracking pipeline by stage, owner or month | Depends on report permissions; a chart shows only what the viewer can read, so confirm access for each role before rollout |
| Record list dashlet | Support agents watching their open cases or overdue tickets | Filters must be updated when statuses or queues change; broad lists can surface records a role should not see |
| Calendar and activity feed dashlet | Account executives and support leads checking meetings and recent actions | Low setup effort, but feeds reflect each user's own visibility, so results differ between roles |
| Tab-based dashboard | Teams that switch between daily work and management views | Each tab adds layouts to maintain; keep tabs few and name them by the task they serve |
| Shared default layout for new users | Onboarding sales reps or support agents into one standard view | One update reaches new users, but existing users keep their current layout unless you reset it |
| Per-user layout | Senior staff or managers with distinct needs | Most flexible, but admin edits to a user's dashboard need a clear policy and an audit of who changed what |
| Locked dashboard | Management views that must stay consistent across a team | Users cannot rearrange it, which reduces drift; confirm the locking setting matches your admin model before relying on it |
How sales and support need different dashboards
Sales managers use a dashboard to see whether the team will hit its number and where deals are stalling. The questions are usually about pipeline coverage by stage, forecast against target, deals that have not moved in a set period, and win rates by owner or team. These answers come from grid reports on opportunities grouped by stage, owner and close month, and from joint grid reports that compare actuals with targets. Managers typically need team-wide visibility, so their dashboard should draw on reports scoped to their team rather than on single records.
- Pipeline by stage and owner: a grid report that shows open value per stage, split by owner, so gaps in coverage are visible at a glance.
- Forecast against target: a joint grid report or chart that compares closed and forecast amounts with the targets set for each period.
- Stalled deals: a list view of opportunities with no recent activity, sorted by value, to prompt follow-up.
- Data to exclude: commission fields, other teams' accounts and personal contact details outside the manager's team.
Before you publish the layout, confirm that the manager role can see the reports and the underlying records it depends on, and that the team scope matches your reporting hierarchy.
Account executives work from their own book of business. Their dashboard should answer what needs attention today: which deals are closing, which follow-up tasks are overdue, and which accounts have had no contact recently. Because each executive should see only records they own or are assigned to, the dashboard depends on ownership rules and team assignments in the role, not on the layout alone. Keep the content short, since the rep will open this screen many times a day.
- Today's tasks: a list of overdue and due-today tasks filtered to the logged-in user.
- Deals closing this month: a list view of the rep's open opportunities with a close date in the current period.
- Accounts without recent contact: a list of owned accounts with no logged activity in a defined window.
- Data to exclude: other reps' pipelines, team-level totals and any revenue fields the role is not meant to read.
Check that the executive role's record-level access matches the ownership model, and test the dashboard by signing in as a sample rep account before rollout.
Support agents need to know which cases need an answer first and which customers are waiting. Their dashboard should focus on queue state, ageing and ownership, and should not show sales pipeline or commercial terms. Team leads need a different view on the same data, covering backlog by priority and time to first response, so the support dashboard for leads should be separate from the one for agents. Case visibility also has to respect team assignments so that agents do not see unrelated queues.
- My open cases: a list of cases assigned to the agent, sorted by priority and last customer update.
- Unassigned queue: a list of new cases in the team queue that no one has picked up.
- Ageing by priority: a grid or chart of open cases grouped by priority and age band, for leads.
- Data to exclude: sales opportunities, contract values and cases outside the agent's team.
Confirm that case visibility matches your queue design and that agents cannot reach lead-level reports through direct links.
Layout decisions and data access are separate controls, so a dashboard can look correct while still exposing records. A useful approach is to define the role first, then choose which reports and dashlets that role may use, and only then arrange the screen. Default layouts for new users save setup time, but they must be reviewed for each role because a copied layout may carry panels from another team. Document which items are fixed for each role, since this makes later changes easier to review.
- Role first: settle role permissions and team scope before building any dashboard panel.
- Default layouts per role: prepare one layout per role so new users start with the right panels.
- Report access: check that each report is visible to the roles that place it on a dashboard.
- Data to exclude: fields and records the role should not read, even if a panel could technically display them.
Ask your implementation partner or administrator to confirm, in your own instance, which dashboard items each role can see when signed in as a test user.
How to set up role-specific dashboards in EspoCRM
This sequence produces dashboards that each role can open and rely on. Every step closes with a check that confirms the dashboard shows only the data that role is permitted to see. Work through the steps in order, because each later step depends on the roles, reports and permissions set up before it.
Confirm roles, teams and visible data
The administrator and the business owner of each team agree on which roles exist, which teams they belong to, and which records each role may read. Write this down as a short matrix of role, team and scope before anyone builds a dashboard. Dashlets only show what the underlying role allows, so an unclear permission model will produce dashboards that look correct in a demo and leak data in production. Done means the matrix is signed off and every role has a named owner who can confirm it.
Build or confirm the reports behind each dashlet
For each dashlet, decide whether it will read an existing report or a new one built with the Advanced Pack reporting features. Create or review the report and check its filters, grouping and the entity scope it reads. Run each report as a test user from each restricted role and compare the counts with the expected values from the matrix. Done means every report returns only the records its intended audience should see, and no report depends on a filter that a user could remove.
Create tabs and add dashlets per role
Create one dashboard tab for each role or role group, then place the dashlets that the report work produced onto those tabs. Keep sales pipeline views and support queue views on separate tabs so each role opens to its own work. Confirm the exact tab and dashlet options available in your EspoCRM version before you finalize the layout. Done means each tab renders every dashlet without an error, and each dashlet shows the expected data when viewed as a user from that role.
Set the default layout for new users
Configure the default dashboard layout that new users receive when their account is created, so a new salesperson or agent starts with the right tabs and dashlets. Check in your version how default layouts are assigned and whether they apply per role. Create a test user in each role and confirm that its first login shows the intended layout. Done means each new test account opens to the correct default dashboard without any manual changes by an administrator.
Test with a representative user per role
Sign in as a representative user for each role, ideally someone who holds a realistic workload and team membership, and walk through every tab. Compare each dashlet against the expected results from the matrix, paying attention to records owned by other teams or other users. Repeat the test after any permission change. Done means each representative user sees only permitted data, and any gap has been fixed and retested with the same user.
Lock dashboards or allow personal edits
Decide whether users may change their own dashboards or whether the administrator controls the layout. Confirm in your version whether layouts can be locked for a role and whether administrators can edit a user's dashboard directly. Apply the decision to the test users and verify that the allowed actions work and the blocked ones do not. Done means the setting matches the agreed governance model, and a user who is not permitted to edit the layout cannot change it.
When to lock dashboards and when to let users edit them
Lock dashboards for any view that must mean the same thing to everyone in a role, and let users edit only where personal layout genuinely helps their work. A locked, standard dashboard for a sales team means every manager sees the same pipeline dashlets, the same stage definitions and the same support queue counts, which makes weekly reviews comparable. An editable dashboard lets a rep pin a personal task list or a support agent move a queue widget to the top, but each added widget is a new chance for a report to be filtered differently from the one a manager is reading. Decide per role, not for the whole instance, and write the decision down before you build the default layouts.
Administrators can change a user's dashboard in EspoCRM, so the policy must cover that as well as the user's own edits. Confirm in your running version which admin screen or user record action exposes the dashboard layout for another user, which settings control whether users may add, remove or rearrange dashlets, and whether a lock applies to the default layout only or to the saved layout too. Test each control with a non-admin test account in your own role set. Treat these exact control names and locations as items to verify in the running version rather than as settled facts.
The main risk is a change the user does not know about. If an administrator adjusts someone's dashboard during troubleshooting, that user may later report a missing widget or a wrong number without any record of who changed the layout or why. Set a change policy that states who may edit another user's dashboard, that the user is told when it happens, and how the original default is restored. Keep a short change log outside EspoCRM, reviewed when a role's standard changes. Confirm how your version records dashboard edits in the audit or stream history before you rely on it.
Access and data exposure risks in shared dashboards
Dashboards look like a presentation layer, but each dashlet is a query running under someone's permissions, and each report behind it is a data source. The risks below come from the points where a dashboard design meets role permissions, personal edits, admin sessions and organizational change.
Dashlets showing records users cannot open
A dashlet can list records a user's role does not allow them to open, so the sales lead sees a name and amount on the dashboard but gets an access error on click, or worse, sees fields the record view hides. Check each dashlet against the role that will see it, not against the admin account used to build it. Test with a non-admin user from each role before rollout, and confirm that the records shown in the dashlet match what that user can view in the list and detail screens.
Admin-built reports exposing data
A report built by an administrator and placed on a sales or support dashboard can aggregate data the viewing role would never see in list form, such as totals across all owners or the full account pipeline. Before publishing a report to a dashboard, confirm which teams and roles can see its source entity and whether the aggregate reveals individual records. Where a report is for managers only, place it on a dashboard assigned to that role and keep it out of shared layouts.
Personal edits bypassing the design
Users can often change their own dashboard layout, which is useful but can add dashlets the design team never reviewed, including reports that expose more data. Decide which roles may edit their own dashboards and which dashboards should be locked for the team. Review personal layouts after go-live for dashlets that point at sensitive entities, and confirm the setting that controls personal editing in your version before you promise users a fixed layout.
Admin accounts used for daily work
When an administrator edits dashboards from a daily working account, every layout change and dashlet test runs with full permissions, so mistakes look correct to the admin and fail silently for everyone else. The EspoCRM security docs advise against using admin accounts for daily work. Give administrators a separate account for configuration, and test dashboards from standard role accounts, so the access results reflect what sales and support staff will see.
Stale dashboards after role changes
Dashboards built for a support team can outlive a reorganization, leaving former team members with dashlets that show another team's queue or leaving new hires with empty layouts. Each team change, role change or departure should trigger a dashboard review. Ask your administrator to list which dashboards are assigned to each role and team, and to confirm that default layouts for new users match the current org chart before onboarding.
Limits to confirm before you commit to a dashboard design
Which dashlet types does my EspoCRM version offer?
The available dashlet types depend on the EspoCRM version you run and on the extensions you install, so confirm the list on your own version before you design around a specific widget. Open the dashboard configuration screen on a test instance built from the same release you plan to deploy, and check it against the official documentation for that version. Pay particular attention to chart and report dashlets, since those depend on reports and may depend on the Advanced Pack. Note the exact version you tested, because EspoCRM 10.0.0 was released on July 2, 2026 and several 10.0.x releases followed, and a feature list written for an earlier major version may not match. Ask your implementation partner to show the dashlet list in writing during the design review, and file it with the design document so later upgrades can be checked against it.
Do default dashboard layouts apply to existing users?
Test this on a copy of your instance before you rely on it, because the answer decides how you roll out a new layout. Whether an existing user who already has a saved dashboard receives a changed default is a behavior to verify, not assume. Create a test user with a customized dashboard, change the default layout in the administration area, and log in as that user to see what appears. Repeat the test with a user who has never opened the dashboard. Record which case applies to each, and note whether a manual reset is needed to bring a user onto the new layout. Include this test in the design work, since a wrong assumption means sales or support staff open an unexpected screen on the first day after a change.
How do upgrades affect customized dashboards?
Upgrades can change or overwrite layout settings, so treat dashboard checks as part of every upgrade test. EspoCRM 10.0 disables upgrading through the UI by default, so your administrators will run the upgrade through the command line process, and the dashboard checks belong in that runbook. Before any upgrade, document the default layouts, locked dashboards, admin-edited user dashboards and any extension that adds dashlets. Run the upgrade on a copy of production, then compare each role's dashboard with the saved record. Read the release notes for your target version to see which dashboard settings carry over and which need recreation. Ask your partner for an upgrade checklist that names dashboards explicitly, and keep it with the design document. EspoCRM releases lists the versions to review.
How many reports can a dashboard load before it slows down?
No threshold is documented in the sources available for this page, so measure it on your own data and hardware. Load time depends on how many reports render at once, how many records each report scans, the filters applied, the database engine, and the PHP and cron configuration on the server. Start with a dashboard that loads only the reports each role needs, then add dashlets one at a time and time the page on a copy loaded with production-sized data. Use the browser's network tools to find the slowest requests. Test on the database version you run, since EspoCRM supports MySQL, MariaDB and PostgreSQL. Agree a load-time target with the business owners before testing, so the result becomes a decision everyone accepts.
Does the Advanced Pack need to be installed for each dashlet?
Not every dashlet needs it, but any dashlet built on reports depends on the Advanced Pack, so check each planned dashlet against the extension page. The Advanced Pack provides reports, Business Process Management and workflows, and it is included in all EspoCRM Cloud plans. For a self-hosted installation, confirm how the Advanced Pack is obtained and licensed on the extension page before you cost the design. Build a matrix in your design document that lists each planned dashlet, its data source, and whether it relies on reports. Then check that matrix on a test instance without the Advanced Pack installed to see which dashlets fail. Ask your partner to include this check in the written scope. Advanced Pack describes what it adds.
Who pays for dashboard design, and what recurs afterward?
Most of the design cost is staff time: interviewing each role, building test users, and checking behavior after every change and upgrade. If your own team does the work, the cost is internal time. If a partner does it, the fee should follow the written scope, which should list the roles, dashlets, reports and test cases. Licensing is a separate line. The open-source edition can be downloaded and self-hosted for free under AGPL-3.0, while EspoCRM Cloud charges per user per month on its listed plans, with the Advanced Pack included in those plans. Recurring work includes rechecking dashboards after upgrades and updating reports when fields change. Ask any provider to separate one-time design work from ongoing upgrade checks. EspoCRM pricing lists the cloud plans.
What a dashboard project needs from your team
The work starts with four inputs from your side: a written list of roles (for example, sales representative, sales manager, support agent and support lead), the metrics each role reviews every day or week, a set of sample users you can use to test what each role sees, and a decision on who may change dashboards after go-live. Without the role list, there is no basis for choosing dashlets, and without the metric list, the reports behind those dashlets cannot be scoped. The sample users matter more than most teams expect, because a dashboard that looks right to an administrator can show different records once it is viewed through a sales or support role. Confirm the sample users and their team memberships before the build starts.
The editing policy is the input most often left open. You need to decide whether users may rearrange their own dashboards, whether administrators may edit a user's dashboard on their behalf, and whether certain dashboards should be locked so every member of a team sees the same layout. Each choice affects who maintains the layouts later and how much support traffic follows a change. Ask your EspoCRM administrator to confirm which of these settings the version you run exposes, since dashboard behavior has changed across releases and should be checked on your own instance rather than assumed from this page.
Effort depends mainly on the number of roles and on the reports behind them. An internal administrator with working knowledge of EspoCRM can usually build a simple layout for one or two roles that rely on existing list views and a few standard dashlets. Multi-role designs that share some dashlets, filter others by team, and depend on custom reports need more design time, more testing with sample users and more review rounds with the business owners. Ask any partner for a quote that lists the roles, the number of dashboards and dashlets per role, the reports to be built or reviewed, and the number of test cycles included.
Questions buyers ask about EspoCRM dashboard design
What drives the cost of an EspoCRM dashboard project?
The main driver is how many roles need their own dashboard and how much each one depends on reports, custom fields or custom entities. A design for two roles that use standard fields is a small piece of work. A design for sales, support, managers and customer-facing staff, each with dashlets built from custom reports and linked to layouts and access rules, takes more discovery and more testing. Other cost drivers are the number of stakeholder reviews, how much existing dashboard content must be rebuilt, and whether the Advanced Pack reports the dashboards depend on are already designed. Ask any quote to list each role, each dashlet and the testing approach separately.
How long does a role-based EspoCRM dashboard design take?
No researched duration is available for this work, so confirm the timeline against a written scope rather than a general estimate. The period depends on the number of roles, the number of reports behind each dashboard, how many sign-off rounds your managers need, and whether the reports still have to be built. Ask for the planned stages (discovery, design, build, testing and rollout) with the decision points each one needs from your side, and check how the plan handles delays in data quality or report design.
Can our own team design EspoCRM dashboards without a partner?
Yes, many teams can, because dashboards are configured through the EspoCRM interface and the administrator can set default layouts and tabs. The work becomes harder when the design depends on Advanced Pack reports, custom entities or formula-driven fields, and when the same dashboard must match role permissions for several teams. Decide who owns the role matrix, who signs off on each user's view, and who will update dashboards after a new hire or reorganization. A partner is most useful when those ownership questions are unresolved or the team lacks time to test each role.
What do we need to provide before dashboard work starts?
You need named business owners for sales and support, a list of roles with their actual data access, and examples of the decisions each dashboard should support. Provide the existing EspoCRM instance details, including version, extensions and any custom entities, and confirm whether the Advanced Pack is installed. Access to a test environment helps, as does a sample of records that reflects real pipeline and case volumes. Without these inputs, dashboard designs tend to show metrics that managers do not use.
Can administrators change a user's dashboard, and what happens to it?
Administrators can edit the dashboards of individual users, and EspoCRM also supports locking dashboards so users cannot change them. Confirm the exact behavior in the version you run, because admin edits and locks affect how new users inherit defaults and how later role changes appear. Plan a rule for when admins may override a personal dashboard, record that rule, and review locked dashboards during each access review so they do not drift from the approved design.
How do dashboards change during an EspoCRM upgrade?
Dashboards depend on layouts, reports and extension features, so an upgrade can change how they render or behave. EspoCRM 10.0.0 was released on July 2, 2026, and the EspoCRM upgrade docs should be read before any move. Check that every dashlet, report and tab still works in a staging copy, confirm extension compatibility, and compare default layouts for new users. Restore a backup if a dashboard fails validation. Upgrading through the UI is disabled by default as of version 10.0, so plan the command-line process as part of the test.
What do we need to check after the dashboards go live?
Check that each role sees the intended dashlets, that reports return the expected totals, and that new users receive the correct default layout. Review scheduled report emails and report-based panels if they feed the dashboards, and confirm that data permissions hide records outside each user's scope. Ask for a documented test script and a named owner who reviews dashboards after each role change or EspoCRM upgrade.
How DeployOpen works on this
DeployOpen starts with a written scope that names the roles, dashboard tabs, dashlets and admin controls for your sales and support teams. We then build, test and document the dashboard design inside your own EspoCRM instance, so the setup stays under your control after handover.
How we scope
- Inventory the roles that need dashboards, such as sales reps, sales managers, support agents and team leads
- Agree which dashlets, tabs and report sources each role sees, written into the scope before work starts
- Confirm whether dashboard locking and admin edits of user dashboards match your change control rules
- Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before the build
How we build
- Configure default dashboard layouts for new users in a test instance that mirrors your roles and teams
- Check each dashlet against the access rules of its role so no user sees records outside their permissions
- Test dashboards with a representative user from each role and record the results for review
- Keep configuration changes traceable so each dashboard can be rebuilt or reviewed later
How we hand over
- Document the dashboard design per role, including tabs, dashlets, default layouts and who may edit them
- Walk through the admin procedure for locking dashboards and editing a user's dashboard
- Deliver a change log of configuration made in the instance and the reports each dashlet depends on
- Agree with your team who owns future dashboard changes after handover
How we support
- Ongoing support, upgrades and continuous testing are available as retainers
- Retainers can cover dashboard changes when teams add roles, reports or EspoCRM upgrades
- Ask any support provider to confirm how dashboard changes are tested before they reach production
- Retainer scope and response expectations are set in writing, not assumed
