Monitoring Salesforce
Last updated
Last updated
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 to establish a solid foundation.
To effectively follow this guide, you should be:
Familiar with the and the test types for and .
Familiar with ThousandEyes’ 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 section.
Comfortable with networking concepts, such as:
TCP/IP, HTTP, DNS, and how they relate.
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 teaches 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.
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.
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.
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 and 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.
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.
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.
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 .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 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 (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 and Enterprise Agents, Endpoint Agents, and Internet Insights, as described in their respective sections later in this guide.
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.
ThousandEyes Cloud and 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.
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
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.
To begin deploying a template:
Navigate to the Network & App Synthetics > 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 you click 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.
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.
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 Network & App Synthetics > 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
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.
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.
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 the 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.
To configure scheduled synthetic tests, you must have the Edit endpoint tests permission.
To configure the three scheduled tests described below:
Navigate to the Endpoint Experience > Test Settings screen.
Click the Synthetic Tests tab, if not already selected.
Click + Monitor Application.
This opens the Monitor Application dialog at Step 1 of 3 - Select an application. Select Salesforce from the list of applications.
After you click 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.
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 Experience > Test Settings page, filtered to show only the tests included in this deployment
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 Experience > 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.
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.
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.
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 find your organization's instance, see the 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:
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 in Salesforce’s documentation.
You can identify the active and ready sites for a given instance using the tool.
If your ThousandEyes organization does not have for running Cloud and Enterprise Agent tests, you can skip this section and proceed to the or sections below.
For more information on configuring agent-level proxies, see .
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 for more information on test layers.
Multiple permissions are required to view and deploy test templates. For the complete list, see the of the Test Templates article.
Click the down caret button () next to the Add New Test button
E.g, if your Salesforce Lightning URL is https://pseudoco.lightning.force.com, then your tenant name is pseudoco. See above for more details.
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 guide and the section of the ThousandEyes documentation.
E.g, if your Salesforce Lightning URL is https://pseudoco.lightning.force.com, then your tenant name is pseudoco. See above for more details.
To learn more about configuring real-user tests, see the article.
To learn more about Internet Insights, see the article and the of the documentation.
