If you manage Azure Automation Accounts, you’ve probably wondered “which runbook uses this credential?” or “why did this job fail and which other runbooks are affected?” Navigating the Azure Portal to answer those questions means clicking through dozens of runbooks one by one.

Azure Automation MindMap is a free, open-source web application that connects to your Azure tenant using your own Microsoft credentials and renders your entire Automation Account as a live, interactive graph, including runbooks, variables, credentials, connections, schedules, and job history. All in one view.

In this article, I’ll walk you through setting up the application locally on your machine from scratch — including creating the App Registration in Azure Entra ID, configuring the environment, and running the app in under 10 minutes.

What Does The Automation MindMap Capture

Runbook Static Analysis (from script content):

  • Asset dependencies — which Variables, Credentials, Certificates, Connections each runbook uses (Get-AutomationVariable, Get-AutomationPSCredential, etc.)
  • Key Vault references — Get-AzKeyVaultSecret calls with vault name, secret name, -AsPlainText risk flag
  • Azure VM operations — Start-AzVM, Stop-AzVM, etc.
  • Web requests — Invoke-WebRequest, Invoke-RestMethod calls with URLs
  • Child runbook calls — Start-AzAutomationRunbook chains
  • Email/notification usage — Send-MailMessage, MS Graph mail calls
  • Storage operations — Azure Blob/Storage access
  • SQL operations — database connection patterns
  • RunAs account usage — deprecated service principal auth pattern
  • Hardcoded secrets — direct password assignments AND ConvertTo-SecureString "..." -AsPlainText (including via variable indirection)
  • PowerShell cmdlets — categorized (Azure, FileSystem, Network, Process, Service, AD, etc.)
  • PowerShell functions — defined function names with line numbers
  • Broken dependencies — assets referenced in script but not found in the account.

Operational Monitoring:

  • Job execution history — 7/30-day success/failure/other trend chart
  • Schedule health — next run time, missed runs, expiry status
  • Run Now capability — triggers runbook directly from the UI

Infrastructure Context

  • Subscription & Resource Group scoping
  • Source control integrations — GitHub / Azure DevOps links
  • Azure Portal deep links — for every resource node in the graph

What You Will Learn

  • How to register an application in Azure Entra ID with the correct permissions
  • How to clone and configure the project
  • How to run the app locally using the SetupLocal.ps1 script
  • A tour of the three main views: Runbooks, Objects, and Table

Prerequisites

Before you begin, make sure you have:

  • Node.js 20 LTS — nodejs.org
  • Git — git-scm.com
  • PowerShell 5.1+ (built into Windows)
  • An Azure subscription with at least Reader access
  • An Azure Automation Account with some runbooks
  • Permission to create App Registrations in your tenant (or ask your admin)

Step 1 — Create an App Registration in Azure Entra ID

Azure Automation MindMap uses MSAL (Microsoft Authentication Library) to sign you in with your own Azure account. It never stores credentials — it reads your Automation Account on your behalf using delegated permissions, so no need for persistent permissions or application permissions.

You need a Single-Page Application (SPA) App Registration with one API permission.

1.1 — Create the Registration

  1. Go to portal.azure.com → search for Microsoft Entra ID
  2. Click App registrations → + New registration
  3. Fill in:
    • Name: AutomationMindMap (or any name you prefer)
    • Supported account types: Accounts in this organizational directory only
    • Redirect URI: Select Single-page application (SPA) and enter http://localhost:3000
  4. Click Register

1.2 — Copy the IDs

After the registration is created, you land on the Overview page. Copy these two values — you’ll need them in Step 3:

  • Application (client) ID
  • Directory (tenant) ID

1.3 — Add the API Permission

  1. Click API permissions → + Add a permission
  2. Choose Azure Service Management
  3. Select Delegated permissions → tick user_impersonation
  4. Click Add permissions
  5. Click Grant admin consent for [your tenant] → Yes

⚠️ Admin Consent Required
If the Grant admin consent button is greyed out, you don’t have the Global Administrator or Privileged Role Administrator role. Ask your Azure AD admin to grant consent, or use an account with those roles.

Step 2 — Assign Reader Role on the Automation Account

The app reads Automation Account data on behalf of the signed-in user. The user must have at least Reader access on the Automation Account (or on the subscription).

  1. Go to your Automation Account → Access control (IAM)
  2. Click + Add → Add role assignment
  3. Select role: Reader
  4. Under Members, select the user(s) who will use the app
  5. Click Review + assign

💡 Subscription-level Reader is also fine. If the user already has Reader on the subscription, they automatically have it on all resources including the Automation Account.

Step 3 — Clone the Repository

Open a PowerShell window and run:

git clone https://github.com/farismalaeb/AutomationMindMap.git
cd AutomationMindMap

If you prefer to use Azure Web App to host it locally in your azure subscription, the follow this article for the step by step deployment (Azure Web App Setup)

Step 4 — Run SetupLocal.ps1

The repository includes a SetupLocal.ps1 script that handles everything in one shot: it creates the .env.local configuration file and installs all Node.js dependencies.

Run it with the two IDs you copied in Step 1.2:

.\SetupLocal.ps1 `
    -ClientId "5b240315-e370-421a-b83b-14fc7453c31b" `
    -TenantId "66461842-b20a-47ac-9f0d-c9030990d593"

The script will:

  1. Verify you are in the correct project directory
  2. Check that Node.js v20+ is installed
  3. Create .env.local with your Client ID and Tenant ID
  4. Run npm install to install all dependencies

💡 Tip — Start the dev server immediately
Add the -StartDev flag to launch the dev server automatically after setup:

.\SetupLocal.ps1 -ClientId "..." -TenantId "..." -StartDev

Step 5 — Start the Development Server

If you didn’t use -StartDev, start the server manually:

npm run dev

You should see output like:

▲ Next.js 16.1.6 (Turbopack)
  - Local:        http://localhost:3000
  - Ready in 1234ms

Open http://localhost:3000 in your browser.

Test PowerShell scripts are also available to play with, you get them all from the Test Runbook

Step 6 — Sign In

The app opens on a sign-in screen. Click Sign in with Microsoft Entra ID.

You’ll be redirected to the Microsoft login page. Sign in with your Azure account. After authentication, you’ll be redirected back to http://localhost:3000.

Exploring the App — Three Views

Once the data loads, you have three views to explore your Automation Account:

Runbooks View

The default view. Each runbook is a central node connected to all the assets it uses — variables, credentials, connections, certificates, and schedules — as branches.

Click any runbook node to open the Detail Panel on the right, which shows:

  • Runbook description and type (PowerShell Runbook only)
  • Last job status with timestamp
  • Schedule information
  • Latest 10 job history entries with load-more
  • Security analysis (hardcoded credentials, deprecated RunAs accounts)
  • Detected dependencies (HTTP calls, VMs, databases, child runbooks)

Objects View

A flipped perspective — assets are the roots, and the runbooks that use each asset are the branches. This is useful for answering: “Which runbooks will break if I delete this credential?”

Click on the image to enlarge

Table View

A traditional tabular list of all runbooks with sortable columns. Expand any row to see the full detail card inline — useful for bulk review or sharing with non-technical stakeholders.

Job History

The detail panel loads the last 10 jobs for any runbook you click. Status highlights:

StatusColour
FailedRed row background
Completed w/ ErrorsAmber row background (completed status but error streams found)
CompletedDefault — clean completion

Click Load 10 More to page through older jobs.

Basic Best Practices Tracking

One of the most useful features is the built-in security scanner. It analyses each runbook’s PowerShell source code and flags:

The script is not analyized or sent anywhere, all the analyzes is done locally in the app and no AI yet

  • Hardcoded passwords or secrets (e.g., $password = "...", ConvertTo-SecureString "...")
  • Plain-text credential patterns

Common Issues

SymptomLikely CauseFix
AADSTS50011 error on loginRedirect URI not registeredAdd http://localhost:3000 in App Registration → Authentication → SPA
AADSTS700054 — response_type not enabledApp Registration is not configured as SPADelete the existing redirect URI and re-add it under Single-page application platform
Subscriptions list is emptyAdmin consent not grantedGrant admin consent for user_impersonation in App Registration → API permissions
Automation Accounts list is emptyNo Reader role on subscription or Automation AccountAssign Reader role in IAM on the Automation Account
White screen after sign-in.env.local has wrong Client ID or Tenant IDRe-run SetupLocal.ps1 with the correct IDs, restart the dev server
npm run dev fails — missing modulesnpm install was not runRun npm install from the project root

Summary

The application is 100% read-only — it only calls Azure ARM REST API GET endpoints using your own delegated token. No data is ever written, and no credentials are stored.

The project is open source on GitHub. If you’d like to deploy it as a permanent internal web app, see the Azure Web App Setup Guide linked in the repository. Pull requests and issues are welcome!

Resources

Rate this post