Browser extension: Guidely on apps you don't own
The Guidely browser extension runs guides, checklists, the Scout messenger, page analytics and (optionally) session replay on third-party web apps your company uses but can't change: Salesforce, Workday, ServiceNow, SAP, vendor tools. IT installs it on managed Chrome and Edge browsers by policy, with your project key, the sites to run on and how to recognise the signed-in employee. Nothing is installed inside the third-party app.
It runs the same SDK as the script tag, so the dashboard, guide editor, targeting, analytics and Scout work exactly as for an embedded install: create a project (or an environment) for the third-party app, author guides with page restrictions on its paths, and publish.
| Browsers | Chrome and Edge 111+ (Manifest V3). Firefox and Safari are not supported yet. |
| Source | apps/extension in the Guidely repository (pnpm --filter @guidelytech/extension build / package) |
| Distribution | Your private Chrome Web Store / Edge Add-ons listing, or a self-hosted .crx on managed devices |
| Full reference | apps/extension/README.md (architecture, every policy format, troubleshooting) |
How it works
- Only on allowed hosts. The extension injects Guidely into a tab only when the page's host matches
allowedHostsfrom the policy (*.lightning.force.com,acme.service-now.com, …), and only sends data to your GuidelyapiUrl. - Isolated from the page. The SDK runs as an extension content script: it shares the page's DOM but not its JavaScript, so the app can't tamper with it and the app's Content-Security-Policy for scripts doesn't apply. No remote code is ever loaded.
- CSP and CORS-proof networking. The SDK's requests go through the extension's service worker, which only talks to
<apiUrl>/api/v1/sdk/…, never sends cookies and never follows redirects. A strictconnect-srcon Salesforce or ServiceNow therefore doesn't block Guidely. - Shadow DOM. Selectors with
>>>pierce shadow roots (Salesforce Lightning web components, ServiceNow Next Experience), in guide targets and in the identity DOM strategy. - SPA navigation is followed through the browser's Navigation API, so page rules and page analytics work on single-page apps.
Configure it (enterprise policy)
Every setting comes from chrome.storage.managed (the extension ships a managed-storage schema), or from the extension's options page when there is no policy (for testing). When the policy sets any key, it is the whole configuration and the options page becomes read-only.
{
"projectKey": "pk_prod_8f2c…",
"apiUrl": "https://guidelytech.com",
"allowedHosts": ["*.lightning.force.com", "*.my.salesforce.com", "*.myworkdayjobs.com", "*.service-now.com"],
"identity": { "source": "policy", "email": "ada@acme.com" },
"accountFrom": { "source": "policy", "userId": "acme-emea" },
"traits": { "region": "EMEA" },
"autocapture": true,
"sessionReplay": false
}
| Key | Default | Meaning |
|---|---|---|
projectKey | – | Environment public key (pk_…). Required. |
apiUrl | https://guidelytech.com | Your Guidely URL; the only place data is sent. |
allowedHosts | [] | Hosts to run on: app.example.com, *.example.com (subdomains), host:8443. Required. |
identity / accountFrom | {"source":"none"} | How to find the user / account id (below). |
traits | {} | Static traits for every user. Every identify also carries extension: true, extensionVersion and host. |
autocapture, sessionReplay, authoring | true, false, true | Switch capabilities off for the extension (the project settings decide what is on). |
allFrames, allowInsecure, maskSelectors, environment, enabled, debug | See the README. |
Install it with ExtensionInstallForcelist / ExtensionSettings, and put the configuration under the extension's 3rdparty policy:
- Chrome, Windows:
HKLM\Software\Policies\Google\Chrome\3rdparty\extensions\<id>\policy(GPO registry preferences or Intune); per-user values underHKCU. - Chrome, macOS: a configuration profile for the domain
com.google.Chrome.extensions.<id>. - Chrome, Linux:
/etc/opt/chrome/policies/managed/*.jsonwith a3rdparty.extensions.<id>object. - Google Admin console: Devices → Chrome → Apps & extensions, force-install by ID and paste the configuration (each value wrapped in
{"Value": …}) under Policy for extensions. - Edge: the same policies under
Software\Policies\Microsoft\Edgeandcom.microsoft.Edge.extensions.<id>.
The README has complete registry, .mobileconfig, Linux and Admin-console examples.
Allowed origins. The extension's requests carry Origin: chrome-extension://<id> (shown on its options page). If the environment restricts allowed origins (Settings → Environments), add it.
Identify the employee
| Strategy | Example | Use when |
|---|---|---|
policy | {"source":"policy","email":"ada@acme.com"} | Your MDM writes a per-user policy (Jamf payload variables, an Intune/GPO logon script under HKCU). The most reliable option. |
dom | {"source":"dom","selector":"c-guidely-user >>> [data-user-email]","attribute":"data-user-email"} | The app renders the user's email or id somewhere stable. >>> pierces shadow roots; retried while the page loads. |
global | {"source":"global","path":"g_user.userName"} | The app exposes a page global (ServiceNow UI16 g_user). Read by a fixed function in the page; no code is evaluated. |
cookie | {"source":"cookie","name":"user_id","regex":"^u_(.+)$"} | A non-HttpOnly cookie holds the id. |
none | {"source":"none"} | Anonymous visitors only. |
regex extracts part of the value (first capture group). An id that looks like an email is also sent as the email trait. Salesforce Lightning has no reliable page global for the current user; use policy, or add a tiny Lightning component that renders data-user-email and point a dom strategy at it. Workday exposes nothing public: use policy or a verified dom selector.
Privacy and limits
- What is captured follows the Guidely project's settings (autocapture, replay masking, allowed data); the policy can only turn things off. Text inputs are always masked in replays.
- Errors thrown by the third-party app's scripts are not reported, and feature flags are not polled.
- Session replay records the DOM only (no console or network) and is off unless both the policy and the project turn it on.
- A strict page
style-src/img-srccould block guide styles or images; cross-origin iframes needallFramesand an allowed host; closed shadow roots can't be targeted. - The visual designer (
?guidely_authoring=…) depends on the app keeping that URL parameter through its own redirects.