Skip to main content
Availability2017.1 or later

Configure Error Monitoring for Salesforce

Separate real failures from noise

Browser Error Monitoring

Capture front-end failures

Categorize Salesforce Errors

Group repeated errors together

Visualize and Analyze Salesforce Errors

Error-analysis portlet with KPIs

Configure Error Monitoring for Salesforce

GermainUX detects, classifies, prioritizes, and analyzes errors affecting Salesforce users and business processes.
Error Monitoring for Salesforce Cloud (Configure): Configure Error Monitoring for Salesforce
The objective is to separate actionable software failures from expected validation messages and technical noise, allowing teams to focus on issues with measurable business or user impact. GermainUX helps answer:
  • Which Salesforce errors affect users?
  • Which errors are new?
  • Which errors recur most frequently?
  • How many users, sessions, and workflows are affected?
  • Which errors prevent users from completing their work?
  • What actions occurred before the error?
  • Is the cause related to the browser, Salesforce, Apex, an API, or an integration?
  • Has the error stopped occurring after the fix?

Error Sources

GermainUX can detect Salesforce errors from multiple sources. Deploy and configure the applicable monitoring components for the sources you need.

Error Classification

Before configuring dashboards and alerts, distinguish the following categories.
A message being visible to the user does not automatically mean that the user caused it. Use user-facing error for software failures displayed to users and user validation for expected feedback about incorrect or incomplete input.
Some existing GermainUX configurations use the internal field userError. In this context, it generally identifies an error relevant to the user experience. It should not be interpreted as proof that the user caused the problem.

Prerequisites

Before configuring Salesforce Error Monitoring, confirm that: For deployment instructions, see Deploy GermainUX for Salesforce.

Configure Browser and User-Facing Error Monitoring

Open the Salesforce UX Monitoring Profile

In GermainUX Workspace, navigate to: GermainUX Workspace → Left Menu → Settings → Analytics → UX Monitoring Profiles → Salesforce
Error Monitoring for Salesforce Cloud (Configure): Open the Salesforce UX Monitoring Profile
The Salesforce UX Monitoring Profile controls the browser-side monitoring used to detect and enrich Salesforce errors.

Profile Capabilities

The current Salesforce profile should provide the applicable configuration for:
  • Salesforce-specific browser integration
  • User and session identification
  • Salesforce application and component metadata
  • Console error and warn events
  • Salesforce Aura errors
  • Application and developer errors
  • Error toasts and form-level errors
  • Network processing
  • Salesforce request and response processing
  • User clicks
  • Page and interaction performance
  • Session termination on logout
  • Search and workflow monitoring when configured
Use the current profile supplied with your GermainUX version. Do not replace it with code copied from an older documentation page unless instructed by Germain Software Support. Review the following behaviors in the profile.

Browser Log Threshold

Configure which browser log levels should generate facts. A typical Salesforce profile emits:
This allows warnings and errors to be analyzed while avoiding lower-level console noise. Increase or reduce the threshold according to the required diagnostic detail and data volume.

Session End Markers

Configure logout labels so GermainUX closes the user session when the user logs out. Example:
Validate these labels against the organization’s language and Salesforce customization.

User and Application Metadata

Configure metadata providers for attributes such as:
  • Session ID
  • Username or anonymized user identifier
  • Salesforce application
  • Active Salesforce component
  • Business object
  • Page or view
  • Organization and environment
These attributes improve segmentation and correlation. Do not collect raw identifiers when organizational privacy policies require anonymization.

Console Errors and Warnings

Enable processing for:
The Salesforce-specific processor should determine whether each console message is:
  • An actionable error
  • A relevant warning
  • Known noise
  • Sensitive and requiring sanitization

Salesforce Error Dialogs and Toasts

The Salesforce integration can detect events such as:
  • Aura application messages
  • one:applicationError
  • Lightning developer errors
  • force:showToast error messages
  • Form-page errors
  • Validation dialogs
  • Other supported Salesforce popup events
Captured facts should include available attributes such as:
  • Error name
  • Title
  • Message
  • Stack trace
  • Business-object identifier
  • User-facing status
  • Salesforce component
  • Timestamp

Network Errors

The Salesforce profile can process Aura and other Salesforce network activity. Review:
  • Excluded URLs
  • Failed-status handling
  • Request and response parsing
  • Sensitive-body exclusions
  • Duplicate-request detection
  • Salesforce-specific request names
  • Correlation identifiers
Exclude monitoring of endpoints that generate irrelevant or high-volume traffic, such as configured streaming or analytics endpoints, when those calls are not required for the intended analysis.

Duplicate Request Detection

The profile can identify repeated network requests within a short period. This may reveal:
  • Retried failed actions
  • Loops
  • Duplicate submissions
  • Repeated component requests
  • UX frustration
Configure the time window and repetition threshold according to expected Salesforce behavior.

Activate and Validate the Profile

After modifying the Salesforce UX Monitoring Profile:
1

Save the profile

2

Confirm that it is assigned to the Salesforce application

3

Reload Salesforce in a supported browser

4

Start a new monitored session

5

Trigger a safe, known error in a non-production environment

6

Confirm that GermainUX captures the error

7

Verify its name, message, user-facing status, session, and application metadata

8

Open Session Replay and confirm that the error appears in context

Configure Server-Side Error Sources

Browser monitoring reveals what the user experienced. Configure the Engine-based Salesforce sources to add technical evidence. Combining browser and Engine telemetry helps determine whether the source is:
  • A Salesforce UI problem
  • Custom JavaScript
  • Apex code
  • SOQL or database activity
  • Salesforce platform behavior
  • An external integration
  • A network or browser problem
  • User validation rather than a technical failure

Categorize Salesforce Errors

Without categorization, dynamically changing values can cause the same underlying error to appear as many unrelated messages. For example:
These should normally receive the same category because the Salesforce record ID changes but the underlying failure pattern is identical.

Create a Categorization Rule

Navigate to: Analytics → Categorization Then:
1

Create or select a categorization configuration

2

Select the error KPIs to which the rule applies

3

Configure the fuzzy-matching threshold

4

Add filters limiting the rule to Salesforce error facts

5

Define exact-match prefixes or parsing logic for known dynamic messages

6

Save the rule

7

Test it against representative errors

8

Reprocess historical data when appropriate

Error Monitoring for Salesforce Cloud (Configure): Create a Categorization Rule
For more details, see Categorization.

Simple Categorization Example

Every matching occurrence receives the same category identifier even when the Salesforce record ID or remaining message text differs. Common patterns that may require normalization include:
  • An internal server error has occurred Error ID
  • Invalid date format
  • SendEmail failed. First exception on row 0
  • Unable to get actions for recordIds
  • Update failed. First exception on row 0 with id
  • Upsert failed. First exception on row 0 with id
  • Record ID is malformed
  • This record was modified by
  • Unexpected Response code
  • You do not have access to the Apex class named
  • You do not have the level of access necessary
  • Messages containing changing gackId values
Organization-specific validation messages may also need classification, but they should be categorized separately from technical errors. Examples include:
  • Required fields
  • Invalid email addresses
  • Missing approvers
  • Permission guidance
  • Instructions to use a workflow button
A reusable rule can normalize known error prefixes and use a checksum for messages that do not match a known pattern.
Extend the rule with patterns relevant to the organization rather than maintaining a large list of unrelated sample messages.

Existing and New Errors

After categorization:
  • A known matching error receives an existing category ID.
  • A message that does not match an existing category receives a new category ID.
  • New categories can trigger alerts or review workflows.
  • Recurring occurrences can be aggregated and ranked together.
This makes it possible to identify genuinely new failures without alerting repeatedly on minor variations of known messages.

Visualize and Analyze Salesforce Errors

Create an error-analysis portlet using the KPIs that capture your Salesforce error sources.
Error Monitoring for Salesforce Cloud (Configure): Visualize and Analyze Salesforce Errors

Suggested KPIs

Depending on the configuration and GermainUX version, use:
  • Browser Event
  • JavaScript Console Event
  • JavaScript Popup Dialog
  • Outbound HTTP Request
  • Apex exception KPIs
  • Salesforce Debug Log KPIs
  • Other custom Salesforce error KPIs
JavaScript Popup Dialog is particularly useful for errors displayed through Salesforce dialogs and toasts.

Suggested Measures

Use measures such as:
  • Count
  • Unique error categories
  • Unique users
  • Unique sessions
  • Affected workflows
  • Total duration
  • Lost productivity
  • Failure rate
  • Percentage of sessions affected

Suggested Pivots

Use available dimensions such as:
  • Category ID
  • Name
  • Message
  • Error source
  • Application
  • Salesforce component
  • User
  • Profile
  • Page or view
  • Business process
  • Business-process step
  • Salesforce organization
  • Environment
  • Browser
  • Application version

Suggested Filter

For configurations using the legacy internal marker, filter on:
or:
The precise label depends on the GermainUX version and fact schema. This filter should represent user-relevant or user-facing errors—not necessarily errors caused by users.

Include or Exclude Specific Errors

After creating the portlet, add filters to:
  • Include only user-facing technical errors
  • Exclude known benign messages
Filter in or out specific Salesforce errors

Filter in or out specific Salesforce errors - GermainUX

  • Separate user validation
  • Focus on one workflow or Salesforce component
  • Analyze only new categories
  • Exclude test users or non-production environments
  • Limit analysis to critical errors
Prefer classification over permanent exclusion when a message may still have UX or training value.
Error Monitoring for Salesforce Cloud (Configure): Include or Exclude Specific Errors

Configure Alerts and Reports

Immediate Alerts

Configure an alert when:
  • A new error category appears.
  • A critical user-facing error occurs.
  • Error volume exceeds a baseline.
  • An error affects multiple users.
  • A business-critical Salesforce workflow fails.
  • A previously resolved error returns.
  • Failure rate increases after a deployment.
  • An integration error blocks Salesforce users.
See Alerts.

Scheduled Reports

Create scheduled reports showing:
  • New error categories
  • Highest-volume errors
  • Most affected users
  • Most affected workflows
  • Error trends
  • Resolved and recurring errors
  • Errors introduced after a release
  • User validations requiring UX improvement
  • Estimated productivity or business impact
See Automated Reports.

Validate Error Monitoring

Test the configuration using representative controlled scenarios. Verify that:
  • A Salesforce error dialog is captured.
  • An error toast is captured.
  • Browser console errors are captured.
  • Failed Salesforce requests are identified.
  • Apex exceptions appear when server-side monitoring is enabled.
  • Error messages are categorized correctly.
  • User validation is separated from technical failures.
  • Known benign events are excluded or suppressed.
  • New errors receive new category IDs.
  • User, application, page, and workflow context are present.
  • Session Replay shows the events leading to the error.
  • Alerts and reports include only the intended errors.
  • Sensitive values are masked or excluded.

No Errors Appear

If known Salesforce errors are missing:
1

Confirm that the RUM Extension is installed and active

2

Confirm that the Salesforce UX Monitoring Profile is assigned

3

Verify the application and profile names

4

Confirm Salesforce CSP Trusted Sites

5

Check browser connectivity to GermainUX

6

Verify that console, popup, and network monitoring are enabled

7

Check whether the error occurs inside an unmonitored or isolated context

8

Review privacy, exclusion, and filtering rules

9

Confirm that the selected dashboard time range and environment are correct

10

For server-side errors, verify the Engine, OAuth, and applicable Salesforce monitors

Too Many Errors or Too Much Noise

If dashboards contain too many non-actionable events:
1

Raise the browser log threshold

2

Exclude known noisy endpoints

3

Improve Salesforce-specific error processing

4

Categorize dynamic messages

5

Separate validation messages

6

Exclude recognized benign categories

7

Alert only on new, critical, or high-impact errors

8

Rank issues by affected users, workflows, and business impact rather than raw count alone

Security and Privacy

Salesforce error messages can contain:
  • User identifiers
  • Salesforce record IDs
  • Customer or patient information
  • Field values
  • Request and response content
  • Stack traces
  • Integration endpoints
  • Internal implementation details
Before production enablement:
  • Configure masking, anonymization, and exclusions.
  • Restrict access to error details and Session Replay.
  • Avoid collecting credentials, tokens, and session identifiers.
  • Review request and response-body collection.
  • Apply appropriate retention policies.
  • Validate the configuration with Salesforce security and privacy owners.

Dashboard & Reports

Dashboard & Reports

AI

Insights & Recommendations

Analytics

More Analytics Features

Automation

More Automation Features

Get Help

Contact GermainUX Support

The GermainUX team helps you get up and running faster, empower your team, turn data into actionable insights, and optimize performance to deliver measurable business outcomes.

Can't find what you need?

Search all GermainUX docs with Ctrl + K, or use the feedback buttons at the bottom of this page to tell us what is missing.

The content of this document is proprietary to GERMAIN SOFTWARE.