Elijah R. Young https://elijah.ai Enterprise AI | Intelligent Automation | Data Storytelling Wed, 25 Feb 2026 16:02:40 +0000 en-US hourly 1 https://wordpress.org/?v=6.9.1 https://elijah.ai/wp-content/uploads/2024/06/126897405_padded_logo-100x100.png Elijah R. Young https://elijah.ai 32 32 What Is Business Automation? The 2026 Guide https://elijah.ai/2026/02/25/what-is-business-automation-the-2026-guide/ Wed, 25 Feb 2026 15:37:43 +0000 https://elijah.ai/?p=5425
What Is Business Automation? The 2026 Guide | elijah.ai

What Is Business Automation? The 2026 Guide

A practical, hype‑free roadmap to using automation and AI to improve real work this year.

TL;DR

  • Business automation uses software to handle repetitive, rules‑based, or assistive work so people focus on judgment and relationships. In 2026, this increasingly includes AI agents working alongside humans.
  • The biggest shift: move from isolated “tasks” to end‑to‑end process orchestration across apps, teams, and data—where durable ROI lives.
  • Regulations are real. The EU AI Act’s major enforcement milestone is August 2, 2026. Build governance (risk, logging, oversight) in from day one.
  • Microsoft’s Copilot Studio added 2025–2026 features that make agentic workflows more practical: agent evaluation, computer‑use with audit logging, and multi‑agent orchestration.
  • Start small, measure honestly, and scale what works. Use governance‑as‑code (DLP, environment strategy, logging) to stay safe as you grow.

What we mean by “Business Automation” in 2026

Business automation (business automation, business process automation) is using software to execute steps in your processes with minimal human effort.

Intelligent automation / AI automation adds AI for perception and judgment (classifying docs, summarizing messages, drafting steps).

Agentic automation organizes multiple AI “agents” and tools to collaborate across a process (triage → extract → decide → act), with logging and human hand‑offs.

Process orchestration coordinates tasks, systems, and people end‑to‑end (not just “click this button for me”).

In Microsoft-first shops, this often looks like Power Automate (flows), Power Apps, Dataverse, and Copilot Studio (agents), plus connectors to ERP/CRM and line‑of‑business systems.

What’s new in 2026 (and why it matters)

  • Agentic orchestration is the constraint. A 2026 survey of 1,150 IT leaders found 81% say a fully autonomous enterprise is a “pipe dream” without orchestration; 79% plan to increase automation spend (avg. +20%). Camunda: State of Agentic Orchestration and Automation 2026.
  • EU AI Act timelines bite in 2026. Major rules and enforcement begin August 2, 2026 (high‑risk requirements, transparency, logging/oversight). EU AI Act – Implementation Timeline.
  • Microsoft Copilot Studio matured. 2025–2026 updates include agent evaluation with test sets and activity maps, expanded computer use with enhanced audit logging and Cloud PC pooling, VS Code extension (GA), and multi‑agent orchestration. What’s new in Copilot Studio.
  • Risk frameworks are steadier, not looser. The NIST AI RMF 1.0 remains the baseline, with a living Playbook (updated 2025) covering Govern → Map → Measure → Manage. NIST AI RMF Playbook.

The 2026 stack: From tasks to process orchestration

Mindset shift
Define the outcome, then orchestrate. The durable gains show up when you map the whole flow, pick the minimum tooling, and make human hand‑offs explicit.
  1. Define the outcome and owner (who loses sleep if this process fails?).
  2. Map the end‑to‑end process (systems, people, approvals, exceptions).
  3. Choose the minimum tech to orchestrate it (Power Automate + Dataverse + Copilot Studio where AI helps).
  4. Instrument the flow (logging, metrics, alerts).
  5. Add human-in-the-loop for ambiguous steps (review, approve, correct).

In my work with enterprise and mid‑market teams, the things that stick are boring on purpose: one shared “source of truth,” clear hand‑offs, and a simple rule for where logic lives (flow vs. app vs. data layer).

Five practical plays to start (and actually finish)

  • Start with one “narrow but noisy” process. Pick something small but frequent (intake triage, invoice coding, access requests). Baseline: volume/month, minutes per item, error rate. Write a 1‑sentence value hypothesis and measure it.
  • Build governance‑as‑code from day one. Power Platform DLP policies, environment strategy, solution ALM, audit logging. Document human oversight and exception paths. If you touch the EU, align to EU AI Act expectations for 2026. Use NIST AI RMF (Govern/Map/Measure/Manage) as an operating model.
  • Treat data like a product. Define the golden record and where decisions read/write. Track data quality (completeness/accuracy/freshness). Most “AI failures” are data placement failures.
  • Design human‑in‑the‑loop as a feature, not a bug. Put approvals, clarifications, and overrides in the flow (Power Automate Approvals; request‑for‑info in Copilot Studio). Make it auditable and kind.
  • Evaluate and iterate agents like products. Use Copilot Studio agent evaluation with test sets and activity maps to catch regressions before rollout. Keep a lightweight “release note” per flow/agent.

Where AI (actually) helps right now

  • Document intelligence: classify, extract, and route documents with review for edge cases.
  • Service triage: summarize and route tickets; propose first responses for human edit.
  • Data hygiene: suggest merges, normalize fields, flag anomalies for review.
  • User assistance: embedded copilots that answer “how do I…?” with links into the process.

ROI without the fairy dust

Use a simple model your CFO can sanity‑check:

  • Baseline time per item × monthly volume = hours/month
  • After automation: new time per item × monthly volume = new hours/month
  • Savings = (baseline − new) × fully‑loaded hourly cost
  • Add error‑reduction savings where applicable (chargebacks, rework)
  • Subtract cloud + license + change‑management costs

Publish the math. If it doesn’t pencil, stop or simplify.

Common pitfalls (and how to avoid them)

  • Automating unclear processes. If no one owns the outcome, your automation will drift. Name the owner.
  • API‑only thinking. “Computer use” (UI automation) has its place—use it with audit logging and guardrails.
  • Shadow data lakes. Multiple “sources of truth” will eat your lunch. Pick one.
  • No lifecycle. Treat flows/agents like products (backlog, versions, deprecations).
  • Ignoring policy. 2026 brings stricter expectations (EU AI Act). Align early; don’t retrofit later.

Tools: When to use what

  • Power Automate (cloud + desktop): system‑to‑system and UI steps; great for approvals and notifications.
  • Power Apps + Dataverse: make the work visible and structured; store state and decisions.
  • Copilot Studio: agentic tasks (summaries, extractions, decisions) with evaluation and multi‑agent orchestration.
  • Process orchestration platforms: when you span dozens of endpoints and complex SLAs, coordinate people, systems, and agents centrally.

FAQ (for searchers and skeptics)

What is business automation?
Using software to execute business process steps—data movement, decisions, notifications—so people spend more time on judgment and customer work.

Business automation vs. business process automation (BPA)?
BPA emphasizes mapping and improving the whole process (orchestration), not only tasks.

RPA vs. intelligent automation vs. AI automation?
RPA automates UI actions. Intelligent/AI automation adds perception and judgment and coordinates multiple agents/tools.

Where do we start?
Pick one narrow process, define the owner and baseline, add governance‑as‑code, and measure. Publish what you learned. Then scale.

How do we stay compliant in 2026?
Map use cases to the EU AI Act if you operate in the EU. Log decisions, add human oversight, and align to NIST AI RMF (Govern/Map/Measure/Manage).

Sources and further reading

]]>
National Retail Chain: AI-Powered IT Event Management https://elijah.ai/2026/02/25/national-retail-chain-ai-powered-it-event-management/ Wed, 25 Feb 2026 02:09:13 +0000 https://elijah.ai/?p=5393
National Retail Chain: AI-Powered IT Event Management | elijah.ai
National Retail Chain

AI-Powered IT Event Management

Letting support staff ask questions in plain language instead of sifting through logs

The Challenge

A national retail chain's IT team was drowning in system events. When something broke, finding the right event data took too long. Support staff spent hours sifting through logs instead of solving problems. The volume and complexity of events kept growing. They needed a way to get to the answer fast.

They already had event infrastructure (EventArc). What they lacked was a way for people to interact with it without learning query languages or digging through raw data. They needed AI that could find the relevant events and summarize them so support could act.

The Approach

We built a system on Google Cloud's Vertex AI that let support staff ask questions in plain language. Type what you're looking for, get back relevant events, summaries, and next steps. The AI finds the right event data and summarizes it so people can act instead of hunt.

The system plugged into their existing EventArc infrastructure so we didn't rip and replace. We designed it to scale with their data volume. The architecture separated retrieval (finding the right events) from generation (summarizing and recommending) so each piece could be improved independently.

  • Natural language querying. Support staff ask questions in plain English instead of writing queries
  • AI-generated summaries and recommendations. Context-aware insights and suggested next steps for diagnosis and resolution
  • Vertex AI architecture. Built on Google Cloud Platform, integrated with EventArc, designed for scale

The Results

What They Got

~40% faster issue resolution

Support staff could find the right events and act on them in a fraction of the time it used to take.

~30% efficiency gains for the IT support team

Less time hunting, more time fixing. The team could focus on solving problems instead of searching for clues.

  • Faster identification of system issues through AI analysis
  • Integration with existing EventArc infrastructure (no rip and replace)
  • Architecture that scales with growing event volume

Technologies Used

Google Vertex AI, Google Gemini (large language model), Google Cloud Storage, BigQuery, EventArc. The system uses retrieval-augmented generation: it retrieves relevant event data and uses the LLM to summarize and recommend, so answers are grounded in actual events instead of made up.

Scope: Event-aware AI system for IT support: planning, retrieval component development, Gemini integration, quality evaluation, testing, deployment, and training.
]]>
Fortune 500 Manufacturer: AI Delivery Framework https://elijah.ai/2026/02/25/fortune-500-manufacturer-ai-delivery-framework/ Wed, 25 Feb 2026 01:52:43 +0000 https://elijah.ai/?p=5383
Fortune 500 Manufacturer: AI Delivery Framework | elijah.ai
Fortune 500 Manufacturer

AI Delivery Framework and Idea Lifecycle

Standardizing how AI ideas get vetted, prioritized, and measured

The Challenge

A Fortune 500 manufacturer had AI ideas coming from all over the company. Different teams wanted to build different things. The problem was there was no standard way to vet them, prioritize them, or measure what worked. Different teams were reinventing process. Leadership had no clear view of the pipeline. Good ideas could get lost. Bad ideas could get resources. There was no way to know which AI products actually delivered value.

They needed a repeatable way to go from idea to deployed solution, with numbers to back it up.

The Approach

We created standard operating procedures (SOPs) for the key stages of AI delivery: architecture, testing, incident management, and go-live. That gave teams a shared playbook instead of everyone making it up as they went.

Next we defined a KPI (key performance indicator) and measurement plan tailored to AI products. What does success look like? How do we track it? Now they could see which AI products actually delivered value instead of hoping.

Finally we built an automated workflow for the idea lifecycle. Intake, validation, governance review, prioritization, tracking. All in one place with a live dashboard so leadership could see what was in the pipeline and where things stood. No more ideas in spreadsheets or stuck in email.

  • AI delivery SOPs. Architecture, testing, incident management, go-live procedures
  • KPI and measurement framework. Data-driven tracking of AI product performance against business goals
  • Automated idea lifecycle workflow. Intake, validation, governance, prioritization, tracking with real-time visibility

The Results

What They Got

  • A repeatable way to go from idea to deployed AI solution
  • Visibility: leadership can see the pipeline and track progress
  • Numbers that matter: KPIs show which AI products actually deliver value
  • A foundation for future AI growth that scales with the portfolio

Technologies Used

Standard operating procedure documentation, KPI and measurement frameworks, automated workflow system for idea management. The workflow and dashboard were built on the client's existing automation platform to fit their environment.

Scope: SOP development, KPI plan creation, automated workflow implementation for idea intake through prioritization and tracking.
]]>
Major Utility: Power Platform Strategy & Governance https://elijah.ai/2026/02/23/major-utility-power-platform-strategy-governance/ Mon, 23 Feb 2026 21:26:11 +0000 https://elijah.ai/?p=5362
Major Utility: Power Platform Strategy & Governance | elijah.ai
Major Utility

Power Platform Strategy, Governance, and Citizen Developer Enablement

Scaling safely across 30,000+ potential users while letting employees build their own solutions

The Challenge

A large utility had the right idea: give employees tools to build solutions for their own workflows. Power Platform could do that. The problem was scale. They faced 30,000+ potential makers. How do you let people build without creating chaos? How do you keep data secure when solutions spread across the organization? How do you know what's getting built and whether it's any good?

They needed a path from "someone has an idea" to "we shipped it" without central IT becoming the bottleneck. They also needed guardrails so nothing dangerous slipped through.

The Approach

We built a governance framework first. That meant Data Loss Prevention (DLP) policies, environment strategy, and clear rules for what could go where. Before anyone scaled, we knew how data would move and who could see it.

Next, we created a resource hub for citizen developers. Think of it as a one-stop shop: training, how-tos, and a place to ask questions. We added an idea intake process so good ideas could get visibility and support instead of living in someone's head. We set up hackathons and evangelism so people could learn from each other.

On the delivery side, we implemented reusable component libraries and automated workflows for code review and backlog management. That meant new apps could build on what already worked instead of starting from scratch every time.

  • Governance. DLP policies, environment strategy, compliance dashboards
  • Citizen developer enablement. Resource hub, training, communication plan, hackathons
  • Delivery pipeline. Idea intake, code review automation, reusable components

The Results

What They Got

  • A clear path from idea to shipped solution without central IT as the bottleneck
  • Faster application development through reusable components
  • Visibility for leadership: dashboards showing what was running and where value lived
  • Governance in place before scale, so adoption could grow safely

Technologies Used

Power Apps, Power Automate, Power BI, Power Virtual Agents. Strategy and governance frameworks, reusable component libraries, automated workflow engines for idea intake and code review.

Scope: Enterprise-wide Power Platform strategy, governance, citizen developer program, and delivery pipeline.
]]>
Automotive Manufacturer: Power Platform Governance https://elijah.ai/2026/02/23/automotive-manufacturer-power-platform-governance/ Mon, 23 Feb 2026 21:19:21 +0000 https://elijah.ai/?p=5349
Automotive Manufacturer: Power Platform Governance | elijah.ai
Automotive Manufacturer

Governance and Environment Optimization at Scale

Cleaning up a messy tenant and handing the internal team an operating model they could run themselves

The Challenge

An automotive manufacturer had Power Platform in use across the organization. People were building apps and flows. The problem was there was no playbook for managing it. Environments were messy. There was no shared view of what existed or how to add new solutions safely. A small team had to administer a very large tenant and they were flying blind.

They needed a roadmap. They needed to migrate existing apps into standardized environments. They needed governance so they could say yes to innovation without saying yes to risk. And they needed their internal team to own it going forward, not depend on consultants forever.

The Approach

We started with an assessment. Using the Center of Excellence (CoE) Starter Kit, we mapped what was out there: apps, flows, connections, environments. From there we built a prioritized roadmap with the business. What mattered most? What could wait?

Next we migrated applications into standardized, dedicated environments. We configured default and dedicated environments with appropriate controls so makers knew where to build and how. We implemented governance policies for Teams environments using Dataverse and Copilot Studio where it made sense.

The last piece was handoff. We defined an operating model covering data protection, security, governance, support, data integration, monitoring, and licensing. We put in place an application lifecycle management (ALM) strategy so they had a repeatable way to ship. Then we ran knowledge transfer sessions so the internal team could run it themselves.

  • Assessment and roadmap. Current state analysis with CoE Starter Kit, stakeholder alignment
  • Environment optimization. Standardized dedicated and default environments, migration support
  • Governance framework. Policies for environments, security, Dataverse, Copilot Studio
  • Operating model and knowledge transfer. Defined processes, ALM strategy, KT sessions

The Results

What They Got

  • A clean, secure, standardized Power Platform ecosystem
  • Clear strategies for environment management, security, and application lifecycle
  • An internal team equipped to run the platform long term instead of depending on consultants
  • A repeatable way to add new solutions without recreating process each time

Technologies Used

Power Apps, Power Automate, Power BI, Copilot Studio (formerly Power Virtual Agents), Dataverse. Center of Excellence (CoE) Toolkit for assessment and ongoing governance. Dedicated and default environment strategy. ALM processes.

Scope: Five-milestone program covering assessment, migration, environment optimization, governance deployment, and operating model with knowledge transfer.
]]>
What Microsoft Power Platform Jobs Really Look Like https://elijah.ai/2026/02/23/what-microsoft-power-platform-jobs-really-look-like/ Mon, 23 Feb 2026 19:53:44 +0000 https://elijah.ai/?p=5331
What Microsoft Power Platform Jobs Really Look Like | elijah.ai

What Microsoft Power Platform Jobs Really Look Like

And what you can do to get ready for them

If you're searching for Microsoft Power Platform jobs, you're in good company. More people are looking. I've worked with Power Platform since 2018, from building apps and flows to leading Centers of Excellence (CoE) and advising large organizations on governance. I'm not a recruiter. I'm someone who hires, trains, and works alongside people in these roles. Here's what I've seen.

The Work Is Not Just "Building Apps"

Power Platform jobs span a wide range. Some roles focus on building. Others focus on governance, training, or administration. Most mix several of these. Here's what that looks like in practice.

  • Building and delivery. At a national restaurant chain, I led an automation program that went from 3 solutions to 27 in one year. The work included Power Automate flows, Power Apps, and integrations with finance, supply chain, and HR systems. Day to day, that meant: understand the process, design the solution, build it, test it, and hand it off. The best builders asked questions first. They figured out who owned the outcome before opening the tool.
  • Governance and administration. At an automotive manufacturer, a small team had to administer Power Platform for a very large tenant. The work was license management, organizing environments, and building guardrails so makers could build safely. At a major utility, I helped stand up a Power Platform CoE while they moved from another automation tool. That meant governance frameworks, training for 30,000+ potential users, and processes to manage solutions at scale. Governance roles are less about building and more about enabling others to build responsibly.
  • Document intelligence and AI. At an energy company, I led a team that used Microsoft Copilot Studio for document analysis and classification. We built chatbot interfaces so people could query documents instead of hunting through folders. Power Platform jobs increasingly touch AI. If you're comfortable with Copilot Studio, Power Automate, and the basics of how chatbots work, you're in a good spot.

What Separates People Who Get Hired

I've reviewed candidates, onboarded new hires, and worked with teams filling these roles. A few patterns stand out.

  • You can explain the problem before the solution. The strongest candidates can describe the business problem in plain language. They talk about who feels the pain and how often. They don't jump straight to "I'll build a Power App." That skill matters. It's what prevents building something no one uses.
  • You think about ownership and adoption. Who owns the outcome? What happens if people don't use it? The best practitioners ask these questions. They've seen solutions sit unused because no one was accountable for driving adoption.
  • You understand data and security basics. Where does the data live? Who can see it? What happens when it crosses systems? You don't need to be a security expert. You do need to know enough to have the conversation. At that utility, we built governance before scaling. At the restaurant chain, we had clear rules for where logic lived and how we handled exceptions. Those habits save projects.
  • You've shipped something. It doesn't have to be huge. A flow that saves your team an hour a week. An app that replaced a spreadsheet. Something you built, put in front of users, and improved based on feedback. That shows you can finish.

How to Prepare (Without Overwhelming Yourself)

Search for "Microsoft Power Platform jobs" and you'll see roles asking for Power Apps, Power Automate, Dataverse, and sometimes Copilot Studio. Here's a practical path.

  • Start with one tool. Power Automate (flows) is a good entry point. Many business processes are "when this happens, do that." Build a few flows. Break them, fix them. Then try a canvas app or a model-driven app. You don't need everything on day one.
  • Learn the design-before-build habit. I put together a Design-First Delivery series because the biggest failures I've seen weren't from bad building. They were from building before clarifying the problem, the owner, and the success measure. Go through the checklist. It takes 10 to 15 minutes per project and can save you weeks of rework.
  • Get comfortable with "I don't know yet." In these roles, you'll get requests you haven't seen before. The people who thrive say "I need to understand this first" and then figure it out. At a cancer research center, we built automations for clinical workflows while keeping healthcare privacy rules (HIPAA) front and center. We didn't know every answer upfront. We learned as we went.
  • Consider the PL-900. Microsoft's Power Platform Fundamentals certification (PL-900) covers the basics. It won't get you the job by itself, but it signals you've done the groundwork. I hold it. It's useful for talking the talk when you're starting out.

What the Day-to-Day Actually Feels Like

Expect a mix of building, meetings, and troubleshooting. You'll spend time in Power Apps or Power Automate. You'll also spend time in Teams, email, and spreadsheets. You'll collaborate with business owners who aren't technical. You'll work with admins who care about licenses and security. You'll debug flows that ran yesterday and stopped today. Some days you'll feel like a builder. Other days you'll feel like a translator between business and tech. Both matter.

At a major airline, we built automations that processed hundreds of thousands of customer refunds during a difficult period. The tech was important. So was understanding the process, the data, and who owned each step. The best Power Platform jobs are like that. They're about solving real problems for real people. The tool is just the tool.

One Thing to Do This Week

If you're job hunting, try this. Write down one process you've automated or could automate. It can be small. Describe who has the problem, what's broken today, and what "better" looks like. Practice explaining it to someone who doesn't know Power Platform. Can they repeat it back? If yes, you've got a story for your next interview. If not, keep simplifying until they can.

The market for Microsoft Power Platform jobs is growing. The people who stand out are the ones who can think before they build and explain why it matters. You've got this.

]]>
Module 6: When Design Gets Skipped | Design-First Delivery https://elijah.ai/2026/02/20/module-6-when-design-gets-skipped-design-first-delivery/ Fri, 20 Feb 2026 14:20:46 +0000 https://elijah.ai/?p=5287
Module 6: When Design Gets Skipped | Design-First Delivery | elijah.ai

Module 6: When Design Gets Skipped

Real Talk

What this module covers: What happens when you skip the steps in Modules 1–5. Not to scare you—to give you language when someone says "we don't have time for all that." The checklist doesn't slow you down. It keeps you from building something you'll have to tear down.

What You Get When You Skip Design

Real talk. When you skip these steps, you get:

  • Apps that solve the wrong problem (or no one's problem). You built something. It works. But the person who asked for it says "oh, that's not quite what I meant." Or worse: no one uses it because no one owned the outcome.
  • Flows that break because data boundaries or connectors weren't thought through. You built a flow that mixes SharePoint and Gmail. Your admin's DLP policy says no. Now you're refactoring—or the flow sits in limbo while you negotiate.
  • Rework when governance or compliance show up late. You shipped. It's in production. Then someone asks: "Who can see this data? Is it audit-ready?" You don't know. You're scrambling to add security and logging after the fact.
  • Pilots that never scale because no one owned the outcome. The pilot worked. Everyone loved the demo. But there's no owner. No rollout plan. No support model. Six months later it's orphaned and someone's asking "whatever happened to that thing?"

The "We Don't Have Time" Pushback

You'll hear it: "We need to move fast. Can't we just build it and figure out the rest later?"

Here's the thing. The modules don't add weeks. They add clarity. A 30-minute requirement capture session can save you 30 hours of rework. A 15-minute conversation about who owns the outcome can prevent a pilot from dying on the vine.

The checklist is a filter. It keeps you from saying yes to every request—and from building things that will haunt your backlog. When someone drops "we need an app for X" on your desk, you can say: "I'd love to help. Let's get an owner, a problem statement, and a baseline. Ten minutes. Then we'll know if we should build."

The Bottom Line

Low-code isn't failing because Power Platform is weak. It's failing because we skip the part where we figure out what we're actually building. You wouldn't pour a foundation without a blueprint. Same idea.

Use the modules. Use the checklist. Protect your time. Protect your credibility.

You're Done

You've worked through the Design-First Delivery series. Go build something that sticks.

← Back to index

]]>
Module 5: Ready to Build (and Process Maps) | Design-First Delivery https://elijah.ai/2026/02/20/module-5-ready-to-build-and-process-maps-design-first-delivery/ Fri, 20 Feb 2026 14:10:56 +0000 https://elijah.ai/?p=5283
Module 5: Ready to Build (and Process Maps) | Design-First Delivery | elijah.ai

Module 5: Ready to Build (and Process Maps)

Final Checklist Before You Open the Tool

What this module covers: If you've passed the phases in Modules 1–4, you're in good shape. This is the final pass—and a quick look at Process Maps in Power Apps Plans if you have access.

Final Checklist

Work through this before you open Power Apps or Power Automate. If any box stays unchecked, you're not ready. That's okay. Go back and close the gap.

From Module 1 (Pre-Build)

  • [ ] Problem statement, owner, and success measure are written down.

From Module 2 (Plan)

  • [ ] Project plan exists with scope, timebox, and stop conditions.

From Module 3 (Requirements)

  • [ ] Requirements (functional + non-functional) are captured and agreed.

From Module 4 (Design)

  • [ ] Data structure and app type are decided.
  • [ ] Security and access model are thought through.

Environment

  • [ ] You know which environment you're building in. Not the default, if you can help it. See Environment strategy. Dev, test, prod—or at least "where does this live and who can access it?"

All checked? You're ready to build.

Process Maps (Power Apps Plans)

Process Maps—the built-in visual workflow tool in Power Apps Plans—let you design the flow before you build. You create activities, decisions, and transitions. Share it with stakeholders. Get alignment. Then translate it into a flow or app. If you have access, it's worth using.

  • [ ] Create a process map for the workflow. Activities, decisions, transitions.
  • [ ] Share it with stakeholders. Get alignment before you translate it into a flow or app.
  • [ ] Use it as your spec when you build. See Process maps as part of your plan.

Don't have Process Maps? That's fine. A whiteboard sketch or Miro board works too. The point is: design before you build. The tool is optional; the discipline isn't.

What You Do Next

Open Power Apps or Power Automate. Build to your design. Test. Deploy. The Think like a Maker: Plan and deploy your Power App path walks through make, test, and deploy. You've done plan and design. Now you execute.

Before you go: read Module 6: When Design Gets Skipped. It's a short reality check on what happens when people skip these steps—and why the checklist protects your time.

]]>
Module 4: Design the Solution | Design-First Delivery https://elijah.ai/2026/02/20/module-4-design-the-solution-design-first-delivery/ Fri, 20 Feb 2026 14:07:33 +0000 https://elijah.ai/?p=5279
Module 4: Design the Solution | Design-First Delivery | elijah.ai

Module 4: Design the Solution

The Blueprint

What this module covers: You've identified the problem and captured requirements. Now design the solution before you open the tool. Data structure, app type, and where logic lives matter more than you think. Get these right and building goes faster. Get them wrong and you'll rework.

Source: Design your app like a pro, Model data for Power Platform solutions (Microsoft Learn)

1. Design Your Data Structure

Where does data live?

Dataverse? SharePoint? SQL? Excel? Each has tradeoffs. Dataverse gives you relationships, security, and scale—but it's a commitment. SharePoint works for simpler lists and document-heavy scenarios. SQL when you need existing databases. See Model data for Power Platform solutions for the full decision tree.

  • [ ] You know where data lives (or will live).
  • [ ] You've thought about scale. How many rows? How often does it change? Who queries it?
  • [ ] You've thought about relationships. Do you need lookups between entities? Many-to-many?

Main entities and tables

Sketch or list what you need to track. A service request? A customer? An invoice line? What fields does each have? What connects to what?

  • [ ] You've sketched or listed the main entities/tables.
  • [ ] You've listed key fields for each. (Don't need to be exhaustive—enough to build.)

Data security

Who can see what? Least privilege by default. Don't give everyone access to everything and plan to lock it down later—that almost never happens.

  • [ ] You've thought about who can see what.
  • [ ] You've thought about who can create, edit, delete. Different roles?

2. Choose the Right App Type

Power Apps gives you choices. Each fits different scenarios. Pick before you build.

App typeWhen to use itNotes
Canvas appCustom UI, mobile-first, point solution. Forms, simple CRUD, field work.Flexible. You design every screen. Good when the UI needs to look a specific way.
Model-driven appDataverse-based. Views, forms, and security are built in. Data model drives the UI.Less design work. Good when the data structure is the main thing. Requires Dataverse.
Power PagesExternal users. Public or partner-facing. Customer portals.Different auth and hosting model. For when your users aren't in your tenant.

Rule of thumb: Consider a model-driven app unless your users have a specific need for a canvas app. Model-driven gets you up and running faster because the UI follows the data. Canvas gives you full control when you need it.

Where does logic live?

In the app? In a flow? In Dataverse (business rules, calculated columns)? This affects maintainability and where you'll debug when things break.

3. Security by Design

Don't bolt security on at the end. Think about it now.

  • [ ] Access model is defined. Who can see, create, edit, delete? Role-based? Group-based?
  • [ ] Data boundaries are clear. What data does this touch? PII? Financial? Regulated? Your admin will ask. Know the answer.
  • [ ] You've thought about connectors and DLP. Data Loss Prevention (DLP) policies group connectors into Business, Non-Business, and Blocked. Business and Non-Business can't mix in the same app or flow. Will your solution need connectors from different groups? That's a policy conversation with your Admin Lead.

Next Step

With your design in place, move to Module 5: Ready to Build (and Process Maps). That's the final checklist—and how to use Process Maps if you have them.

]]>
Module 3: Capture Requirements | Design-First Delivery https://elijah.ai/2026/02/20/module-3-capture-requirements-design-first-delivery/ Fri, 20 Feb 2026 14:05:29 +0000 https://elijah.ai/?p=5274
Module 3: Capture Requirements | Design-First Delivery | elijah.ai

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.

TypeWhat to captureExample
FunctionalWhat 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-functionalHow 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.

]]>