Teams often use the word “shared” to mean several different things. A dashboard may have one shared name, layout, and set of report definitions. A copied URL lets another authenticated teammate navigate to it, but it does not cross the workspace boundary or grant administrator configuration rights. Keeping those guarantees explicit makes shared reporting predictable.
Intelligent CRM separates those concerns. Dashboard and report documents belong to one team. Authenticated users in that team can list and open them, while administrator middleware protects creation, updates, deletion, report changes, and layout persistence. When a CRM report runs, the backend applies the authenticated team boundary and then adds the saved report filters. The author’s identity does not create a separate data scope.
This guide explains that model in practical terms: which actions are administrative, how the shared workspace population is applied, why Tasks remain personal, why OR logic cannot cross the team boundary, what a shared URL does, and how to test dashboards with representative roles. The result is a reporting workspace with shared CRM numbers, personal inbox metrics, and strict tenant isolation.
Separate dashboard capabilities into four permission layers
Each layer answers a different governance question and should be tested independently.
| Layer | What is shared | Who can act | What it does not grant |
|---|---|---|---|
| Definition viewing | Dashboard name, description, cards, and saved report configuration | Authenticated teammates in the same team | Access to records outside the workspace |
| Configuration | Create, edit, duplicate, reorder, resize, and delete operations | Workspace administrators | A permanent bypass around report validation or data access |
| Data execution | Validated calculation for the saved definition | An authenticated teammate requesting the report | Data from another workspace |
| Link sharing | A route to the team-scoped dashboard | A teammate who already has valid authentication | Authentication, cross-team access, admin rights, or hidden records |
Treat dashboard definitions as team-scoped configuration
A saved dashboard stores its team, name, description, creator, updater, version, and timestamps. Reports live as separately versioned documents connected to that dashboard and store source, type, metric, grouping, segmentation, filters, filter logic, date range, visualization, target, pipeline or status selections, and layout. Keeping reports separate lets configuration and layout changes use optimistic versions rather than turning a dashboard into one unstructured payload. Team identifiers keep similarly named dashboards in different workspaces isolated.
Authenticated teammates can list dashboards and retrieve a dashboard in their own team. That makes a common operational vocabulary possible: “Pipeline review” can refer to one definition rather than several privately rebuilt cards. The shared object is still configuration, not a cache of results. Report data is loaded through a separate endpoint, and previews also run as the requesting user. A definition can therefore be stable while the authorized population and current values change.
Reserve report and dashboard configuration for administrators
The backend applies administrator authorization to dashboard creation, update, and deletion, and to report creation, update, and deletion. This includes changes that appear primarily presentational, such as saved layout or width, because they modify a team-wide resource. Report duplication ultimately creates another saved report and is therefore an administrative configuration action. The rule is enforced by the API, not only by whether the interface happens to show an Edit button.
Admin-only configuration protects definition integrity; it does not imply administrators are the only valid audience. A practical governance process gives report consumers a way to request changes, names the business owner for each metric, and records important definitions outside a chart title. Administrators should test proposed filters and types, inspect calculated rows, and save as new when an experiment should not replace the established report. Version conflicts should prompt a reload and review rather than silently overwriting another administrator’s work.
Apply the workspace boundary before report filters
For Accounts, Contacts, Deals, and custom-object records, the reporting query begins with the authenticated team boundary. Archived or merged Accounts and Contacts are excluded from ordinary reporting populations, and custom-object reports also require the selected object identifier. Only after that base filter exists does the server translate saved field filters, date constraints, stage selection, and aggregation.
This order matters. A saved owner filter may select a teammate’s records inside the workspace, but it cannot select records from another team. Formula stages and other calculated values are evaluated only after the team match has been placed into the query prefix. The report configuration describes which workspace records qualify; it cannot choose a broader tenant, raw collection, hidden storage path, or arbitrary database expression.
Keep Task reports inside the current user’s inbox
Tasks are intentionally different. The Tasks product is an assignee inbox, so reporting restricts the source to the authenticated user’s assigned Tasks. A role change does not turn a personal Task report into a team workload report. This prevents an apparently harmless count or grouping from exposing coworkers’ private work queues.
Name Task cards accordingly. “My overdue tasks” or “My tasks by priority” communicates the scope; “Team tasks” would overstate it. If the organization needs a team workload capability, that should be designed as an explicit product and permission model rather than inferred through reporting. During dashboard review, test Task cards under several users and expect different totals. A zero for one user and a nonzero total for another can be correct even when every non-Task card matches in a team-wide workspace.
Keep user-authored OR logic inside mandatory access
A report can match All filters or Any filters. With Any, the server creates an OR group containing only the user-authored filter conditions. The mandatory team filter remains a separate AND condition. Conceptually, the query is “record belongs to this workspace AND (condition A OR condition B),” never “record belongs to this workspace OR condition A.” Date, pipeline, and report-type constraints are likewise added without replacing the team boundary.
This is an important negative test. Empty checks, broad text searches, and OR groups deserve the same scrutiny as exact matches because a malformed query could leak aggregate information across teams. Reporting tests should inspect both returned data and the generated base filter, including custom objects, formulas, stage-history queries, and preview requests.
Test access with representative users and failure cases
Create a compact permission test matrix containing an administrator, an ordinary teammate, and a user from another team. Include Accounts, Contacts, Deals, Tasks, and a custom object. Open the dashboard, refresh cards, change a temporary period, inspect calculated values, and attempt CSV download. Confirm that teammates receive the same CRM population, each user receives only personally assigned Tasks, and the other-team user cannot retrieve the dashboard. The current reporting result does not provide record drill-through, so reconcile calculated rows against the matching CRM view.
Test configuration separately. Non-admin API requests to create, update, or delete dashboards and reports should fail even though the user can view and preview reporting data. Test OR filters and empty-value conditions against cross-team records, archived and merged records, formulas, stage history, and ownership transfers. Review logs and error messages for accidental titles or identifiers from another workspace. Repeat the matrix after schema and query changes; permission behavior is a product contract, not a one-time launch check.
Share a pipeline dashboard while preserving workspace boundaries
An administrator creates a dashboard with current Deal count, amount by stage, a progression funnel, time in stage, and My overdue tasks. The administrator tests it as several same-team roles and as a user from another workspace. Saved filters use Any for Enterprise segment or Partner source, but the server keeps the team boundary outside that OR group. The Task card is explicitly titled My overdue tasks because it always uses the current assignee.
Same-team users open the same URL and see the same CRM card titles, settings, period, and Deal population. Each sees only personally assigned Tasks. Ordinary teammates can inspect calculated rows but cannot save a changed definition; a requested revision goes to an administrator. The other-workspace user cannot retrieve the dashboard or contribute records to any result.CRM dashboard permission checklist
- Distinguish shared dashboard configuration from access to underlying records
- Keep dashboards and reports scoped to the authenticated user’s team
- Require administrator authorization for every saved configuration mutation
- Apply the workspace boundary before report filters, formulas, grouping, and aggregation
- Confirm same-team users receive the shared CRM population
- Confirm another workspace cannot retrieve or influence a dashboard
- Label Task reports as current-user reports rather than team workload reports
- Keep user-authored OR conditions inside the mandatory access boundary
- Verify preview, calculated rows, and CSV use the same workspace boundary
- Treat a shared URL as navigation rather than a permission grant
- Show active temporary date overrides when comparing dashboard results
- Test archived, merged, transferred, and custom-object records
- Use representative administrators, ordinary teammates, and another team
- Repeat permission regression tests after schema and query changes
Shared reporting works when workspace boundaries stay explicit
A useful team dashboard needs one stable definition and predictable execution. Intelligent CRM keeps configuration team-scoped, protects saved changes with administrator authorization, uses a shared workspace CRM population, and keeps personal Task metrics tied to the current assignee. That separation lets teams discuss the same questions without weakening tenant isolation.
Document the intended audience and population of each dashboard, label personal Task cards honestly, and test every path that can reveal aggregate data. When two same-team users see different CRM totals, compare filters, periods, refresh timing, and query execution rather than assuming a hidden role scope. Reporting earns trust when people understand both what the metric means and which workspace population it measures.