These steps come before the deploy. Most are agreed with your flowscope contact; the technical prerequisites are on IT.
Agree the shape
Agree three things with flowscope, in writing:
- The cohort: which employees take part. A small, named, opted-in group, not the whole company.
- The period: how long capture runs, generally four weeks.
- The goal: the workflows or area of the business you want understood.
Separately, give whatever workplace-monitoring notice applies in your jurisdiction before anything is installed. flowscope provides the participant-facing agreement and materials, but informing the cohort and any legally required notice or consent are your organization's responsibility (Discovery trust addendum).
Decide the capture scope
flowscope only observes the applications and websites on an allowlist you control. Anything outside it produces no captured content, only a content-free measure of active time that names no application or site, so this is the decision that bounds the engagement.
You do not have to compile that list yourself. flowscope proposes one from the systems you name for the target workflows, and you confirm, amend, or replace it. During the engagement flowscope keeps it current: business systems that fall inside the workflow scope you confirmed are added for you, and anything it cannot place with confidence waits for your decision. Reviewing those is the one recurring job the engagement asks of you, because a real system left waiting is a workflow missing from the map. You can turn the automatic additions off on the allowlist page, after which every addition waits for you.
While scope is still being decided, the bare name of an unlisted application or site can be reported once to the engagement admin's scoping review, with no timing, no duration, and no link to any participant. Denylisted software is never named.
A permanent denylist overrides the allowlist regardless of how it is set, covering personal banking, brokerage, and payment sites, healthcare portals, password managers, encrypted messengers, personal email, legal portals, government services portals, and private browsing. You can extend it; neither you nor flowscope can shrink it below its default. The participant-facing view is in Your privacy and controls, and the full posture is in the Discovery trust addendum.
Technical prerequisites
Confirm on the IT side before scheduling the deploy:
- The cohort's devices are enrolled in Intune and Microsoft Entra joined (or Entra hybrid joined). This matters for force-installing the browser extension.
- There is an Entra user group of the engagement's participants to assign the agent to, and an Entra device group of their endpoints to target the extension policy at.
- You know the default browser on those machines, so you ship the Edge policy, the Chrome policy, or both.
- The admin running the dashboard has access to your flowscope organization. flowscope creates it and grants access; first sign-in is the admin's work account through your own Microsoft Entra, with no separate flowscope password.
Deployment mechanics are in Deploying the desktop agent with Microsoft Intune and Rolling out the browser extension; what your security team will want to clear is in Network and security requirements.
Before you deploy
You should have:
- the cohort, period, and goal agreed with flowscope;
- the proposed capture allowlist confirmed, and any business-specific denylist additions noted;
- devices Entra-joined, the user group and device group created, and the default browser known;
- dashboard access confirmed for the admin running the rollout.