For the team clearing a rollout: what the software talks to, how traffic is secured, how a device authenticates, and where captured data goes. Install steps are in Deploying the desktop application with Microsoft Intune, Deploying the desktop application with the Windows installer and Rolling out the browser extension.
Outbound destinations to allow
If outbound traffic from the fleet is filtered by destination, allow these hosts. All are standard HTTPS on port 443, and none pin certificates, so a TLS-inspecting proxy can decrypt them without special handling.
| Destination | Purpose |
|---|---|
app.flowscope.com | Capture event ingestion, device pairing and sign-in, and desktop application auto-update |
stflowscopeextrel.blob.core.windows.net | Browser extension update manifest and package download |
stflowscopeagentrel.blob.core.windows.net | Desktop application installer and auto-update bundles, reached via a short-lived signed link minted by app.flowscope.com |
The desktop application host is reached through a redirect from app.flowscope.com, so without it on the allowlist the desktop application's install and self-update will fail behind a destination filter.
As a plain list for a firewall ruleset:
app.flowscope.com
stflowscopeextrel.blob.core.windows.net
stflowscopeagentrel.blob.core.windows.net
The device only reaches out.
How traffic is secured
All traffic to app.flowscope.com is HTTPS, terminated at Azure Front Door with managed certificates, with TLS 1.2 minimum and TLS 1.3 where the client supports it. The desktop application's network calls, including its auto-update check, go through a native HTTPS client rather than an embedded browser, so they are not affected by any in-app content policy.
How a device is authorized
A capture surface cannot send anything until it is paired to your organization. Pairing is a browser handshake in which the participant signs in with their work account and confirms; it provisions a credential unique to that device. Every subsequent request carries that credential, and the server resolves the specific device before accepting anything.
- The credential is per device. No shared key is baked into the software, so nothing in a distributed build is valid for another customer or machine.
- It is revocable. An admin can revoke a device from the dashboard at any time; its requests are then rejected immediately and it must pair again to return.
Administrators sign in to the dashboard through your own identity provider (Google Workspace or Microsoft Entra ID for customer staff), not a flowscope-managed password.
The path captured data takes
Captured activity is minimized in layers before it comes to rest:
- On the device, before anything is sent: capture is confined to the customer's allowlist, the denylist categories are excluded entirely, password fields and token-bearing URL parameters are dropped, personal data with a checkable format is masked.
- In transit: over the TLS channel above, authenticated by the device credential.
- On the server, before storage: an always-on layer, run by flowscope or by a subprocessor under contractual zero data retention and data-protection obligations at least as protective as those in the customer agreement, masks a broader set of personal data, such as names.
- At rest: a managed PostgreSQL database on Microsoft Azure, encrypted at rest.
The capture model is accessibility-tree events. Subprocessors are listed on the subprocessors page.
Endpoint execution controls
The extension installs by browser policy; the desktop application installs per user, with the Defender ASR exclusion in the Intune guide where that rule is in Block mode.