Sharing EspoCRM reports with portal users

When sharing EspoCRM reports with portal users makes sense

A team often wants customers or partners to see their own pipeline, ticket or account figures without giving them a login to the internal CRM. In EspoCRM, that goal points toward the portal, where an external user signs in with a portal role and sees only the records tied to their account. Reports from the Advanced Pack can be made available to those portal users, so the same report definitions your staff use can serve an external audience, provided the data behind them is scoped correctly. The decision is less about whether the feature exists and more about whether your customer-facing figures can be expressed as report results limited to one account.

Before committing, confirm in your specific EspoCRM version how portal access to reports is enabled, which portal roles can see which reports, and how account-scoped data is enforced on the underlying entities. The Advanced Pack page describes the reporting extension and its inclusion in the cloud plans, but the exact portal permission model should be tested with a non-admin portal user in a staging instance. Check that report filters cannot be edited by the portal user to widen the result set, and that related entities such as contacts, tickets or opportunities do not expose records from other accounts through linked fields.

A different approach fits better when the audience needs formatted documents on a fixed cadence, when figures must be frozen at a point in time for a contract or invoice, or when customers need analytical drill-down that a BI tool handles more naturally. Exported PDFs or scheduled report emails can cover the first two cases with less access exposure. A separate BI tool with its own row-level security can suit the third. Many teams combine approaches, keeping portal reports for light, live status views and sending periodic summaries through other channels.

Which portal access model fits your customers or partners

Customers who log in to the portal should see reports limited to their own account. The data scope is the account they are linked to and the records that hang off it, such as their open cases, orders or service history. Before you share any report, confirm that the portal role grants read access only to the specific reports needed and nothing that exposes internal users, other accounts or unrelated entities.

Scope: Reports return only records tied to the customer's account, so the account link must be correct before anything is published.
Role to confirm: Use a dedicated portal role with read-only access to the named reports, with no access to internal user lists or team data.
Account link: Verify that each portal user is linked to exactly one account, since a second link silently widens what they see.
Main risk: A report built on a broad entity, such as all opportunities, shows other customers' names and amounts if the account filter is missing or misapplied.

Test the setup by logging in as a portal user for two different accounts and confirming that neither can see the other's rows, including through report filters and exported files.

How to configure portal report access step by step

This sequence turns on the EspoCRM portal, shares only the reports each customer or partner needs, and confirms through testing that a portal user sees nothing outside their own account. Each step closes with a check, so the access design is verified before any external user signs in.

Enable the portal
An administrator turns on the portal in the EspoCRM administration area, creates the portal record and sets its URL and default options. Confirm the exact menu labels and portal settings in your EspoCRM version, because they can change between releases. Done when you open the portal URL in a private browser window and the portal login page loads without signing in to the main CRM. If it does not load, check the portal domain and web server routing with the team that runs your hosting.
Confirm reports are available to portal users
The Advanced Pack provides reports and is included in all EspoCRM Cloud plans, according to the EspoCRM pricing page. On a self-hosted instance, confirm the extension is installed and licensed for your use. Then have an administrator confirm that each report you plan to share runs without errors and is built on the entity the portal user needs, for example Opportunity or Case as illustrative choices. Done when the test reports run for an administrator.
Create the portal role with report permissions
In the administration area, create a portal role for each customer or partner group and grant access only to the entities and reports that group needs. Set record access to the narrowest level your version supports for portal roles, and keep administrative and global permissions switched off. Save the role and reopen it to confirm the settings were stored. Done when a reviewer can list the role's entity and report permissions and each line matches the written access design.
Link each portal user to the correct account
Create or edit the portal user, link it to the customer account it should see, connect it to the matching contact, and assign the portal role from the previous step. Account-based scope depends on these links, so a missing or wrong link is the first thing to check when results look empty or too broad. Done when the user's record shows the intended account and role, and the account's contacts show the linked person.
Check report filters limit data to the account
Open each shared report and confirm it limits rows to the portal user's account, either through the access scope the report uses or through a filter tied to the account link. Reports that total or group across all accounts can expose figures from other customers even when detail rows are hidden, so review charts, totals and grid headers as well. Done when the reviewer can name, for each report, the field or scope that limits the rows.
Test with a sample portal user
Create a sample portal user linked to a test account that has records, then sign in through a private browser window and open each shared report. Confirm that only records for that account appear, and try to open a record belonging to another account using its direct link to confirm access is refused. Repeat with a second test account and a different portal role. Done when no records or totals from another account appear in any report or record view. Run this test again after every role or report change.

Security risks when reports reach outside users

Portal users sit outside your workforce, so every report you expose to them becomes part of your attack surface. The risks below connect through one question: what can a portal user see, from where, and under which login controls. Each card names a check you can run in your own instance before go-live.

Report scope wider than the account filter

A report can return records that a portal user should never see, even when the portal role looks restrictive. The report's own filters, selected columns and joined entities are evaluated separately from the record-level limits you set on the role. Build a test portal user for each customer type, open every report and export it, then compare the rows and columns against what that customer should see. Confirm the result by running the same report as a second portal user from a different account.

Reports built on internal fields

Fields such as internal notes, margin, discount approvals or owner comments often sit on the same entities as customer-facing data. A report that includes them, even in a column the portal layout hides, can still expose the values through export or a filter that reveals them indirectly. Review each report's field list against the portal user's field access, and remove any field that is only needed by staff. Ask the person who owns the report to justify every column in writing.

Shared admin accounts behind portal access

Teams sometimes share one administrator login to publish reports, test portal views or troubleshoot a customer's complaint. That login then controls the portal setup, can change roles and can read everything the portal reports expose. EspoCRM's security guidance recommends avoiding admin accounts for daily work, so give each builder a named staff account with only the rights their task needs. Check the admin user list for shared or generic names and confirm each admin has a single accountable owner.

Missing two-factor and password policy

Portal users are often customers who choose weak passwords, reuse credentials from other sites and never see a policy prompt. Once an account reaches a report with customer or partner pricing, it becomes a valuable target. EspoCRM's security guidance recommends enforcing a password policy and requiring two-factor authentication, and it also advises disabling password recovery for admins. Confirm these settings apply to portal users as well as staff, then test a weak password and a login without a second factor to see that both are rejected.

IP restrictions and session lifetime

Portal logins from unknown networks and long-lived sessions widen the window in which a stolen token or shared computer can reach report data. The security guidance recommends limiting authentication token lifetime and restricting access by IP address where your user base allows it. Partners often connect from fixed office ranges, while customers may not, so decide per portal which access pattern you can support. Verify the setting by signing in from an address outside the allowlist and confirming the request fails, and by checking that an expired session requires a fresh login.

Questions teams ask before sharing reports in the portal

What does the setup effort for portal reports depend on?

The effort depends mostly on how many portal roles you need, how cleanly your data already links to customer or partner accounts, and how many reports and panels each audience should see. Each report also needs its filters checked against the portal user's account, so a report built for internal users may need rework before a portal user can see it safely. Teams with a short list of audiences and clean account links usually finish faster than teams that must restructure records first. Ask any partner to base the estimate on a written list of roles, reports and data links.

Can our internal team set up portal reports without outside help?

Yes, if at least one administrator is comfortable with EspoCRM roles, portal settings and the Advanced Pack reporting tools, and has time to test each audience. The work is configuration rather than custom code in most cases, but mistakes in account-scoped access are easy to miss without a structured test pass. Outside help is most useful for designing the role model, reviewing data exposure before launch and writing a repeatable test script. Decide which part you will own before you start, and who signs off on what a portal user can see.

What does the Advanced Pack licensing mean for portal use?

The EspoCRM pricing page states that the Advanced Pack is included in all EspoCRM Cloud plans. It also states that the open-source edition can be downloaded and self-hosted for free. Because the reports features come from the Advanced Pack, a self-hosted deployment needs that extension installed and licensed under your own arrangement. Confirm with EspoCRM which licensing applies to your deployment model and how it treats portal users before you commit to a design, since the pricing page does not describe portal licensing in detail.

What should a partner quote include for portal reports?

A useful quote lists the scope in writing before work begins. It should name the portal roles, the reports and dashboards each role can see, the account-scoping rules, the environments used for testing, and the data you must provide. It should also separate one-time work, such as role design and build, from recurring work, such as upgrades and ongoing support, and state what is excluded. Ask how testing is counted, whether migration of existing portal users is included and how changes requested after sign-off are handled.

How long does testing take as the number of portal roles grows?

Testing time grows with the number of portal roles and the number of reports each role can reach, because every role-and-report pair is a potential data exposure path. A small set of roles with one account per audience can be checked in a short cycle, while a larger set needs test accounts for each role, a documented expected-results list and a repeat pass after every change. Ask for the test plan and its coverage rules in the quote, and confirm whether the plan covers both the portal interface and any direct API access.

What should we confirm with EspoCRM for our version before sharing reports?

Start by confirming the EspoCRM version you run, the Advanced Pack version that matches it and the portal settings and role options available in that release. Check the EspoCRM security documentation for recommended controls such as enforcing a password policy, requiring two-factor authentication where applicable, limiting token lifetime and restricting access by IP address. Also confirm how report access is evaluated for portal users, since behavior can differ between releases. Record the answers in your design document so the team can recheck them at each upgrade.

How do we stop portal users from seeing other customers' data in reports?

Limit each portal user to records linked to their own account, and test that link from the report output rather than from the list view alone. Set portal roles so that only the reports and fields a customer needs are available, and do not reuse internal reports without reviewing their filters. Run each test with a dedicated account for every audience, and include negative tests that try to reach another account's records. Ask your implementation partner to show the test script and results before go-live.

Limits to confirm in your environment before launch

Portal report access depends on the EspoCRM version you run, how your data model links customers to accounts, the volume of records behind each report, and how the portal is reached over the network. Confirm each of these in a staging instance built the way production will be built, because a report that works for an internal user can behave differently for a portal user.

Report type exposure in your version

Not every report type should be assumed to be available to portal users. Check, in the exact EspoCRM version and Advanced Pack version you plan to run, whether list, grid and joint grid reports can be granted through portal roles and whether each type appears in the portal navigation. Record the result per report type, and retest after every minor release because the Advanced Pack and core permissions evolve together. A missing report type discovered after launch usually means a redesign of the dashboard or a rollback for customers who have already been promised access.

Account-scoped filters across linked entities

Portal users usually see only records tied to their account, but reports often join opportunities, cases, contacts and custom entities. Test whether an account-scoped filter holds when a report reaches through a relationship, for example from a case to a contact to an account, and whether a user linked to two accounts sees the union you intend. Use two test portal users in different accounts and compare every row count against an internal report. Any row that leaks across accounts is a release blocker, not a tuning task.

Result behavior at large volumes

Report results can slow down or time out as the number of linked records grows, and portal users tend to run reports more often than expected. Load a copy of production-scale data into staging, then measure how long the slowest portal report takes to render and how many rows a portal user can export. Ask whether indexes on the fields used in filters are in place and who owns index changes after go-live. Agree a row or time threshold up front so the decision to restrict a report is based on evidence.

Portal domain and TLS configuration

Portal access runs on its own domain or path, and that domain needs its own certificate, reverse proxy rules and firewall policy. Confirm how the portal hostname resolves, which certificate authority issues it, and how the reverse proxy passes headers so that sessions and the login redirect work correctly. Test expiry and renewal, since a lapsed certificate blocks every external customer at once. Check whether your web server and TLS settings match the installation method you chose, because the supported web servers and PHP versions are listed in the server configuration docs.

IP restriction and admin exposure

Portal users reach the same application server as your staff, so network controls decide who can reach the login page at all. Decide whether the portal should be open to the internet or limited by IP allowlist for specific partner networks, and confirm that admin paths are not exposed on the portal hostname. Review whether the security settings in your version can restrict access by IP address for the portal role without blocking internal users. Document the decision, because a change to the network path later can silently expose administrative screens.

Background jobs for report refresh

Some report data and scheduled deliveries depend on background jobs run by cron or a scheduled task. If portal dashboards or reports depend on refreshed data, confirm that the scheduled job runs on the production host, that failures are logged, and that someone receives an alert when it stops. A stalled job often looks like a correct report with stale numbers, which customers may act on before anyone notices. Ask your provider to show the job status on the portal test instance during acceptance testing.

Trade-offs between portal reports and other sharing methods

Choose a sharing method by deciding how much control you need over the data each external reader sees and how often that data changes. A live portal report keeps the customer or partner inside EspoCRM, so the data they see is evaluated against their portal role and account at the moment they open it. Changes to fields, layouts or role permissions take effect without another delivery step, but every change to the portal role or report definition is also a change the customer experiences immediately. Scheduled report emails to external recipients work differently: the report is generated and sent on a timer, and the recipient keeps a copy outside EspoCRM. Access rules for those recipients need to be confirmed in the email sending settings for your version, because a copy in an inbox cannot be revoked the way a portal login can. Exporting data to a separate tool, such as a spreadsheet or a BI product, gives the widest control over presentation and the weakest control over scope, since the exported file is only as restricted as whoever prepared it.

Maintenance effort follows the same pattern. With portal reports, the work sits in the configuration: each time a field is renamed, a status is added or a role is restricted, someone must check that the report, the portal role and the account-scoping rules still return the intended rows. Emailed reports add a second place to check, because the report definition and the recipient list must both stay correct. Exported data moves the burden to the people who maintain the export, and any change in the source fields can silently break downstream formulas. Ask your implementation partner or internal admin to list every report shared externally, with its portal role or recipient list, so that a field change triggers a review of each one.

Audit and support work also differ. Portal access is tied to named portal users, so a access review can answer who could see what, and a support request can be reproduced by logging in as the same role in a test environment. Scheduled emails leave a trail in the mail logs, but they do not show whether the recipient forwarded the report, so the audit question becomes one of recipient governance. Exports are the hardest to evidence once they leave the platform. Before choosing, confirm with your auditors which of these trails they will accept, and record the decision for each report type in your access documentation.

Portal report configuration options and when each fits

This table compares four ways to share EspoCRM reports with external users, from read-only report access to separate reporting for partner groups. Read each row against your audience, your data sensitivity and how much maintenance your team can carry, then check the risk column before choosing. Most deployments combine two options, so treat the rows as building blocks rather than alternatives.

Option	What it needs	Main risk	When it fits
Portal role with read-only report access	A portal role that allows viewing the specific reports, and portal users assigned to it	Reports that expose more records than intended if the underlying scope is broader than the portal role allows	Customers who need to check a fixed set of status or summary reports
Portal role with reports limited to the account	Account-scoped permissions on the reported entities, and reports built on fields that tie records to the portal user's account	A report filter that is missing or misconfigured can show other customers' data, so testing with several test accounts is essential	Customers who each see only their own orders, cases or opportunities in shared reporting
Scheduled report emails to portal contacts	Scheduled report sending configured for the right recipients, plus a clear list of who receives each report	Emails leave the portal and can be forwarded, so sensitive figures may spread beyond the intended contact	Recurring summaries for external contacts where a weekly digest is enough and live portal access is not needed
Separate reporting for partner groups	Teams or accounts per partner group, a shared report design scoped per group, and a named owner for each group's access	Higher administrative load as partner groups change, and the risk of one group's data leaking through a shared team	Partner programs where partners are grouped by territory or channel and must not see each other's pipeline

How DeployOpen scopes and delivers portal report access

We start by agreeing in writing which reports, portal roles and account boundaries customers or partners will see, then build and test that access before anything reaches live users. The result is a documented setup your team can review, change and run after handover.

How we scope

Inventory every report you plan to share with portal users and the data each one reads.
Define portal roles and which account-level records each portal user may see.
Agree in writing which reports, roles and test cases the fixed scope covers before work starts.

How we build

Configure portal access to reports and role permissions on a non-production EspoCRM instance first.
Test each portal user type with sample accounts to confirm they see only their own account data.
Check that internal reports and admin-only fields stay hidden from portal logins during testing.

How we hand over

Document the portal roles, report permissions and account-scoping rules in a handover pack your team can audit.
Walk your administrators through how to add a portal user and review what that user can access.
Record the test cases used and their results so your team can repeat them after later changes.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retested portal access after EspoCRM upgrades, new reports or changes to your portal roles.
Ask us to confirm scope, deliverables and timelines in writing before any work begins.