Help & Setup Guide

On this page

• Signing in (the default — no setup)
• Optional: use your own Azure app registration
• Troubleshooting sign-in
• Using more than one account
• 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 the three required permissions below as Delegated permissions (the fourth is optional):

Admin vs. user consent: none of the four 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.
• The Connection broken switch won't stay on — the approval window was closed, or your organization requires admin approval for the PowerApps Service User permission. An admin can grant it from Microsoft Entra → Enterprise applications → FlowOversee → Permissions; on your own registration, add PowerApps Service → User under API permissions first.
• 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.

Using more than one account

Many people have more than one work account — an everyday account and an admin account, or accounts in different organizations. FlowOversee can keep several of them signed in and switch between them without signing out. It uses one account at a time: everything on screen, and every alert, comes from the account you are signed in to at that moment.

Add, switch, and sign out

• The account item sits at the bottom of the sidebar, just above Settings, and shows the account in use. Click it to open the account menu.
• Add another account… opens the Windows account picker. Sign in with the other work account and FlowOversee switches to it. An account that has never used FlowOversee sees the same one-time read-only approval described under Signing in.
• Switch by picking any account listed in the menu — the one in use is marked. The app reloads for that account and stays on the same environment when that account can see it.
• Sign out of one account with Sign out of … in the same menu. If another account is signed in, FlowOversee moves to it; if it was the only one, the sign-in screen comes back. To sign out of every account at once, use Settings → Sign out of all accounts.

What each account keeps to itself

The things you build in FlowOversee point at specific flows, and a different account sees different flows. So these are saved on your PC separately for each account:

• Folders on the Organize Flows page
• Daily Monitor templates and their day-by-day history
• Findings you have silenced under Needs attention
• The alert history on the Alerts page
• The environments that alerts watch

Everything else in Settings is shared by all accounts: theme, display time zone, the flow filter, and the alert options — on or off, how often to check, and which triggers.

Good to know

• Alerts watch the account you are signed in to. Background checks cover that account only, in the environments chosen for it. Other accounts listed in the menu are not checked until you switch to them.
• Signing out keeps the data. Signing out of an account removes only its sign-in. Its folders, templates, history, and alerts stay on your PC and come back when that account signs in again. Settings → Reset application data removes everything, for every account.
• Switching doesn't ask for a password. Windows holds each account's sign-in, so moving between accounts you have added is immediate. If other people use your Windows login, sign out of the accounts they shouldn't reach — or turn on Settings → Require Windows Hello at launch, which locks the app as a whole.
• Backups remember their account. Backup and export files record the account they were made under. On restore, FlowOversee offers to put the data back under that account and tells you when it differs from the one in use. Back up & restore all settings covers every account you have added to FlowOversee, in one file.
• All accounts use the same app registration. With FlowOversee's built-in app (the default), accounts from different organizations work side by side. With your own app registration, only accounts that registration accepts can sign in. Changing the Tenant ID or Client ID in Settings signs you out.

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. A few 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 switched to a different account. Each account has its own folders, Daily Monitor templates, silenced findings, and alert history. After a switch those pages show the new account's items, which can be none at all if that account is new to FlowOversee. Nothing was lost — switch back from the account item at the bottom of the sidebar and everything the other account set up is there. See Using more than one account.

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, plus the folders, templates, and silenced-finding decisions of every account you have added to FlowOversee; 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.
• Alerts watch the account you are signed in to. With more than one account, each has its own list of environments to watch, and only the account in use is checked.
• 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.
• Connection alerts are a separate, optional trigger (Settings → Alerts → Connection broken). FlowOversee reads the health of the connections you own or were shared in each monitored environment and alerts when one starts reporting an error — an expired sign-in, revoked access, or a connector failure. Connections that were never fully set up (the portal reports them as needing configuration, which is normal for child-flow links) are not treated as broken. Connections already broken when monitoring starts are listed on the Alerts page without a notification. This trigger needs one extra read-only permission (PowerApps Service → User); turning it on opens a one-time Microsoft approval window, and the switch stays off until that approval completes. Each connection alert links straight to the environment's Connections page in the maker portal, where the fix is a re-sign-in.

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.