Help & Setup Guide

On this page

• Set up the Azure app registration
• Troubleshooting sign-in
• Why what you see might not match what you expect
• Flow states, explained
• Alerts & background monitoring
• Getting support

Set up the Azure app registration

FlowOversee uses delegated, read-only permissions and the native Windows account broker — there is no client secret to manage and no browser redirect to a local server. Because sign-in goes through the Windows broker, your tenant's Conditional Access and MFA policies apply as normal; FlowOversee cannot bypass them.

Before you start

• Access to the Azure Portal (portal.azure.com) for your tenant, signed in as someone who can register applications — or who can ask an admin to grant consent.
• Know whether your org requires admin consent for app permissions. FlowOversee only asks for read-only, user-consentable permissions, but some tenants require admin consent for everything by policy.

Step 1 — Create the registration

1. portal.azure.com → Microsoft Entra ID → App registrations → New registration.
2. Name: FlowOversee (anything you like — users never see it).
3. Supported account types: Accounts in this organizational directory only (single tenant) is the usual choice. Pick multi-tenant only if FlowOversee will sign in users from other tenants.
4. Redirect URI: leave it blank here — you'll add the desktop/broker URI in step 2.
5. Register.

The Overview blade now shows the two IDs you'll need: the Application (client) ID goes into the redirect URI at step 2, and both it and the Directory (tenant) ID go into FlowOversee at step 4. Keep this blade handy.

Step 2 — Add the redirect URI

1. In the registration: Authentication → Redirect URI configuration → Add Redirect URI → Mobile and desktop applications.
2. Under Custom redirect URIs, add this, replacing {client-id} with the Application (client) ID from the Overview blade:

ms-appx-web://microsoft.aad.brokerplugin/{client-id}

3. Save.

This is the WAM broker redirect URI — the URI Windows' native account broker hands the sign-in response back through.

Step 3 — Grant API permissions (delegated)

Go to API permissions → Add a permission → APIs my organization uses, and add all three of the following as Delegated permissions:

Admin vs. user consent: none of the three permissions requires admin consent under Entra's defaults — the Graph scope reads basic profiles only (display name, UPN), which is exactly why FlowOversee requests it instead of the admin-consent-gated User.Read.All. Tenant policy can still require admin consent for everything, though.

• If you're a tenant admin, click Grant admin consent after adding the permissions — it saves every user an individual consent prompt either way.
• If you're not, and your tenant allows user consent, FlowOversee will prompt for consent on first sign-in. Otherwise ask an admin to grant it.

Step 4 — Enter your IDs in FlowOversee

1. Launch FlowOversee. The first-run wizard asks for the Tenant ID first, then the Client ID — both from the Overview blade you kept open at step 1 — then Sign in.
2. Sign-in uses the Windows account broker — pick the work account already on the machine. No browser tab; no password prompt if you're already signed into Windows with that account.
3. You can change these later in Settings → Account; FlowOversee applies the change live, no restart needed.

Troubleshooting sign-in

• AADSTS50011 (redirect URI mismatch) — the broker URI from step 2 doesn't match exactly. Re-check the {client-id} value and that it's registered under Mobile and desktop applications.
• "Need admin approval" / consent_required — an admin must grant consent for the step-3 permissions (or your tenant must allow user consent).
• Sign-in dialog never appears / fails silently — confirm a work account exists on the machine, and if needed set Allow public client flows = Yes (step 2).
• Flow creators show as GUIDs instead of names — Graph User.ReadBasic.All wasn't granted or consented.
• No desktop flows appear — Dynamics CRM user_impersonation wasn't granted or consented, or the environment has no Dataverse.

Why what you see might not match what you expect

FlowOversee never caches your flow data — every load pulls fresh from Microsoft's services, so what you see is current as of the last refresh. Two behaviors are worth knowing about:

• You have a flow filter set. Settings lets you include or exclude flows by name pattern, and the filter applies everywhere in the app. Any page affected by it shows a "Filter active" banner with a one-click Clear — if a flow seems missing, check for that banner first.
• Suspended flows surface a moment after everything else. The flow-list API reports suspended flows as merely "Stopped" — only each flow's detail carries the true state. FlowOversee fetches that detail and corrects the state, so during a load a suspended flow can briefly appear under Stopped before moving to Suspended once its detail arrives, with the suspension reason shown in its details.

Flow states, explained

The dashboard sorts flows so problems surface first. The summary tiles partition every visible flow into exactly one of these:

Cloud and desktop flows are grouped separately in the list ("Cloud — …" and "Desktop — …" section headers), and the Desktop Flows toggle in the header hides or shows desktop flows everywhere.

Alerts & background monitoring

• Alerts are off until you turn them on (Settings → Alerts). You pick the environments to watch, the triggers that matter, and the check pace — from every 2 minutes to hourly.
• FlowOversee must be running for alerts to fire — minimized to the taskbar is fine, but it has no service or scheduled task that runs when the app is closed. That's a deliberate part of being local-first.
• Background checks use silent sign-in only — they will never pop a credential prompt while you're working. If your session expires and needs interactive sign-in, background checks pause until you bring up the app and sign in again.
• New alerts show as Windows toast notifications and collect on the Alerts page, with a badge on the navigation item.

Getting support

Start with the sections above — the setup walkthrough and sign-in troubleshooting cover nearly everything that goes wrong. Still stuck? Email contact@flowoversee.com with a short description of the problem or question.

FlowOversee is an independent project built and maintained by one person. Support is best-effort: a reply, timeline, or fix can't be promised.

Please don't attach log files, screenshots of your flows, or anything else from your environment. FlowOversee is local-first and sends nothing to the developer on its own — anything that leaves your machine is something you chose to send, and less is better. See the Privacy Policy for the full picture.