Brief Overview

When configuring a WalkMe extension, you use regex to define which domains WalkMe should inject into. This article covers general regex guidelines and platform-specific examples for Salesforce, Workday, and SuccessFactors.

General Guidelines

Be specific but flexible

Regex should be as specific as possible while still working across different pages. Use customer-specific prefixes to achieve this balance.

Use different regex for each environment

Each environment must have its own unique regex. Use prefixes to differentiate between production and sandbox.

Always wrap regex with .*

Begin and end every regex string with .*

Replace numbers with .*

Instead of using specific digits, use .* in their place.

Escape periods with \

Always put a \ before every period.

Don't escape hyphens

Use (first|second) for multiple prefixes

To include a URL with two or more different prefixes, use (first|second|third) where the prefixes occur.

Use negative lookahead to exclude words

To exclude a specific word from a match, use (?!word).

Combine multiple regex with |

To include more than one regex in a package, separate each with | and no spaces.

Regex is case sensitive

Always match the exact case of the URL in your regex.

Stricter Domain Regex

In some cases you may need to restrict injection to a specific iFrame while preventing WalkMe from loading in other iFrames that reference the same domain.

^https?://[^/]*(visual\.force)\.com

App-Specific Regex

Salesforce

Salesforce extensions require extra care due to the variance across pages and the presence of analytics iFrames.

When creating the extension:

• Use negative lookahead to avoid session server and other unnecessary injections: (?!/(login/sessionserver|s\.gif)
• Use "or" logic within a package rather than creating two separate extensions
• The server prefix ("na", "ap", "eu", "cs") generally stays the same — stick with the URL you have

Test environments

Salesforce Classic:

.*customername.*\.cs.*\.my\.salesforce\.com.*|.*cs.*\.salesforce\.com/(?!console).*|.*cs.*\.visual\.force\.com.*

Salesforce Lightning:

.*cs.*\.lightning\.force\.com.*

Salesforce Console:

.*cs.*\.salesforce\.com/console.*

Production environments

Salesforce Classic:

.*customername\.my\.salesforce\.com.*|.*na.*\.salesforce\.com/(?!console).*|.*na.*\.visual\.force\.com.*

Salesforce Lightning:

.*na.*\.lightning\.force\.com.*

Salesforce Console:

.*na.*\.salesforce\.com/console.*

Workday®

Test: .*impl\.workday\.com/customername.*

Production: .*myworkday\.com/customername.*

SuccessFactors

Test: .*hcm.*preview\.sapsf\.com.*

Production: .*performancemanager.*\.successfactors\.com.*

Distinguishing Between Similar URLs

When configuring extensions for platforms with similar URLs — for example, standard Salesforce and Salesforce Service Cloud — use regex to differentiate between them.

Normal SFDC URL: https://cs2.salesforce.com/home/home.jsp?tsid=02u0000000000hV

Service Cloud URL: https://cs2.salesforce.com/console?tsid=02u50000000e56v

The difference is the word "console" appearing after salesforce.com. Use this to your advantage:

Service Cloud regex:

.*cs2\.salesforce\.com/console.*

For SFDC, use negative lookahead to exclude any URL where "console" follows salesforce.com:

SFDC regex:

.*cs2\.salesforce\.com/(?!console).*

This matches https://cs2.salesforce.com/home/home.jsp but not https://cs2.salesforce.com/console.