Monitoring Salesforce
This best-practices guide is intended for readers who already have some proficiency in ThousandEyes and are ready to delve into more advanced guidance. It assumes a basic understanding of networking concepts and familiarity with the ThousandEyes platform. If you're new to ThousandEyes, we recommend starting with our getting started guides to establish a solid foundation.
This article describes monitoring for a third-party application, and might not apply to all use cases. Because the third-party company updates their application separately from ThousandEyes, the information outlined here might not represent the application's latest architecture. ThousandEyes will provide best-effort support for these solutions.
Audience Prerequisites
To effectively follow this guide, you should be:
Familiar with the three types of ThousandEyes Agents and the test types for Cloud and Enterprise Agents and Endpoint Agents
Familiar with ThousandEyes’ role-based access control settings to ensure your user account has the necessary permissions
Able to deploy Enterprise Agents and/or Endpoint Agents, if they’re not already deployed
Aware of your organization’s available licenses for Endpoint Agents and Internet Insights, and available units for Cloud and Enterprise Agents. For information on your organization’s usage and capacity, see the articles in the Usage-Based Billing section.
Comfortable with networking concepts, such as:
TCP/IP, HTTP, DNS, and how they relate
Introduction
Salesforce (also known as Salesforce-dot-com, or "SFDC") is a customer relationship management (CRM) software-as-a-service (SaaS) that aids businesses in managing customer interactions. With its broad suite of services, such as sales, support, marketing, and application development, Salesforce is a crucial part of many employees' daily workflow.
Monitoring the workforce digital experience of a SaaS platform like Salesforce is important because it ensures that employees can use the software effectively and efficiently, which directly impacts productivity, morale, and the company's bottom line. By analyzing and optimizing the digital experience, organizations can proactively identify and resolve usability issues, enhance adoption rates, and improve overall business processes.
This guide will teach you how to monitor your workforce digital experience for Salesforce. To do this, you'll use multiple features within ThousandEyes: ThousandEyes Cloud and Enterprise Agents, ThousandEyes Endpoint Agents, ThousandEyes test templates, and ThousandEyes Internet Insights.
Salesforce Architecture
To monitor a SaaS like Salesforce, it is important to understand its architecture: where and how the services are hosted, and how your users reach those locations. For Salesforce, there are three core services to monitor and assure:
Instance: The Salesforce environment which serves your organization's tenant. The instance itself contains multiple services for your organization, such as Salesforce Classic, Salesforce Lightning, and File Uploads.
DNS: The authoritative domain name servers for resolving Salesforce hostnames, including vanity domains, to IP addresses.
CDN: The content delivery network which serves common static assets, such as images and JavaScript files, that are used for all tenants.
A network or application issue with any of these services will impact your employees' ability to use Salesforce. Each of these services are described in more detail in the following sections.
Your Salesforce Organization
Each Salesforce customer has an “organization” or “org” to which all Salesforce services and functionality are bound, including Salesforce Lightning and Salesforce Classic. An org is effectively a customer’s individual tenant in Salesforce’s multi-tenant architecture -- similar to how your ThousandEyes org works. Each org is part of a Salesforce “instance”, which is the specific environment from which the services and functionality are hosted and served. The org is distinct to each customer, but the SalesForce instance is a multi-tenant environment that serves multiple orgs.
Your organization likely has a specific hostname, sometimes called a vanity domain, for accessing Salesforce. For example, a company named “Pseudoco” might have their Salesforce organization available at pseudoco.lightning.force.com and pseudoco.my.salesforce.com. Authoritative DNS for these hostnames is served by third-party (non-Salesforce) anycast servers.
Salesforce Instances
There are two main types of instance environments for Salesforce: Non-Hyperforce, and Hyperforce.
Non-Hyperforce: The original Salesforce infrastructure environments. Non-Hyperforce instances run on first-party infrastructure owned and operated by Salesforce, and are fully managed, meaning Salesforce handles all the backend infrastructure, scaling, security, and performance aspects. Non-Hyperforce instances are hosted in first-party Salesforce-managed data centers.
Hyperforce: Hyperforce is Salesforce's newest infrastructure architecture, tailored for the public cloud. Hyperforce instances are served from AWS Cloud infrastructure.
Both Hyperforce and Non-Hyperforce instances are monitored the same way from Cloud & Enterprise Agents and from Endpoint Agents. However, monitoring with Internet Insights will depend on whether your instance is a Hyperforce or Non-Hyperforce instance, as explained further in the Internet Insights section of this guide.
To find your organization's instance, see the View instance information for your Salesforce Organization article in Salesforce’s documentation. Alternatively, you can use DNS lookups to identify your instance. For example, if your org’s Salesforce hostname is pseudoco.my.salesforce.com or pseudoco.lightning.force.com, perform a DNS lookup to identify the specific Salesforce instance to which your org belongs. For example:
In the example shown above, the pseudoco Salesforce org is hosted in instance na107.
A Salesforce instance is actively served from one location, regardless of whether the Salesforce instance is Hyperforce or not. This is explained further in the Active Site and Ready Site section below.
Active Site and Ready Site
Each Salesforce instance is replicated across two separate locations: the active site, and the ready site. Salesforce performs site switches between the sites as needed; for example, for maintenance or disaster recovery purposes. You can learn more about site switching and the active site in the Site Switching Overview and FAQ in Salesforce’s documentation.
This means that at any time, outside of your control, your users may be redirected from one location to another and this can impact their experience. For example, the two sites for the na107 instance are located in Hillsboro, Maryland (on the United States east coast), and Portland-Troutdale, Oregon (on the United States west coast). Users on the east coast may experience worse performance when the west coast location is the active site, and users on the west coast may experience worse performance when the east coast location is the active site. By proactively monitoring the active site, you can identify whenever a site switch occurs and use this information to determine if changes in user experience are due to a site switch or something else.
You can identify the active and ready sites for a given instance using the Find My Instance tool.
Uploaded Files
Salesforce allows for customizing the organization (e.g, adding branding/logos, user avatars, etc), as well as uploading files (e.g, uploading a PDF to a sales opportunity). This uploaded content is served from <tenant>.file.force.com, which is part of the Instance to which the tenant belongs. By monitoring the file upload service for your tenant, you can assure that employees have performant and reliable access the assets they need to perform their duties.
Salesforce DNS
Salesforce uses multiple third-party DNS solutions for serving authoritative DNS. The authoritative DNS servers are anycast, as shown in the architecture diagram earlier in this section.
Monitoring the authoritative DNS for Salesforce is accomplished with scheduled synthetic testing from Cloud and Enterprise Agents, described in further detail in the Monitoring Salesforce with Cloud and Enterprise Agents section later in this article. Monitoring DNS resolution for individual end users is accomplished with Endpoint Agents, as described in more detail in the Monitoring Salesforce with Endpoint Agents later in this article.
Static Assets (CDN)
Static assets (such as javascript, images, and CSS) are served from static.lightning.force.com which is fronted by Akamai’s content delivery network (CDN) via a CNAME record. The CNAME points toward Akamai’s edgekey.net domain and further resolves to a unicast address for a regional CDN point of presence.
CDN monitoring for Salesforce can be performed by any or all of Cloud & Enterprise Agents, Endpoint Agents, and Internet Insights, as described in their respective sections later in this guide.
Monitoring Salesforce with Cloud and Enterprise Agents
You can use Cloud and Enterprise Agents to proactively monitor Salesforce with scheduled synthetic testing against the critical services described in the Salesforce Architecture section above. Use Enterprise Agents from within your own secure networks, and Cloud Agents to monitor from outside of your own networks. This section includes where to locate your ThousandEyes agents, and what to test from each vantage point.
If your ThousandEyes organization does not have units for running Cloud and Enterprise Agent tests, you can skip this section and proceed to the Monitoring Salesforce with Endpoint Agents or Monitoring Salesforce with Internet Insights sections below.
Agent Placement and Selection
ThousandEyes Cloud & Enterprise Agents are global vantage points. Use Enterprise Agents for "inside-out" testing and Cloud Agents as external reference points testing the same Salesforce targets.
Enterprise Agents: Use ThousandEyes Enterprise Agents to proactively monitor your Salesforce digital experience from vantage points within your enterprise WAN. This is known as “inside-out” testing which monitors your specific network paths from your own network to the Salesforce cloud.
At a minimum, place an Enterprise Agent at each Internet egress point.
For hub-and-spoke network architectures with centralized egress, the recommended best practice is to also test from Enterprise Agents at each “spoke” user location. Spokes are typically branch offices.
Cloud Agents: Use ThousandEyes Cloud Agents to establish a baseline and reference point for web application performance outside of the enterprise network. It is recommended to select at least one Cloud Agent for each region where you have an Internet egress and have also deployed an Enterprise Agent.
Why do we use both Cloud Agents and Enterprise Agents?
By using both internal and external vantage points, we can more quickly triage and troubleshoot events which impact user performance. For example, if your Salesforce tests are failing from both Cloud and Enterprise Agents, this indicates an issue affecting more than just your own enterprise, like an application issue in the Salesforce environment, or a network issue near the Salesforce environment. If your Salesforce tests are failing from Enterprise Agents but not Cloud Agents, this indicates a problem closer to or within your own environment, like an issue with your own ISP.
Cloud Agents are also useful to represent your employees who are not located within your enterprise network, such as hybrid workers. While Endpoint Agents are best fit for hybrid workers / work from home use cases, Cloud Agents are still useful as an always-on external reference point if you do not have Endpoint Agent licenses or have not yet deployed your Endpoint Agents.
Note on Proxies
Web proxy configuration can be applied either at the agent level or at the test level. The tests that are included in the ThousandEyes test template for Salesforce do not specify any proxy configurations at the test level. Instead, these tests default to use the proxy configuration of each individual ThousandEyes agent. This allows you to deploy the ThousandEyes test template for Salesforce using a mixture of agents, both with and without a proxy; for example, to compare the performance of Salesforce when accessed directly versus through the proxy.
For more information on configuring agent-level proxies, see the Proxy Settings section of the Working with Agent Settings article.
Salesforce Cloud and Enterprise Agent Template
ThousandEyes provides a Cloud and Enterprise Agent test template with the tests that you need to assure users’ Salesforce experiences. The test template for Salesforce uses the test types described below.
The HTTP server tests are used to monitor the performance, reachability, and availability of Salesforce web components.
Salesforce Lightning: <tenant>.lightning.force.com
Salesforce Classic: <tenant>.my.salesforce.com
File Uploads: <tenant>.file.force.com
The Agent to server test is used to monitor Salesforce components that cannot be monitored using an HTTP server tests without more advanced configuration; specifically, the Akamai CDN which serves shared static assets.
static.lightning.force.com
The DNS server test monitors the availability, performance, and network connectivity to the third-party authoritative DNS servers.
pch1.salesforce-dns.com
pch2.salesforce-dns.com
udns4.salesforce.com
udns1.salesforce.com
udns2.salesforce.com
udns3.salesforce.com
Both the HTTP server and DNS server test types are multi-layer: they automatically include network tests towards their targets, measuring packet loss, latency, jitter, and identifying the network path, in addition to the application metrics they collect. See Test Type Layering for more information on test layers.
Using the ThousandEyes Salesforce Test Template
A ThousandEyes template is a suite of ThousandEyes resources, such as tests and dashboards, designed for monitoring a service based on the best practices for that particular type of target. Now that we've discussed all the tests, agents, and targets in the ThousandEyes Salesforce test template, we are ready to use this template to deploy our tests.
Multiple permissions are required to view and deploy test templates. For the complete list, see the Prerequisites section of the Test Templates article.
To begin deploying a template:
Navigate to the Cloud & Enterprise Agents > Test Settings page
Click Add From Template in the drop-down menu
This will open the Deploy Template dialog at Step 1 of 3 - Select template. At the top of the Deploy Template dialog:
Type “Salesforce” in the Search box to filter the list of available templates.
Click the Salesforce template in the list to proceed to configure the tests.
After clicking the Salesforce template, the dialog moves forward to Step 2 of 3 - Configure tests and shows the template’s Global Settings. The global settings are where you provide the specific details of your Salesforce tenant, the Cloud and Enterprise Agents that will run the tests, and the interval at which the tests will run. These global settings will apply to all of the tests in the template.
The ThousandEyes Salesforce test template requires you to:
Select the Agents for the tests
Enter your Salesforce tenant name
E.g, if your Salesforce Lightning URL is https://pseudoco.lightning.force.com, then your tenant name is pseudoco. See Your Salesforce Organization above for more details.
Select a testing interval (recommended: 1 or 2 minutes, no greater than 5 minutes)
Provide a name for your test suite to easily identify which tests were deployed from this template. This name is arbitrary, but note that:
The name will be prefixed to all of the tests’ names, and long names may be harder to discern or distinguish in dashboards and test views.
A label will be created with this same name and applied to all the tests
Excluding Tests from the Template Deployment
Before proceeding to review your template deployment, you may want or need to exclude some of the tests in the template from the deployment. For example, if your organization uses Salesforce Lightning but not Salesforce Classic, you should exclude the Salesforce Classic tests from the template. Or, if your users login to Salesforce with Identity Provider (IdP) initiated single sign-on, you might exclude the Salesforce Login test from the template. To exclude a test, click the toggle switch next to the test’s name, as shown in the screenshot below.
Once you have provided the necessary details in the template’s Global Settings, you should be able to proceed to review the template deployment by clicking the Review button.
After clicking the Review button, the dialog moves forward to Step 3 of 3 - Review template and displays a summary of the tests, labels, and dashboards included in the deployment. Review the summary, then click Deploy Now to deploy the monitoring suite. The dialog updates to show the template is being generated and the tests, labels, and dashboards are being built, as shown in the image below.
The deployment process may take a few minutes to complete. When it has finished, the dialog shows a success message and includes two links:
Clicking Go to Test Settings will navigate to the Cloud & Enterprise Agents > Test Settings page, filtered to show only the tests included in this deployment
Clicking Go to Dashboards will navigate to one of the dashboards created by the template
Salesforce Dashboard
This section describes the dashboard that is included in the Salesforce test template. This dashboards is designed with the highest-level information shown at the top, with increasing granularity in the widgets that follow.
All of the widgets in these dashboards allow you to drill down into the individual tests for complete details. Click on the widget to open the drilldown dialog, then select the tests to view, and click Open in Views.
The first three rows of the dashboard show alerts activity, web app health summary, and network health summary, aggregated for all Salesforce tests in your deployment. This top third of the dashboard, shown in the image above, is intended as a default "NOC view" from which you can easily glean the health status of Salesforce overall.
When Salesforce is healthy, expect to see 'No Alert Activity' in the alerts widget, and green number cards in the web app health and network app health widgets. When problems arise, alerts will show in the alerts widget, and the web app health and network app health widgets will change from green to yellow to orange to red, depending on the scope and severity of the performance degradation.
The middle section of the dashboard, shown above, begins to break down the metrics for each service, such as Salesforce Lightning and Classic. This allows you to easily see if user experience for an individual service is impacted.
The bottom widget of the dashboard shows each of your Salesforce tests, along with their current alert status, the most recent test measurements, and the trends of those measurements over the last 12 hours. You can click on any of the tests in this list to open the test view.
Monitoring Salesforce with Endpoint Agents
The Endpoint Agent is a lightweight service installed on an end user's laptop or desktop that monitors applications through a browser plug-in. Because Endpoint Agent goes where the user goes, you can use it to troubleshoot performance issues related to Wi-Fi, bandwidth capacity, ISP routing, VPN gateways, and SaaS availability.
In addition to the Cloud and Enterprise Agent test template described above, you can use ThousandEyes Endpoint Agents for both scheduled synthetic testing ("Synthetic Tests") and real user monitoring ("Real User Tests") of Salesforce. For more information on End-user monitoring, see the Getting Started with Endpoint Agents guide and the End-User Monitoring section of the ThousandEyes documentation.
Synthetic Tests
To configure scheduled synthetic tests, you must have the Edit endpoint tests permission.
Configure the three scheduled tests described below by:
Navigating to the Endpoint Agents > Test Settings page
Clicking the Synthetic Tests tab, if not already selected
Clicking the + Monitor Application button.
This will open the Monitor Application dialog at Step 1 of 3 - Select an application. Select Salesforce from the list of applications.
After clicking the Salesforce application, the dialog moves forward to Step 2 of 3 - Configure tests and shows the application monitoring settings. The Salesforce application monitoring configuration requires you to:
Select a testing interval (recommended: 1 or 2 minutes, no greater than 5 minutes)
Select the Agents for the tests
Enter your Salesforce tenant name
E.g, if your Salesforce Lightning URL is https://pseudoco.lightning.force.com, then your tenant name is pseudoco. See Your Salesforce Organization above for more details.
Provide a name for your test suite to later identify which tests were deployed for this application. This name is arbitrary, but note that:
The name will be prefixed to all of the tests’ names, and long names may be harder to discern or distinguish in dashboards and test views.
A label will be created with this same name and applied to all the tests
Once you have provided the necessary details in the template’s Global Settings, you should be able to proceed to review the template deployment by clicking the Review button.
After clicking the Review button, the dialog moves forward to Step 3 of 3 - Review application monitoring and displays a summary of the tests, labels, and dashboards included in the deployment. Review the summary, then click Deploy Now to deploy the monitoring suite. The dialog updates to show the template is being generated and the tests, labels, and dashboards are being built, as shown in the image below.
The deployment process may take a moment to complete. When it has finished, the dialog shows a success message and includes two links:
Clicking Go to Test Settings will navigate to the Endpoint Agent > Test Settings page, filtered to show only the tests included in this deployment
Real User Tests
Configure real user monitoring for Salesforce by including the most important domains in the monitored domain set for your Endpoint Agents. A monitored domain set consists of domains that you want to automatically gather end-user performance metrics about as the users navigate to those domains.
Navigate to the Endpoint Agents > Test Settings page and click the Real User Tests tab. ThousandEyes recommends including the following Salesforce Monitored Domain Set in your Endpoint Agent real user test configuration:
Salesforce Monitored Domain Set:
salesforce.com
force.com
lightning.com
The Edit endpoint agent monitored domain sets permission is required to configure real user tests.
To add a new monitored domain set:
Click the Add New Monitored Domain Set button to open the Add New Monitored Domain Set dialog
Enter a name for the domain set (for example, "Salesforce Monitored Domain Set")
Add the domains above to the Monitored Domains input field. Note: You must enter each domain one at a time, you cannot copy and paste the full list.
To learn more about configuring real user tests, see the Real User Tests article.
Monitoring Salesforce with Internet Insights
When a critical service is disrupted, it's common to wonder if you're the only one affected by the outage or if the issue is larger in scope or scale. Internet Insights collects data from a diverse set of vantage points across the globe to offer visibility into service providers, including Salesforce and Amazon Web Services. Internet Insights is built upon ThousandEyes’ collective data set -- billions of probes across the Internet to websites, apps, and API endpoints every day -- combined with outage detection to provide a macro-scale view into network and application outages. The intelligence derived from this data enables operations teams to quickly identify and resolve issues with providers using concrete Internet telemetry data.
To effectively monitor Salesforce with Internet Insights, it's crucial to include the most relevant packages from the catalog. ThousandEyes recommends selecting the following packages in your Internet Insights Catalog Settings configuration to enable you to understand if these services are affected by disruptions.
Package Selection
The SaaS Providers package is essential — particularly, the one(s) tailored for your region. For example, if your offices and users are located in North America, you might use the package titled North America SaaS Providers This package enables you to detect application outages directly affecting Salesforce in your region.
Salesforce leverages Akamai to deliver static content, including images, CSS, and JavaScript files. To gauge the impact of potential CDN network outages on your user experience, it's advisable to choose the CDN Providers package for each region where your users are located. For instance, the "North America CDN Providers" package will monitor network outages for Akamai's CDN.
Additionally, for Salesforce tenants running on a Hyperforce instance, it's important to also include the IaaS Providers package for every user region, such as "North America IaaS Providers." This package provides insights into both application and network outages, including on Amazon Web Services, ensuring comprehensive coverage of your Salesforce environment.
Activating an Internet Insights Package
To activate a package for Internet Insights when you have available licenses for it:
Go to Internet Insights > Catalog Settings screen and click the Packages tab.
Verify that the Available counter shows one or more licenses.
Find the row with the package that you want to add.
In the Included column, click the Active slider to add the package.
To activate a package when you have no available licenses, you can purchase an additional license by contacting your customer success manager. Or, you can first deactivate a package, then activate the desired package in its place. To deactivate an Internet Insights package:
Go to Internet Insights > Catalog Settings screen and click the Packages tab.
Find the row with the package that you want to remove.
In the Included column, click the Active slider to remove the package.
To learn more about Internet Insights, see the Getting Started with Internet Insights article and the Internet Insights section of the documentation.
Last updated
