Help & Setup Guide

On this page

• Signing in (the default — no setup)
• Optional: use your own Azure app registration
• Troubleshooting sign-in
• Why what you see might not match what you expect
• Flow states, explained
• The Daily Monitor
• Alerts & background monitoring
• Getting support

Signing in (the default — no setup)

Out of the box, FlowOversee signs in with an app registration published and maintained by FlowOversee LLC, shown on the Microsoft consent prompt as a verified publisher. There is nothing to create in Azure: launch the app, pick your work account, and approve the read-only permissions listed on the prompt.

• Creator names are a separate, optional approval. Microsoft grants permissions per service, so after sign-in the setup wizard offers one more optional approval that lets FlowOversee show flow creators as names instead of IDs. It's a single approval window, only ever opened when you click the button — skip it and everything else works, and it stays available later under Settings → Creator names.
• Your data still never leaves your machine. The app ID only identifies the application to Microsoft — sign-in happens between this device and your organization's Microsoft tenant, tokens are issued to you on this device, and FlowOversee LLC is never in the path and can see nothing.
• Your organization stays in control. The first sign-in creates a FlowOversee entry under your tenant's Enterprise applications, where admins can review, restrict, or revoke it — and your tenant's Conditional Access and MFA policies apply as normal.
• Some organizations require an admin's approval for any new app. If the consent prompt says "Need admin approval," forward it to your admin — one approval covers the whole organization.
• Windows may ask "Stay signed in to all your apps?" on first sign-in. That dialog belongs to Windows, not FlowOversee — either answer works; "No, this app only" is the conservative choice on shared machines.

Optional: use your own Azure app registration

Prefer an app identity your organization owns — for Conditional Access scoping, auditing under your own name, or policy reasons? FlowOversee works identically with your own registration: same read-only permissions, same local-only storage. Expand "Use your own app registration" on the first-run sign-in step (or edit the IDs later in Settings → Account) once you've completed the steps below.

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 — it appears on your users' consent prompt).
3. Supported account types: Accounts in this organizational directory only (single tenant) is the usual choice, paired with your tenant GUID in FlowOversee. Pick multi-tenant only if FlowOversee will sign in users from other tenants — and note the literal common Tenant ID works only with a multi-tenant registration. Never pick the "+ personal Microsoft accounts" variant: personal accounts have no Power Automate environments, so FlowOversee requires a work or school account in a Microsoft Entra tenant.
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 the native Windows 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 Microsoft Entra defaults — the Microsoft 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. On the first-run sign-in step, expand "Use your own app registration" — it reveals the Tenant ID input 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 — the Microsoft Graph User.ReadBasic.All permission hasn't been consented yet. FlowOversee never interrupts you over this (it quietly falls back to the GUID). To fix it yourself, open Settings → Creator names → Enable — a one-time Microsoft approval window appears; approve it and names resolve from then on. If that window says "Need admin approval," your organization restricts user consent — an admin can grant the permission from Microsoft Entra → Enterprise applications → FlowOversee → Permissions, which covers everyone at once.
• No desktop flows appear — Dynamics CRM user_impersonation wasn't granted or consented, or the environment has no Dataverse.
• Asked to approve again later — Microsoft consents per service, so opening desktop-flow data for the first time can show one more consent prompt for Dynamics, and creator names have their own optional approval (offered in the setup wizard and under Settings → Creator names). Each is a one-time approval; none of them recurs once granted, and FlowOversee only ever opens an approval window from a button you click.
• Windows asks "Stay signed in to all your apps?" — a Windows dialog, not FlowOversee; see Signing in. Either answer works.

Why what you see might not match what you expect

FlowOversee never caches flow statuses, counts, or run times — every load pulls them 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.
• An environment or someone else's flow is missing. FlowOversee sees exactly what the signed-in account can see: environments where the account holds a role (backed by a Dataverse database), cloud flows the account created or that are shared with it, and desktop flows that have been published. A missing environment usually means the environment has no Dataverse database yet, or the account holds no role there — see why an environment does not appear. A missing flow is usually another maker's flow that has not been shared with the signed-in account — see why a flow does not appear, which ends with a step-by-step checklist.
• 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.
• You signed in with a different Microsoft account. Your monitored flows, folders, and alert history are stored on this PC and are tied to the flows the signed-in account can see. If you sign in with a different work account (Settings → Sign out, then sign in again), items added under the other account can show as "Not found" or "Missing" — they aren't lost or deleted, and they'll work again the next time the original account signs in. If the switch is permanent, remove the flagged items and re-add them under the new account, or use Settings → Reset application data for a clean start (take a settings backup first if you want to preserve anything).

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.

The Daily Monitor

The Daily Monitor is a per-day checklist for the flows you care about: pick them once, and each day FlowOversee checks every one against its actual run history and marks it Completed, Failed, Not run, Pending, and so on. Decided outcomes are saved locally and aren't re-pulled when you come back to the page. The in-app ? button on the page explains every status and control in place; the essentials:

• Expected times respect the flow's own time zone. A scheduled flow's expected run time is computed in its schedule's source time zone; flows without one use your display time zone from Settings, and you can pin a specific zone per flow. A late start within the grace window (15 minutes, tighter for high-frequency schedules) still counts for its slot.
• Templates are named monitor lists per environment — for example "Monday–Friday jobs" and "Month-end" — each with its own day-by-day history. Switch between them from the dropdown on the page.
• Templates back up to a file. The template menu saves the active template — or every environment's — as a JSON file, and restores them later; a restore replaces same-named templates and adds the rest. Resetting or uninstalling the app deletes templates with the rest of its local data, so take a backup first (there's a Back up button right next to Reset in Settings). Recorded day-by-day history stays local-only and isn't part of a backup. Settings also offers Back up & restore all settings — one file holding every setting, folder, template, and silenced-finding decision; sign-in and license acceptance are never included, so restoring signs you out and re-presents the license agreement.
• Build the list your way: pick flows in-app, or import a CSV/JSON file. The Dashboard's flow export produces exactly the import format, so exporting an environment and trimming the file is the fast path. Flows that don't exist in the current environment are skipped at import.
• Manual calls stick. You can set a flow's status by hand with a note (say, "ran on the backup machine"); manual statuses are never overwritten by an automatic re-check.
• History is local — one small file per day per template on your PC (see the Privacy Policy for exactly what's stored), viewable up to 27 days back and cleaned up after 28 days unless you turn cleanup off in Settings.

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.
• Alerts stay until you dismiss them — closing or restarting the app (or a Windows restart) doesn't clear the Alerts page or its badge, so nothing raised while you were away goes unseen.

Getting support

Start with the sections above — the setup walkthrough and sign-in troubleshooting cover nearly everything that goes wrong. Still stuck? Email [email protected] with a short description of the problem or question.

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.