Tutorials & How-Tos – Elijah R. Young

Module 3: Capture Requirements | Design-First Delivery

Alan Williams — Fri, 20 Feb 2026 14:05:29 +0000

Module 3: Capture Requirements | Design-First Delivery | elijah.ai

← Index | ← Module 2 | Module 3 | Module 4 Next →

Module 3: Capture Requirements

What You're Actually Building

What this module covers: Requirements aren't bureaucracy. They're the guardrails that keep you from building the wrong thing—or building it in a way that breaks governance or security. Here's how to capture functional and non-functional requirements, run effective sessions, and get stakeholder sign-off.

Source: Work with requirements, Discover customer needs (Microsoft Learn)

Functional vs Non-Functional: What to Capture

It's useful to separate these. Functional = what the solution does. Non-functional = how it does it (performance, security, access, compliance). Both matter. Skip one and you'll hit surprises later.

Type	What to capture	Example
Functional	What the app or flow must do. Features. Behaviors.	"User can submit a request and see status within 24 hours." "Flow sends approval email when amount exceeds $500."
Non-functional	How it performs, who can access it, how it fits governance.	"Only HR can see PII." "Flow must complete within 5 minutes." "Must be audit-ready for SOC 2."

Leading a Requirement Capture Session

You don't need to be a professional facilitator. You need to ask good questions and write things down. Here's a simple structure.

Before the session

[ ] You've invited the right people. Business owner, key users, maybe someone from governance if you know it touches sensitive data.
[ ] You've sent a short agenda. "We're going to capture what this solution needs to do. Bring your questions and examples."
[ ] You have a place to capture. Doc, OneNote, whiteboard—whatever your org uses.

During the session

[ ] Start with the problem statement you wrote in Module 2. "We're solving X. Does that still sound right?"
[ ] Ask: "What must this do?" List every "must." Be specific. "User can submit" vs "User can submit a request with attachments and receive a confirmation within 5 seconds."
[ ] Ask: "Who can see what?" Access, privacy, compliance. This is where non-functional requirements show up.
[ ] Ask: "What would break if we didn't have this?" Helps prioritize.
[ ] Write it down in real time. Don't trust your memory. Read it back: "So I'm hearing that…"

After the session

[ ] Organize what you captured into functional and non-functional.
[ ] Send it back to the group. "Here's what I captured. Correct anything that's wrong. Add anything we missed."
[ ] Get confirmation before you start building. "We're building to this. Yes?"

Discovery Questions (If You're Stuck)

Sometimes stakeholders say "we just need an app" without specifics. These questions help:

Who does the first step today? What do they do? What do they need to see?
What happens when something goes wrong? Who gets notified? Who fixes it?
What data does this touch? Where does it live today? Who can access it?
What would "done" look like? How would you measure success?
Are there rules we have to follow? Compliance? Audit?

Requirement Capture Checklist

[ ] You've run at least one requirement capture session with stakeholders.
[ ] Functional requirements are documented. (What the solution does.)
[ ] Non-functional requirements are documented. (Security, performance, access, compliance.)
[ ] Requirements are confirmed and finalized with the business owner before build.

Next Step

With requirements in hand, move to Module 4: Design the Solution. That's where you decide data structure, app type, and where logic lives—all before you open the tool.

← Index | ← Module 2 | Module 3 | Module 4 Next →

Power Automate Flow Troubleshooting Checklist

Alan Williams — Mon, 16 Feb 2026 14:33:24 +0000

Power Automate Flow Troubleshooting Checklist | elijah.ai

Power Automate Flow Troubleshooting Checklist

Why this exists: A flow fails. You stare at the run history. Where do you even start? This checklist keeps you from spinning.

For you if: You build or support Power Automate flows and sometimes hit a wall when something breaks.

Ground truth: Built from Troubleshoot a cloud flow, Employ robust error handling, and Troubleshoot cloud flows.

Before You Dig In

[ ] When did it last succeed? If it worked yesterday and failed today, something changed. Update? Connector change? Data change?
[ ] Is it the first run or a rerun? First run failures are often config. Reruns that used to work point to data or permissions.
[ ] Which step failed? Don't guess. Open the run, look at the red step. That's your starting point.

Step-by-Step: The Failed Action

1. Read the Error Message (Yes, Really)

[ ] What does it actually say? "Unauthorized" vs "BadRequest" vs "InvalidTemplate" mean different things.
[ ] Copy the error code if there is one. Sometimes a quick search turns up the fix.
[ ] Common codes: 401/403 = authentication; 400/404 = configuration; 500/502 = temporary. See Troubleshoot a cloud flow.

2. Check the Inputs

[ ] Did the previous step pass the right data? Look at the outputs of the step right before the failure. Null? Wrong format? Wrong property name?
[ ] Dynamic content from a previous run? If the flow was edited or the trigger payload changed, old dynamic content can point to the wrong place.
[ ] Expressions with typos? A missing parenthesis or wrong function name will blow up. Check items('For_each') vs items('For_Each') (case matters).

3. Permissions & Connections

[ ] Connection valid? Go to Data → Connections. Is the connector for this action still connected? Sometimes they expire or get revoked.
[ ] Service account / run-as user: Does the user running the flow still have access to the target system (SharePoint, Dataverse, etc.)?
[ ] Licenses: Some actions need Premium. If the flow used to run under a different user, check who's running it now.

4. Rate Limits & Throttling

[ ] Too many requests? Connectors (SharePoint, HTTP, Outlook, etc.) have limits. "429" or "throttled" means slow down. Add a delay, reduce parallelism, or schedule retries.
[ ] Concurrent runs: If multiple flows hit the same system, you can hit limits. Stagger or batch.

5. Data Shape

[ ] Empty array or null? A "For each" on an empty list can behave oddly. Use "Condition" to check if the array has items before looping.
[ ] Schema change? Did SharePoint add/remove a column? Did the API response structure change? Your "Parse JSON" or dynamic content might be out of date.

Quick Wins That Fix a Lot

Symptom	Try this first
Flow runs but does nothing useful	Check "Configure run after" on actions. Maybe the step is set to run only on failure or skip.
Intermittent failures	Add retry where supported. Many connector actions have retry settings (action → ... → Settings). Use Run after for error paths. See Employ robust error handling.
"Action failed" with no detail	Check run details in Power Automate, or Power Platform Admin Center (PPAC) → Analytics → Power Automate for tenant-level view.
Trigger not firing	Re-check trigger conditions. For "When an item is created," ensure the list/library hasn't changed.

When to Escalate

Connector outage: Check Microsoft 365 Service Health or Power Platform status.
Custom connector / API: The external service might be down or returning errors. Test the API directly (Postman, etc.).
Premium features: If you're hitting limits of HTTP + Premium or Process Advisor, you may need to talk to your admin about capacity or licensing.

Microsoft Sources

ROI & Value Measurement Toolkit

Alan Williams — Sun, 15 Feb 2026 19:54:27 +0000

ROI & Value Measurement Toolkit | elijah.ai

ROI & Value Measurement Toolkit

Why this exists: You've built stuff. Leadership wants numbers. You're tired of "chasing shiny tools" skepticism and status reports that don't tell the real story. This toolkit helps you turn what you've delivered into language execs actually care about.

For you if: You're a Delivery Lead, Automation Team Lead, CoE Lead, or anyone who has to prove the Power Platform is paying off.

Ground truth: Everything here pulls from Microsoft's adoption guidance on measuring business value and the Business value toolkit in the CoE Starter Kit.

Time: 15–20 minutes per solution the first time. Less once you've done a few.

1. What to Measure (and Why It Matters)

Ever been in a meeting where someone asks "So what are we getting from this?" and you didn't have a clean answer? Microsoft's adoption guidance breaks value into four buckets: performance improvement, cost savings, risk mitigation, and business transformation. The measures below come straight from their docs: Measure and communicate the business value of Power Platform solutions

Category	What it means (per Microsoft guidance)	Example metrics
Time and cost savings	Compare time and costs before vs. after automation. Calculate based on hours saved per week or month, reduction in errors, and cost savings per task.	"4 hrs/week per user × 12 users = 48 hrs/month"
Error reduction	Track errors before and after implementation. Automated processes minimize errors.	"Approval errors dropped from ~15/month to 0"
Productivity improvements	Compare output achieved before and after implementation (tasks completed, work completed in a given time).	"Process 3× the invoices with same team"
Adoption / User analytics	Microsoft recommends tracking adoption rates, feature usage, and user engagement.	"85% of target users active in first 30 days"
Risk mitigation	Track incidents related to mitigated risks before and after; compliance rate; incident response time.	"Compliance rate improved; incident response time reduced"

2. Tangible vs. Intangible: Report Both

You've got stuff you can count (hours saved, errors down) and stuff that's harder to put a number on (people actually like using it, fewer headaches). Microsoft's framework says both matter. Don't leave the intangible stuff out. That's often what convinces people your solution is worth keeping.

Tangible value	Intangible value
Revenue growth ($)	Risk mitigation and compliance
Reduced maintenance cost ($)	Fewer disruptions
Reduced paperwork and admin ($)	Improved employee experience
Resource optimization (%)	Improved data security

Source: Measure and communicate the business value of Power Platform solutions

3. One-Page Value Summary: Copy-Paste It

Next time someone asks "What did that automation actually do?" (or you're writing a status report or project closeout), fill this in and you're done.

Solution name:
Owner:
Live since:

Metric	Before	After	Delta
Time per transaction
Error rate
Cycle time (end-to-end)
Hours saved per month

One-line story for execs:
[e.g., "This automation saves Finance ~40 hours a month on purchase approvals and cut our error rate from 8% to zero."]

Evidence attached: [ ] Screenshot / [ ] Before-after process map / [ ] User count × hours saved

4. Questions That Actually Get You the Numbers

When you're talking to process owners, these questions tend to surface the data you need. They're from Microsoft's business value guidance:

Time and cost savings:

What was the average time to complete this process before automation, and what is it now?
How much did you spend on labor costs for this process before automation, and how much have you saved since?
Can you provide examples of errors that occurred before automation, and how has automation reduced or eliminated them?

Productivity:

What is the current volume of work handled by the automated process compared to the previous manual process?
How has the automated process improved the speed at which tasks are completed?

5. Before You Hit Send: Quick Checklist

Your status update is ready when you can tick at least one of these:

[ ] Before/after screenshot or simple process map (if you have it)
[ ] User count × hours saved (or equivalent)
[ ] A manual count you replaced (e.g., "previously 50 emails/week we no longer process")
[ ] Adoption rate (e.g., "% of target users active"). User analytics is what Microsoft recommends here.
[ ] UAT sign-off or business owner quote

6. When You Don't Have the Numbers Yet

Early launch? No baseline because the process was chaos before? Here's what to say instead of "we can't prove it yet."

Situation	What to say instead
Just launched	"First 2 weeks: X active users. Full impact metrics in 60 days."
Qualitative wins only	"Eliminated manual handoffs; team reports less friction and fewer 'where's my stuff?' questions."
Pilot phase	"Pilot with [dept]. Success criteria: [list]. Decision point: [date]."
No baseline data	"No formal baseline. Going forward we're tracking: [list 2–3 metrics]."
Skeptic asking for ROI	"We're measuring [X, Y, Z]. First report in [timeframe]. Happy to walk through the methodology."

7. Talk to Who's in the Room

Finance cares about different things than IT. Operations cares about different things than execs. Microsoft's guidance: adjust what you say based on who you're talking to:

Audience	Focus on
IT	Cybersecurity, scalability, technology adoption
Finance	Cost savings, financial ROI, investment justification
Operations	Process efficiency, productivity, reduced downtime
Executives	How it ties to goals, KPIs, OKRs

Source: Measure and communicate the business value of Power Platform solutions

8. When You Need to Do This at Scale

A few apps? This toolkit is enough. Hundreds or thousands? You'll want Microsoft's built-in tools. Here's what's out there:

Tool	What it does	Learn more
Business value toolkit	Lives in the CoE Starter Kit. Walks app owners through a story: problem → solution → obstacles → value → next steps. Uses a value calculator so you can quantify.	Link
Innovation Backlog	Helps you prioritize and line solutions up with what the org actually cares about	Link
Automation Project app	Part of the Automation Kit for Power Automate. Tracks value across flows.	Link

9. Drop-In Snippet for Your Next Status Report

You shipped something. Here's a sentence you can paste in:

Value delivered this period: [Solution name] went live on [date]. Early metrics: [X hours saved / Y errors reduced / Z users active]. Full impact report in [next period].