A lightweight collection of CRM Analytics dashboards for gaining a better understanding of Event Monitoring data.
Easy Option: CRM Analytics Templated App
- (If the "Event Monitoring Analytics" CRM Analytics app is already running with the below-listed log types, you can skip to Package Deployment)
- Select a sandbox or production org
- Ensure Event Monitoring Analytics is enabled
- Assign permissions to users
- Create the analytics app
- Hard Requirement: must include following log types:
- ApexExecution
- ApexUnexpectedException
- ApexCallout
- ApexRestApi
- ApexSoap
- ApexTrigger
- API
- BulkApi
- ConcurrentLongRunningApexLimit
- LightningInteraction
- LightningPageView
- Login
- Report
- RESTApi
- Hard Requirement: must include following log types:
Harder Option: Set up a custom process to push Event Logs into CRM Analytics
Use the button below to authenticate with the Heroku app. Make sure to enter 'main' in the Branch/Tag/Commit field.
- It is recommended to use Salesforce DX or Workbench to perform the deployment, as per the video installation guide link, above.
- Identify the API name of the above-mention datasets in CRM Analytics that you wanted to analyse.
- These should be datasets that are regularly updated, as part of whichever log ingestion process you've configured above.
- To identify the API name of a dataset, follow these steps to reach the edit page and note the 'API Name' in the top-left.
- This package assumes that the dataset names are the first or only iteration of the log ingestion process, and hence uses simple dataet names, like, for example "ApexExecutionWithUsers" for the ApexExecutionWithUsers log file. (If you have gone through several iterations of creating the CRM Analytics templated app, you may end up with dataset names like "ApexExecutionWithUsers1" or "ApexExecutionWithUsers5" (if you've been unlucky enough to create it 5 times)).
- If your dataset names are different / have numbers as suffixes, download the package, edit the .wdash (Wave Dashboard) files, and Find/Replace with the appropriate dataset API name from your environment (e.g. "LightningPageViewWithUsers" with "LightningPageViewWithUsers1"). (User_Activities.wdash uses the LightningInteractionWithUsers and LightningPageViewWithUsers datasets; Apex_Performance.wdash uses ApexExecutionWithUsers; Apex_Exceptions.wdash uses ApexUnexpectedException).
- If you are using the datasets from the default Event Monitoring analytics app (te the '~WithUsers' datasets), make sure that you've scheduled your Event Monitoring Analytics app's dataflow.
- This is a SFDX version of the original repo. So you just have to auth an org and deploy as per the
manifest/package.xmlas explained here. - You can also deploy the dashboards with these two other alternatives:
- Metadata deployment with Ant, SFDX, etc. If you know how to do this, the
misc/mdapi/package.xmland payload should suffice.- If you don't know how to do a metadata deployment, create a .zip of the
misc/mdapi/directore (your zip file should not have any root folder - bothpackage.xmlandwavefolder should be on the root of the zip file), and then follow this guide; note in Step 7 you do have to click the 'Single Package' checkbox.
- If you don't know how to do a metadata deployment, create a .zip of the
- You can also use the JSON files that are available into
misc/json/and copy and past them from the folder direclty into a new, blank dashboard in CRM Analytics. This method is not preferred as you're not deploying the dashboard's extended metadata (XMD), and so you lose the rich, informative colour-coded metrics that were lovingly added to the dashboards. Only use this approach as a last resort or you just want an initial glance.
- Metadata deployment with Ant, SFDX, etc. If you know how to do this, the
It is imperative that every business understands what parts of a Salesforce implementation are valuable to its users. This dashboard gives a top-to-bottom view of what UI-level interactions users perform in Lightning, from apps, standard and custom objects, to components of a page layout, what they view and what they click. As a result, Salesforce sponsors, stakeholdes, owners, product owners, project managers, admins and developers have a clearer sense of what is valuable to users by virtue of their level of interaction with many of the customisations they have developed and improved and put in the hands of users. This dashboard leverages the LightingInteration event log; reading the documentation is strongly encouraged.
A narrative of the raw ApexExecutionWithUsers dataset in order to help pin-point slow-performing code. Ideally for a Developer, Admin, QA, Release Manager and / or Product Owner to identify what code is consistently slow, what's started being slow, and what skillset is required to begin reviewing the code. Try and use this early-on in your development process, or at the very latest in a UAT full-copy sandbox, so you can spot trends in newly-problematic code and decide if a current release is about to introduce risk to the business in production. This dashboard leverages the ApexExecutionWithUsers event log; reading the documentation is strongly encouraged.
When Apex starts to break, quick and decisive action is needed. This dashboard gives a clear view of what Apex classes and methods are generating unhandled exceptions, by volume, over time. Realistically, every datapoint on this dashboard is something for developers to review, consider, and fix or prevent. QAs, Release Managers and Product Owners should be reviewing this dashboard early in the development process, or at the very latest in a UAT full-copy sandbox. If things are beaking, this dashboard will help decide if a current release is about to introduce risk to the business in production by breaking business-critical processes. This dashboard leverages the ApexUnexpectedException event log; reading the documentation is strongly encouraged.
Helps you to identify the pages that are performing poorly in Lightning, by GEO, App, Object. Uses CRMA compare tables to calculate lost productivity due to poor page load time (EPT). This dashboard leverages the LightningPageViewWithUsers and LightingInteration event log; reading the documentation is strongly encouraged.
A very similar dashboard to the Lightning Page Performance EPT dashboard, but with some filters and tweaks to help better understand and visualise which Experience Cloud pages have higher EPT. This can be explored by many dimensions, such as the Site URL, user's location / geo, browser version, etc. This has only been tested with Experience Cloud site templates; it has not been tested with Aura or LWR Buil-Your-Own sites.
A dashboard that looks at reports from adoption, performance and security points-of-view (the three pillars of Event Monitoring!). Adoption: who's running existing reports as opposed to editing or building new ones (reports with no name). Performance: the relationship between rows returned and database (DB) time. Security: how may reports are being run in .csv, Excel or printable formats.
This dashboard gives a complete performance overview of the business logic and API layers of your org; highlights the usual errors and hotspots that cause general platform and org-wide performance bottlenecks and failures. Consider this as a general superset of some of the other performance-focused dashboards in this repo. Can be used as a startign point to spot general performance trends that can be investigated more thoroughly in other lenses or dashboards.
The Dashboards are in an app / folder called "Event Monitoring Plus" that uses the Event Monitoring licence type. Please do not click the 'Reconfigure' link at the top of the app page; it will overwrite and remove these dashboards.
As of January 2023, the dashboards now use the '~WithUsers' datasets. It is important that you've scheduled your Event Monitoring Analytics app's dataflow.
The app is deployed with a default security setting of 'Manager' for the Entire Organisation; anyone in the Entire Organisation that has access to CRM Analytics. Users will only be able to view the contents of the dashboards if they also have access to the datasets. Your datasets are protected within whichever app you've stored them in and so will remain as the main security control. Related point: feel free to edit and save these dashboards into your existing Event Monitoring CRM Analytics app. Again, be aware of reconfiguring any templated apps, as it will delete these dashboards.