Strategy & Thought Leadership – 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 Strategy & Thought Leadership – 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

]]>
Power Platform February 2026: What’s New and What It Means for IT Pros https://elijah.ai/2026/02/19/power-platform-february-2026-whats-new-and-what-it-means-for-it-pros/ Thu, 19 Feb 2026 15:08:05 +0000 https://elijah.ai/?p=5241

Power Platform February 2026: What’s New and What It Means for IT Pros

If you’re an IT professional managing Power Platform, you’ve got a lot to track. Microsoft ships updates monthly, and the announcements can feel dense. Tiffany Treacy, Vice President of Product for Power Platform at Microsoft, published the February 2026 feature update on the Microsoft Power Platform Blog. I’ve pulled out what matters most and translated it into plain language and what it means for your day-to-day work and career.

The Recap: What Microsoft Announced

The official Microsoft Power Platform Blog post covers five main areas. Here’s the short version.

Apps, Agents, and Copilot

M365 Copilot chat in model-driven apps (public preview). Copilot chat is now available inside model-driven apps. Users can ask questions, analyze in-app data, and use first-party agents (Researcher, Analyst) plus custom Copilot Studio agents, without leaving the app. Administrators configure it per environment; makers turn it on or off per app.

Public preview: M365 Copilot chat in model-driven apps

Power Apps MCP and enhanced agent feed (public preview). The Power Apps Model Context Protocol (MCP) Server lets agents act on app data, starting with data entry. Agents can parse unstructured data into app forms, create records, and flag items for human review. The enhanced agent feed gives makers a shared workspace to oversee agent activity, use side-by-side comparison views for approvals, and link to in-app records.

Public preview: M365 Copilot chat in model-driven apps

Building Modern Apps

Modern Card control (public preview). A new Card control for canvas apps lets you build responsive layouts with a single control instead of assembling multiple classic controls. It adapts to vertical or horizontal layouts and aligns with Fluent UI.

Theme copy-paste (generally available). You can copy a canvas app’s theme—colors, typography, styling tokens—as YAML and paste it into other apps. Useful for consistent branding across an app portfolio.

Confirm() function as Fluent dialog (generally available). The Confirm function now shows a Fluent-style modal confirmation dialog in canvas apps instead of a browser-native dialog, when modern controls are enabled.

Managed Platform (Governance)

Move canvas apps and SharePoint forms out of the default environment (public preview). Admins can migrate canvas apps and custom SharePoint forms from the default environment to managed environments. Migration can be done manually from Power Platform Advisor recommendations or automated via the Power Platform for Admin v2 connector. Admins choose whether to keep, quarantine, or delete the original resource.

Code apps in Power Apps (generally available). Developers can build web apps with React, Vue, or other frameworks in a code-first IDE and deploy them to Power Platform. Code apps are governed as standard Power Platform assets—IT gets visibility and control without blocking developers.


What This Means in Plain Language

Copilot where work happens. Instead of switching to a separate Copilot window, users get AI and agents inside the apps they already use. Fewer context switches, more in-flow assistance.

Agents that do work, not just chat. With MCP, agents can create and update records, parse data, and route items to humans. The agent feed gives visibility and approval workflows so you’re not blindly trusting automation.

Default environment cleanup. The default environment tends to become a dumping ground. This preview lets you move apps and SharePoint forms into managed environments so you can apply governance, DLP, and clear ownership.

Code-first apps within Power Platform. Developers who prefer React or Vue can stay in their workflow and still deploy to Power Platform. IT gets the same admin, security, and lifecycle controls as for low-code apps.

Consistency and reuse. Theme copy-paste and the modern Card control make it easier to keep branding and layouts consistent as your app portfolio grows.


Why This Matters

Different roles see different wins. The February 2026 update connects to what you care about in the following ways.

If you’re an Admin Lead or Governance owner: You’ve been fighting default-environment sprawl: apps and flows piling up without clear ownership, DLP hard to enforce, and “who built this?” questions that go nowhere. The migration preview gives you an actual path: move canvas apps and SharePoint forms into managed environments, apply governance where it matters, and tell a clearer story to leadership about security and compliance. Copilot in apps and the agent feed give you configuration knobs (per environment, per app) instead of all-or-nothing. Code apps GA means developers who build with React or Vue no longer live outside your visibility. They’re Power Platform assets you can monitor and govern like everything else. You get more control without becoming the bottleneck.

If you’re a Delivery Lead: You’re juggling demand vs. capacity, governance constraints that slow projects, and pressure to prove ROI. Theme copy-paste and the Card control cut repetitive setup and layout work, so you get faster builds and consistent design. The default-environment migration reduces the “why is this app in Default?” conversations so you can focus on delivery. Copilot and agents inside model-driven apps mean users get help where they work, which can improve adoption and reduce support load. Code apps GA lets you bring pro developers into the Power Platform fold without a separate toolchain. One platform, one governance model. You can deliver more without multiplying complexity.

If you’re on an Enterprise or Transformation team: You need risk-managed innovation: quick wins that don’t compromise security or compliance. The February 2026 features support that: default-environment migration improves governance posture, Copilot and agents add human-in-the-loop and visibility, code apps bring code-first builds under the same enterprise guardrails. Theme copy-paste and modern controls help you scale design consistency across an app portfolio. You get incremental value and a clearer path from pilot to scale.

If you’re a citizen developer or Power Platform specialist: You’re building skills while balancing governance and maintenance. Theme copy-paste and the Card control make it easier to build professional-looking apps without fighting layout complexity. Copilot in model-driven apps puts AI assistance where you work. The agent feed and MCP give you visibility into what agents do and a way to approve before data changes. These updates add to your toolkit without forcing you to learn everything at once. They also signal where the platform is going (AI, agents, human oversight), which helps you plan your next skills.

If you’re an AI-curious Executive: You want practical value, not hype. The February 2026 update emphasizes governance and human oversight. Copilot in apps is configurable per environment and app; the agent feed requires human review before agents create or update records. Default-environment migration reduces risk and improves audit readiness. Code apps GA brings more development capacity under one governed platform. You get incremental, low-risk ways to adopt AI and automation without betting the company.

If you’re a Developer or Tech Professional: Code apps GA matters most. You can build with React, Vue, or other frameworks in your preferred IDE and deploy to Power Platform. No need to choose between “low-code” and “real code.” You get code-first flexibility with the same visibility and controls IT expects. The MCP server and agent feed show how agents will interact with apps and data, which is useful if you’re integrating AI into solutions. Theme copy-paste and modern controls give citizen developers better patterns, which can reduce the quality and maintainability issues you sometimes inherit. Your Power Platform skills (governance, ALM, environments) apply whether the app is canvas, model-driven, or code. That’s career-relevant.


What This Means for Your Job

Your Day-to-Day Work

Less default-environment chaos. If you’ve struggled with apps scattered in the default environment and no clear boundaries, the new migration preview gives you a path out. You can move apps to managed environments and enforce DLP, security groups, and lifecycle policies where they matter.

One place for Copilot configuration. Microsoft 365 Copilot chat in model-driven apps is configured in Power Platform admin center. You set it up per environment; makers enable or disable it per app. That gives you governance without blocking every use case.

Agents with a human checkpoint. The Power Apps MCP and agent feed add approval and visibility. You can see what agents are doing and require human review before records are created or updated. That’s helpful for risk-sensitive processes and compliance.

Code apps under the same roof. Code apps are governed like any other Power Platform asset. You get visibility in the admin center, standard deployment and environment controls, and no need for a parallel governance model for “real” code.

Faster, more consistent app delivery. Theme copy-paste and the Card control reduce repetitive setup and layout work. That shortens build time and helps you maintain design standards across teams.

Your Career Development

Governance and compliance. The default-environment migration and code apps GA position you to own Power Platform governance at scale. Being able to say you’ve moved apps out of Default, applied DLP in managed environments, and governed both low-code and code apps is a strong differentiator.

AI and agents. Copilot in apps and MCP/agent feed are where the platform is going. Understanding how to configure, secure, and govern these capabilities keeps you relevant as AI becomes part of every workflow.

Modern development practices. Code apps GA means you’ll be working with developers who use React, Vue, and DevOps tooling. Familiarity with how Power Platform fits into that pipeline (ALM, pipelines, environments) strengthens your role as a bridge between IT and engineering.

Reducing technical debt. Default-environment sprawl is technical debt. The migration preview gives you a concrete way to address it and tell a clear story to leadership about governance, security, and compliance.


Where to Start

  1. Admins: Review the Move apps from the default environment documentation. Check Power Platform Advisor recommendations and plan a small pilot migration.
  2. Makers: Try the modern Card control and theme copy-paste in a canvas app.
  3. Developers: Explore Power Apps code apps overview and how they connect to Dataverse or external data.
  4. Everyone: Read the full February 2026 feature update on the Microsoft Power Platform Blog for the complete list, including learning updates and Power Pages changes.

The Bottom Line

The February 2026 Power Platform update gives IT professionals better tools for governance (default-environment migration), AI (Copilot in apps, MCP, agent feed), and hybrid delivery (code apps GA). It’s not just feature noise. It’s directly relevant to reducing sprawl, governing AI safely, and supporting both low-code and code-first teams under one platform.

If you want the authoritative source, the Microsoft Power Platform Blog and Microsoft Learn are the places to go. This recap is meant to save you time and connect the announcements to what matters for your role.

]]>
Build a Power Platform Center of Excellence Without Burying Yourself Under Work https://elijah.ai/2026/01/14/build-a-power-platform-center-of-excellence-without-burying-yourself-under-work/ Wed, 14 Jan 2026 19:33:33 +0000 https://elijah.ai/?p=4821

If your Power Platform program is growing, you’ve felt this tension.

You need to move fast, but without breaking things.
You want to innovate, but without compromising security or compliance.

For Admin Leads, the priority is safeguarding the tenant: enforcing governance, protecting data, and maintaining a strong compliance posture.

For Delivery Leads, the mission is speed. They’re focused on delivering value quickly without getting bogged down in approvals or red tape.

This is where a Center of Excellence (CoE) makes the difference.

Not as a slow-moving committee.
Not as the “no” team.

But as an enablement engine that helps teams deliver faster, safer, and more consistently at scale.

What a Power Platform Center of Excellence Actually Is

In plain language, a Power Platform center of excellence is a small set of capabilities that help your organization scale Power Platform adoption without sacrificing quality, security, or delivery speed.

It is nota single org chart.
It is nota static team.
It is a way of working.

At its best, it creates three outcomes:

Standards that speed up delivery
  • The right way becomes the easy way
  • People stop reinventing the wheel
  • Templates, office hours, reusable assets
  • Clear escalation paths when something gets stuck
  • Templates, office hours, reusable assets
  • Clear escalation paths when something gets stuck

Keep it grounded in Power Platform reality:

  • Environments (where solutions live and how you separate work safely)
  • Data policies and connectors (how you prevent accidental risk)
  • Solutions and release discipline (how you promote changes without production chaos)
  • Application lifecycle management (how you build, test, and release reliably)

Pick the Model That Fits: Three Common Center of Excellence Shapes

Most teams land in one of these models. None is universally “best.” The right one depends on maturity, risk, and how much demand is coming from the business.

Model 1: Centralized

Everything routes through one core team.

  • Works when
    • You need fast stabilization
    • Maturity is low and risk is high
    • You are standardizing from chaos
  • Watch-outs
    • “Buried in more work” risk is real
    • The business disengages if the center becomes a gate

A small core sets standards and guardrails. Delivery happens within departments.

  • Works when
    • Demand is high and distributed
    • You need speed close to the business
    • You already have capable builders in departments
  • Watch-outs
    • Quality drifts unless you invest in shared assets and enforceable guardrails
    • Departments will duplicate work unless reuse is intentionally designed

A hub defines standards, guardrails, and shared services. Spokes deliver inside business areas.

  • Works when
    • You want both speed and consistency
    • You can support a small central enablement function
    • You need a clear path from “local need” to “enterprise-safe”

If you can only staff one person, start closer to centralized, but bias toward self-service assets.
If you already have builders embedded in departments, move toward hub-and-spoke as you mature.

When a Center of Excellence Is the Right Move (Signs it’s time)

A center of excellence is often the right move when:

  • Your user base is expanding (more people are building and shipping)
  • Your inventory of apps and flows is growing across departments
  • Risk is rising (data sprawl, inconsistent standards, unclear ownership)
  • Delivery is slowing due to rework, support load, and “who owns this?” confusion

If you’re early, you don’t have to “go big” to start.
You can start lightweight and still be serious: a few guardrails, a few reusable assets, and a way to see what is happening in your tenant.

The Foundation: Governance and Enablement Must Stay in Balance

The fastest way to kill adoption is governance that only knows how to say no.
The fastest way to create a support nightmare is enablement without guardrails.

I like to frame it this way:

Enablement is empowerment for builders.
Governance is protection for the organization.

The operating principle you’re aiming for is simple:
“Yes, and here’s how to do it safely.”

Governance is not there to slow people down.
Governance is there to make the safe path the fast path.

What too much governance looks like

  • Long approval cycles
  • Fear-driven policy making
  • Delivery teams route around the process

What too much enablement looks like

  • Rapid growth and a support crisis later
  • Inconsistent security practices
  • Technical debt that blocks future scale

The balance is guardrails, templates, and clear lanes for different types of solutions.

Here’s the mindset shift that makes the balance real without turning you into a bureaucracy.

You are not trying to control every build; you are trying to reduce surprises.

If you do that, you get both outcomes:

  • Delivery moves faster because people know the path.
  • Governance gets stronger because the path is actually used.

A practical way to think about it:

  • Create lanes, not a single line
    • Low-risk work should have a fast path
    • High-risk work should have tighter guardrails and clearer checkpoints
  • Make the safe defaults invisible
    • Templates, naming, environment patterns, and connector rules should guide people before they ever need to ask you
  • Turn “approval” into “enablement” where possible
    • Instead of “come ask,” aim for “here’s the standard, here’s the example, here’s how to do it safely”
  • Keep your guardrails explainable
    • If you can’t explain why a rule exists, you will spend your time defending it
  • Use friction as a signal
    • When smart people keep going around the process, it usually means the process needs work

The goal is not perfect governance on day one, rather, a system where you can say “yes” more often, without waking up to a bigger mess next month.

A Practical Build Sequence (High-level, no rigid timeline)

You do not need a day-by-day plan.You need an order of operations that makes your week calmer over time.

This is not a strict timeline.It’s a way to make delivery repeatable so you can ship without guessing what “safe” means this week.
  1. The order matters because each phase reduces chaos in the next one.
  2. If environments are messy, intake becomes political.
    If intake is messy, build work becomes rework.
  3. If build is messy, support becomes your full-time job.

This is where you decide where work happens, and where it is not allowed to happen.

When the environment boundaries are clear, you can move faster because you are not renegotiating the basics every time.

Microsoft’s guidance is basically this: most organizations start in the default environment, and that’s fine for early productivity work. As adoption grows, the default environment is not where you want “everything forever.”

You need a strategy that routes makers into the right place so governance and security can be applied consistently, without you manually policing every new app and flow.

Develop a tenant environment strategy to adopt Power Platform at scale

Example in real life:
you stop building directly in production.

This is where you make work visible and defensible.

It’s how you say yes without saying yes to everything.

This is also where you protect your future self.
When you validate the request up front, you avoid building the wrong thing quickly. When you prioritize in the open, you stop getting cornered by whoever escalates the loudest.

Example in real life:

requests stop arriving in five different places, and you can explain why you said yes to one thing and not another.

This is the delivery lifecycle.
It’s how you stop “shipping” from meaning “hoping.”

The goal is not to slow delivery down.
The goal is to make delivery repeatable so you can ship twice without paying twice.
When this phase is consistent, you get fewer late-night surprises and fewer “who changed what?” conversations.

Pipelines in Power Platform

Solutions overview

Example in real life:
releases become boring, which is the goal.

Support is how you keep trust when something breaks, and how you keep today’s success from turning into next month’s resentment.

Reporting and evangelization are how you keep your wins from disappearing.
They help people find what already exists, follow the safe patterns, and stop rebuilding the same solution three different ways.

Power Platform Analytics

Monitor apps in Power Apps

If your wins stay invisible, demand doesn’t get easier. It gets louder. And you stay buried.

Common Pitfalls (And what happens next when you hit them)

These are the patterns I see when a center of excellence struggles.

Pitfall: Your center of excellence becomes the place everything gets stuck

  • Impact: people go around you, inconsistent builds proliferate, trust erodes, and you get buried in more work
  • What to do instead: create self-service standards and templates so people can move without asking permission

Pitfall: Governance without enablement

  • Impact: builders hide work, off-path solutions increase, standards lose legitimacy
  • What to do instead: say yes with guardrails and support, then tighten based on what you learn

Pitfall: Too much process

  • Impact: cycle time grows, delivery slows, adoption fragments
  • What to do instead: keep the process lightweight and prove value with every step

Pitfall: Ignoring off-path building

  • Impact: you lose visibility and learn too late, security and support risk rises
  • What to do instead: design a safe on-ramp back into the program and fix the root cause

Pitfall: Not evangelizing wins

  • Impact: leadership assumes nothing is changing, departments duplicate work, adoption stalls
  • What to do instead: publish the wins, the reusable assets, and the “how we did it safely” story

Quick wins that build momentum

When you are building from scratch, return on investment is not the only metric that matters.
Momentum matters.

Here are quick wins that do not corner you:

  • Do not shy away from small projects
    • Pick work you can complete and show
    • Build credibility with delivered outcomes
  • Reserve time to take care of home
    • Target about 20 percent of capacity for internal systems and reusable assets
    • Intake improvements, templates, catalog, standards automation
  • Identify and nurture champions
    • Find the builders in the business who want a path
    • Give them guardrails, training, and the right access
    • They will become your best evangelists and your best opportunity pipeline

If you want a simple next step for this month:

  • Pick one guardrail to tighten
  • Pick one enablement asset to ship

The bottom line

A Power Platform center of excellence is not about control. It is about repeatable delivery at scale.

If it slows delivery, people will route around it.
If it enables safe speed, it becomes the foundation that lets you scale without burning out.

If you want to talk through what this looks like in your world, feel free to email me.

]]>
The Chat Window Will Be the Death of AI: Why Frictionless Interfaces Are the Future of Intelligence https://elijah.ai/2025/08/27/the-chat-window-will-be-the-death-of-ai-why-frictionless-interfaces-are-the-future-of-intelligence/ https://elijah.ai/2025/08/27/the-chat-window-will-be-the-death-of-ai-why-frictionless-interfaces-are-the-future-of-intelligence/#comments Wed, 27 Aug 2025 20:12:37 +0000 https://elijah.ai/?p=3681

We’re at a weird moment with AI. It’s getting more powerful every day, promising to change how we work and solve problems. But here’s the thing: the way most of us interact with AI, through those chat windows, might actually be holding it back.

I know, I know. That sounds backwards. Chat interfaces are everywhere. ChatGPT, Copilot, Claude. They all use chat. It’s become the default way we think about talking to AI. But what if that’s the problem?

This isn’t just about what feels nicer to use. It’s about whether AI actually becomes useful in our daily work, or stays stuck as a novelty we occasionally remember to check.

The Problem with Chat

Let me start with something personal: I prefer dictation to typing. For me, typing out a question is friction. It’s extra work. And here’s what I’ve learned: AI works best when there’s no friction at all.

Think about it this way. When you’re using an app you know well, like your email or your calendar, you don’t stop to think about how to use it. You just… use it. The interface disappears. That’s what good design does.

But chat windows? They make you stop. They make you think about how to phrase your question. They make you switch contexts, from whatever you were doing to “now I’m talking to the AI.” That’s friction. And friction kills adoption.

The industry is already moving beyond text-only chat. We’re seeing AI that can understand images, video, and audio. That’s progress. But we’re still stuck thinking chat is the answer to everything.

Here’s what I think happened: Chat became popular because it was easy to build. Developers could quickly show off what Large Language Models (LLMs), which basically means AI that understands and generates text, could do. It felt familiar, like texting. So it stuck.

But just because something’s familiar doesn’t mean it’s the best way to do things. We’ve spent decades learning how to design good interfaces. Why throw all that knowledge away?

The Real Cost of Chat-First Thinking

This isn’t just a design preference. It has real costs.

For the people building AI tools: If you think chat is the only way to deliver AI, you’re limiting yourself. You might build a chatbot when what people really need is AI built into the workflow they already use. You’re solving the wrong problem.

For the people using AI: If you only see AI through chat windows, you’re missing what it could actually do for you. You might think “AI is cool but I don’t have time to chat with it.” And you’d be right. But that’s not AI’s fault. It’s the interface’s fault.

For organizations: Companies invest in AI, but if it’s only available through chat interfaces that feel like extra work, adoption fails. People take the path of least resistance. If AI isn’t on that path, they’ll skip it.

We’re also seeing AI evolve into something more sophisticated, what people are calling “agents.” These are AI systems that can do multi-step tasks on their own, even working with other AI agents. Try managing that complexity through a chat window. It’s like trying to conduct an orchestra with a single drum. The interface doesn’t match what the technology can do.

The Copilot Myth

A lot of people think the solution is just putting chat closer to where work happens. Like having a Copilot sidebar in your application. That’s better than a standalone ChatGPT window, sure. But it’s still missing the point.

True integration isn’t about proximity. It’s about embedding intelligence directly into what you’re already doing.

Let me give you an example. Say you’re using a cloud platform, and there’s a chat window for budget questions. The system already has your data. It knows common budget mistakes. It can see when you’re about to hit a spending limit.

So why should you have to ask? Why should you have to type “Hey, am I about to go over budget?” when the system could just… tell you? Or better yet, prevent the problem before it happens?

That’s what I mean by proactive intelligence. The AI uses its access to your data to anticipate what you need, instead of waiting for you to ask. The right interface doesn’t ask for input. It removes the need for input.

What I’ve Learned from Power Platform

I’ve seen this play out in real organizations. Teams that relied heavily on chatbots (like Power Virtual Agents, now called Copilot Studio) for internal services saw a huge jump in usage when they moved to native application interfaces (like Power Apps).

People didn’t want to chat with a service. They wanted to do work through interfaces designed for the task. Once someone in leadership gets frustrated with clunky chat experiences and decides “AI is all hype,” that door closes for the whole organization.

AI is a Helper, Not a Destination

Here’s a fundamental misunderstanding: People often treat AI like it’s the destination. Like the goal is to interact with AI.

But AI isn’t the destination. It’s the helper. It’s the tool that gets you to your actual goal faster and better.

The interface should reflect that. It should fade into the background, not demand that you adapt to its conversational quirks.

Chat became the default not because it was the best user experience, but because it was a straightforward way to show off what LLMs could do. It’s a developer shortcut that doesn’t always translate to a user-first experience.

And honestly? It can be limiting for developers too. Instead of embedding AI into existing, stable applications, developers might build standalone chat apps. That increases complexity and time-to-value. It’s often cheaper and less risky to add AI as a feature enhancement within something that already works, rather than building an entirely new application around chat.

The Human + AI Thing

I believe this: A person plus AI will always be better than either one alone. But if AI interfaces are clunky, organizations might wrongly conclude that “human plus robot isn’t as good as just the robot.” That leads to dangerous pushes for full automation where human oversight is critical.

On the flip side, if users reject AI because the interfaces are frustrating, they stay overworked. They’re doing tasks that AI could handle, but the interface barrier keeps them from getting that help.

This is fundamentally a leadership challenge. We need to guide our teams to think beyond what’s immediately obvious.

What to Do Instead

So if chat isn’t the answer, what is?

1. Think integration first, not chat first. Instead of asking “How can we build a chatbot for this?” ask “How can AI be invisibly embedded to make this workflow better?”

2. Do real UX research. Don’t assume chat is the answer. Understand what people are actually trying to accomplish. Then design for that.

3. Build proactive intelligence. Create AI systems that anticipate needs and offer help at the right moment, rather than waiting for questions.

4. Educate your team. Show them examples of AI that’s deeply embedded, context-aware, and doesn’t require chat. Broaden their understanding of what an “AI interface” can be.

5. Measure what matters. Don’t count chat sessions or queries. Measure whether AI helps people complete tasks faster, make better decisions, and reduce effort.

A Practical Path Forward

Here’s how you might actually do this:

Phase 1: Find the opportunities (1-3 months)
Look at your existing applications and workflows. Where are the friction points? Where could AI help proactively, without requiring someone to ask?

Phase 2: Build small pilots (3-6 months)
Pick one or two high-impact opportunities. Build AI features that are deeply embedded in the existing interface. For example, instead of a budget chatbot, build an AI feature that flags budget anomalies directly in your financial dashboard.

Phase 3: Create cross-functional teams (ongoing)
Bring together UX designers, AI engineers, product managers, and people who actually use the tools. Give them permission to challenge chat-first assumptions.

Phase 4: Document what works (6-12 months)
When something works, codify it. Create a library of patterns for frictionless AI features. Share these successes internally.

Phase 5: Iterate and scale (ongoing)
Gather feedback. Measure success by task completion and user satisfaction, not chat engagement. Refine and scale what works.

The goal is simple: Make AI an enhancement to how work gets done, not an additional task.

The Bottom Line

Chat windows served a purpose. They introduced us to what conversational AI could do. But they’re not the foundation for how AI will actually deliver value.

The future of AI is seamless integration. It’s proactive assistance. It’s interfaces so intuitive they fade into the background, letting human capability take center stage, powerfully augmented.

This requires challenging assumptions, investing in thoughtful design, and prioritizing real utility over novelty. The organizations that get this will actually harness AI’s transformative power.

The rest? They’ll be stuck wondering why their expensive AI investments aren’t paying off.

Here’s my question for you: What does your interface say about how you define intelligence?

If it says “intelligence is something you chat with,” you might be missing the point. Intelligence should be woven into the fabric of how you work. Invisible. Indispensable. Frictionless.

That’s the future. And honestly? It can’t come soon enough.

]]>
https://elijah.ai/2025/08/27/the-chat-window-will-be-the-death-of-ai-why-frictionless-interfaces-are-the-future-of-intelligence/feed/ 1
Understanding Low-Code Development https://elijah.ai/2025/08/27/understanding-low-code-development/ Wed, 27 Aug 2025 16:53:20 +0000 https://elijah.ai/?p=3657

By Elijah Young

Categories: Low-Code Development / Power Platform & Automation / Business Transformation


Let me explain low-code development. It’s an approach to building applications that uses visual tools and pre-built components instead of writing everything from scratch in code. Sounds simple, right? But it’s changing how organizations build software.

I’ve seen teams transform their development process using low-code platforms. They build applications faster. They involve more people in the process. They respond to changing business needs without waiting months for traditional development cycles.

Let me break down what low-code development is, why it matters, and how it can transform your business.

What is Low-Code Development?

Low-code development is a way of building applications using visual, drag-and-drop interfaces instead of writing code line by line. Think of it like this: Instead of building a house by cutting every board yourself, you’re using pre-made components and assembling them visually.

The “low-code” part means you still might write some code for custom logic or complex features, but most of the application is built using visual tools. It’s a middle ground between traditional coding (where you write everything) and no-code platforms (where you don’t write any code at all).

Low-code platforms provide pre-configured modules, logic, templates, and connectors that you can customize and extend. Professional developers can add custom code when needed. Business users can build simple applications without coding at all. Everyone works together.

Why Low-Code Development Matters

Here’s what makes low-code development valuable:

It accelerates development. You can build applications much faster than traditional coding methods. What used to take months can take weeks. What used to take weeks can take days. The visual tools and pre-built components eliminate a lot of repetitive work.

It reduces costs. You minimize the need for extensive coding expertise. You don’t need as many highly specialized developers. Business users can build some applications themselves. This reduces development costs and speeds up delivery.

It empowers more people. Non-developers can participate in app creation. Business analysts, process owners, and subject matter experts can build solutions themselves. This fosters innovation because the people who understand the problems can build the solutions.

It’s flexible. You can easily adapt to changing business needs. When requirements change, you can modify applications quickly. You’re not locked into long development cycles. You can iterate and improve based on feedback.

It improves collaboration. Low-code platforms break down silos between IT and business teams. Business users can build prototypes. IT teams can refine and extend them. Everyone speaks the same visual language.

How Low-Code Development Transforms Businesses

When organizations adopt low-code development, they typically see three big changes:

Innovation accelerates. You can rapidly prototype and iterate on new ideas. When someone has an idea for solving a business problem, they can build a working prototype quickly. You can test concepts before committing to full development.

Collaboration improves. The barriers between IT and business teams start to break down. Business users can build applications themselves. IT teams can focus on complex integrations and custom code. Everyone contributes.

Agility increases. You can respond swiftly to market changes and customer demands. When a new requirement comes up, you can build a solution quickly. You’re not waiting months for traditional development cycles.

Visual Modeling and Development

Here’s what makes low-code platforms different: They elevate coding from textual to visual. Instead of writing code in a text editor, you build applications through a model-driven, drag-and-drop interface.

Think of it like building with LEGO blocks. You have pre-made pieces (components, modules, connectors) that you can snap together visually. You can see how everything connects. You can understand the flow of your application by looking at it.

This approach democratizes app development. Professional developers can work faster. Novice developers can build applications without deep coding knowledge. Business stakeholders can build simple solutions themselves. Everyone collaborates effectively.

Low-code platforms offer pre-configured modules, logic, templates, and connectors that can be customized and extended by skilled developers. This accelerates development and ensures consistency and scalability across applications. You’re not reinventing the wheel every time.

Reusable Components and Extensibility

One of the powerful aspects of low-code development is reusable components. You build something once, and you can use it everywhere. A component for user authentication. A component for data validation. A component for sending notifications.

Once you build these components, they become part of your library. Other developers can use them. Other applications can use them. You ensure consistency across your organization while speeding up development.

But here’s the key: Low-code platforms are extensible. Skilled developers can add custom code when needed. If you need complex logic that the visual tools can’t handle, you can write code for that specific part. You get the speed of visual development with the power of custom code when you need it.

Low-Code vs. No-Code

You might be wondering: What’s the difference between low-code and no-code?

No-code platforms let you build applications without writing any code at all. Everything is visual. Everything is drag-and-drop. These are great for simple applications, workflows, and automations. But they’re limited. If you need something the platform doesn’t support, you’re stuck.

Low-code platforms offer more flexibility. You can build most of your application visually, but you can also write custom code when needed. This makes low-code suitable for a broader range of applications, from simple productivity tools to complex enterprise systems.

Think of it like this: No-code is like using a template. Low-code is like using a template but being able to customize it however you want.

When to Use Low-Code Development

Low-code development works well for:

Rapid prototyping. When you need to test an idea quickly, low-code platforms let you build a working prototype in days instead of months.

Business process automation. When you need to automate workflows or build applications that support specific business processes, low-code platforms are perfect.

Internal tools. When you need to build tools for your team, low-code platforms let you build exactly what you need without the overhead of traditional development.

Integration applications. When you need to connect different systems and create workflows between them, low-code platforms excel.

Customer-facing applications. When you need to build applications for customers, low-code platforms can handle it, especially with the ability to add custom code for complex requirements.

The Future of Low-Code Development

Low-code development is set to revolutionize digital transformation. As organizations seek to modernize legacy systems and enhance customer experiences, low-code platforms will play a pivotal role in driving innovation and efficiency.

Here’s why: The demand for software is growing faster than the supply of developers. Low-code platforms help bridge that gap. They enable more people to build applications. They speed up development cycles. They reduce costs.

But more importantly, low-code platforms enable rapid, iterative, and collaborative application design. You can build something, test it, get feedback, and improve it quickly. This iterative approach leads to better solutions because you’re learning and adapting as you go.

Getting Started with Low-Code Development

If you’re thinking about adopting low-code development, here’s what I’d suggest:

Start with a specific problem. Don’t try to rebuild everything at once. Pick one process or one application that’s causing pain. Build a low-code solution for that first.

Choose the right platform. Different low-code platforms have different strengths. Some are better for business users. Some are better for developers. Some integrate better with your existing systems. Do your research.

Train your team. Low-code platforms are easier to learn than traditional coding, but they still require training. Invest in helping your team understand how to use the platform effectively.

Establish governance. Even though low-code makes development easier, you still need governance. Who can create applications? What standards do they need to follow? How do you ensure security and compliance?

Start small, scale gradually. Build one application. Learn from it. Build another. As your team gets comfortable, you can tackle more complex projects.

The Bottom Line

Low-code development is not just a trend. It’s a transformative approach that empowers businesses to innovate and adapt in a rapidly changing digital landscape.

It accelerates development. It reduces costs. It empowers more people to build applications. It improves collaboration between IT and business teams. It increases organizational agility.

But here’s the thing: Low-code development isn’t about replacing professional developers. It’s about enabling more people to solve problems with technology. It’s about moving faster. It’s about building solutions that fit how your business actually works.

The question isn’t whether low-code development is powerful enough. It is. The question is: What problem do you want to solve first?

Start there. Build one low-code solution. See how it works. Then build another. Before you know it, you’ll have transformed how your organization develops applications.

]]>