You are deciding whether to run an engagement, or about to announce one to your organization. This page is the short version; every claim on it links to the document that backs it.
What an engagement is
A time-boxed observation of how work actually runs, ending in a map. A desktop application and a browser extension read structured interaction events inside the applications your team approves, so the processes can be described as they are rather than as documented.
It observes. It does not act. Automating a process is separate, later, and separately agreed; when it happens, flowscope acts through your systems' own interfaces, with a person approving anything consequential.
What it asks of your organization
You approve the application list, so the scope is yours. The default categories (personal banking, healthcare, password managers, personal email and similar) stay on every organization's list; your admins add entries and remove only the ones they added. The list is published in the categorical denylist.
Names are masked by default. In the product, every person shows as a masked letter label like Person A. The AI that builds the map works with these labels. Turning real names on is a logged action, taken by your organization's admin or flowscope staff. Your company owns the captured data, and it is never used to train any AI model.
Telling your staff
This is the part that determines how the engagement goes. On a managed rollout the software reaches laptops before anyone can be invited, so if nobody has told your team first, the engagement starts with a surprise on their machine.
Send them the employee guide with your announcement, before IT deploys. It opens with a short video and needs no flowscope account.
Going deeper
Counsel reviewing this will want the white paper, a provision-by-provision technical and legal overview written for prospective customers and their advisors. It is available from security@flowscope.com, along with the customer agreement and our formal information-security policies.