Hi everyone,
I have a requirement to implement Row-Level Security (RLS) in a CRM Analytics (CRMA) dashboard for three different types of users: Branch Users, Corporate Users, and Legal Users.
The expected access is:
- Branch Users – should only be able to see data belonging to their respective branch.
- Corporate Users – should be able to see data across all branches.
- Legal Users – should only be able to see the records/data relevant to Legal.
The same CRMA dashboard will be used by all three types of users, but the data displayed should be restricted based on the logged-in user's access.
I'm considering using
Security Predicates for this requirement, potentially using Salesforce User attributes such as User Type and Branch.My questions are:
- What would be the recommended approach for implementing this type of RLS in CRMA?
- Should this be handled using Security Predicates, Sharing Inheritance, or a combination of both?
- What is the recommended way to map the Salesforce User attributes (User Type, Branch, etc.) to the CRMA dataset?
- Can a single Security Predicate handle all three scenarios?
- Are there any best practices or considerations when implementing this for a production dashboard?
If anyone has implemented a similar Branch / Corporate / Legal user access model in CRMA, I would really appreciate an example or guidance on the architecture and Security Predicate approach.
Thanks!
#CRM Analytics
There's no native "blocking modal" widget in CRMA dashboardsnothing in the standard widget palette (chart, list, toggle, date, range, number, text) creates a popup that intercepts interaction on load. What CRMA does give you natively are selection based filter widgets date, list, range, and toggle that let users filter results, and these can trigger selection bindings that dynamically change other query parameters, plus the ability to set initial filter selections that are applied when the dashboard first opens.
None of that adds up to a true gate, though it pre selects or lets users filter, but users can still interact with every widget before making a choice, which breaks your requirement #6.
What actually gets you the behavior you described: a custom LWC wrapper, not a dashboard internal component.
The key distinction is where the LWC lives. Don't embed it as a widget inside the dashboard canvas embed the dashboard inside
an LWC on the Lightning App Page instead:
- Build an LWC for the App Page that, on connectedCallback, shows a modal (SLDS modal or the native lightning-modal overlay) with a Customer Name picklist/combobox.
- Don't render the <lightning-analytics-dashboard> component at all until the user submits a selection - conditionally render it with if:true. This is what actually satisfies "no interaction before selection," since the dashboard genuinely isn't mounted yet, not just visually hidden.
- On submit, close the modal and mount the dashboard, passing the chosen customer in as a filter - either via the dashboard component's filter/selection input, or via the query-string filter/selection syntax CRMA supports for embedded dashboards.
- This pattern (custom LWC talking to a CRMA dashboard, Apex backed data lookups feeding the picklist) is a standard, well documented approach embedding LWCs into or alongside CRMA dashboards is explicitly supported.
If you want to avoid a custom component entirely, the closest declarative approximation is: a required Global Filter Panel widget with no default selection, paired with faceting so every other widget shows an empty/prompt state until a Customer is chosen. It's a real CRMA pattern and much less build effort, but it only discourages
interaction with unfiltered widgets it doesn't block it, so it won't fully satisfy your requirement #6 as written. Worth confirming with whoever owns this requirement whether that softer UX is actually acceptable before committing to the LWC build, since it's a meaningfully smaller lift.
One thing to flag before you build either way: confirm whether this dashboard is embedded (Lightning App Page / Experience Cloud) or accessed directly in the Analytics Studio tab the LWC wrapper approach only works for the embedded case, since you need a page to host the wrapper component around the dashboard.