---

Stop Guessing: How Prompt Coach Trains You to Actually Talk to Copilot

I’ll start with a confession. After spending some serious time with Microsoft 365 Copilot’s Prompt Coach agent, I came to a humbling realization: for thirteen years, I have been giving my wife improper instructions. Maybe my ambiguity has resulted in some strange lover’s quarrels and to that end, I must also apologize to my spouse…its partially my fault.

“Can you grab something for dinner?” is a prompt with no goal, no context, no constraints, and no format. It is the marital equivalent of typing “help me with the project” into Copilot and being mildly offended when the output is useless. My wife, bless her, has been doing the work of an LLM for over a decade. Inferring intent. Filling in gaps. Producing a reasonable response from input that, frankly, did not deserve one.

Next time I’ll ask Q if she’d just stop at our favorite Jamaican restaurant and get me some curry goat, rice and peas, and cabbage.

Most people who try Microsoft 365 Copilot for the first time have the same experience. They type something vague, get back a generic, soulless response, and quietly conclude the hype was overblown. The hype isn’t overblown. The prompt is. The gap between a mediocre output and a genuinely useful one almost always comes down to how you structured the request.

The good news is that Microsoft has baked an answer to this directly into the platform. It’s an agent called Prompt Coach, and it teaches you the fundamentals of effective prompting while you work, not in some separate training module you’ll never finish. The better news is that the skills transfer. Once you internalize how to talk to Copilot, you’ll find yourself accidentally becoming a better communicator with humans, too. Over time, your spouse will thank you.

This article walks through Microsoft’s GCSE framework for strong prompts: Goal, Context, Source, and Expectations. And it shows how Prompt Coach reinforces each one until clean prompting becomes muscle memory.

What Prompt Coach Actually Is

Prompt Coach is a pre-built agent template available in Microsoft 365 Copilot. You can install it from the Agent Store and run it inside the Copilot app, where it acts less like a tool and more like a patient teacher sitting next to you, gently judging your life choices.

It does four things: helps you generate well-structured prompts, analyzes prompts you’ve already written, fixes the broken ones, and walks through worked examples that explain why a given prompt is effective. It works through an iterative feedback loop. You give it a rough idea, it asks clarifying questions, and you end up with something far sharper than what you started with.

Prompt Coach is my go to. As a Power Platform developer I use it to refine prompts I embed into Power Automate flows, and to help me generate instructions for agents in Copilot Studio. The point is this: use it as long as you need to. Over time, it will become second nature to write prompts that net you the outcomes you actually want, instead of whatever Copilot guessed you wanted while you weren’t looking.

The Four Pillars: Goal, Context, Source, Expectations

Microsoft’s own internal framework for prompting is referred to as GCSE: Goal, Context, Source, Expectations. Every strong prompt answers four questions before Copilot ever sees it. Whichever vocabulary you prefer, the mental model is identical.

1. Goal: What do you actually want?

The goal is the non-negotiable piece. If your prompt has nothing else, it needs this. A goal is the specific outcome you want Copilot to produce. A draft email. A summary. An analysis. An outline. A comparison.

The mistake most people make here is confusing context with a goal. “I am a consultant who regularly requests access to my clients’ environments. Rewrite this email to ask IT for environment access” gets you part of the way there, but it’s mostly background, not an objective. “Rewrite a professional email requesting IT environment access” is a goal.

Where Prompt Coach helps: when you feed it a vague goal, it pushes back. It asks what kind of output you want, what success looks like, and whether you’re trying to inform, persuade, decide, or summarize. That nudge alone fixes maybe half of all bad prompts.

2. Context: Why does it matter, and who’s involved?

Context is the background information that lets Copilot tailor its response to your actual situation. This is where you tell it who the audience is, what the project is about, what’s already been decided, what tone is appropriate, and any history that affects how the response should land.

A status update for your skip-level executive reads very differently from one for your peer engineering team. Copilot can’t infer that from “draft a status update,” and honestly, neither could I. But it absolutely can deliver if you say “the audience is our CFO, who hasn’t been close to this project and cares mostly about budget impact and timeline risk.”

Where Prompt Coach helps: it consistently asks the “who is this for and why” question. Over time, you start front-loading that information without being prompted, which is the whole point.

3. Source: What should Copilot ground itself in?

Source is where you specify which information Copilot should draw from. A specific SharePoint folder. A Teams channel. A particular file. Emails from a date range. Standard corporate language from a given domain. Grounding your prompt in the right sources is what separates a generic output from one that’s actually accurate and relevant to your situation.

Where Prompt Coach helps: it flags when you’ve referenced something without being specific about it. If you mention “the project document” without naming it, Prompt Coach will ask which one. That habit alone prevents a surprising number of hallucinated details.

4. Expectations: What are the boundaries and format?

Expectations cover both your constraints and the shape of the output. Word counts. Tone restrictions. Things to avoid. Scope limits. And the format itself: bullet list, table, paragraph, email, slide outline, JSON, executive summary, FAQ.

Specifying expectations isn’t a nice-to-have. The same content delivered as a wall of prose versus a clean three-column table is, for most business purposes, an entirely different deliverable. Expectations are what stop Copilot from producing a 2,000-word essay when you needed three bullet points.

Where Prompt Coach helps: it routinely suggests format improvements you wouldn’t have thought of. Asking for “an analysis” might prompt it to suggest a table comparing options against criteria, with a short narrative recommendation underneath. That’s a better answer than what you would’ve asked for, which is a mildly insulting thing to admit but here we are.

Prompt Coach in Action: A Worked Example

Here’s what this looks like in practice. A consultant submits a reasonable but under-specified prompt to Prompt Coach: “I am a consultant that needs that regularly requests access to my clients environments. Rewrite this email to ask IT for environment access.” Prompt Coach recognizes the instinct to improve the prompt is right, and responds with a plan to do three things in one pass.

First, it analyzes the original prompt. The prompt does have some things going for it: it states the role, identifies the task, and names the audience. But Prompt Coach calls out exactly where it falls short.

The prompt is under-specified. Goal clarity, context, tone expectation, constraints, and output expectations are all missing or vague. Copilot will guess at each of these and guessing is what leads to weak or unusable drafts.

Next, Prompt Coach rewrites the prompt with all four pillars in place: a clear goal, full context, grounded source material, and explicit expectations for tone and output format.

That improved prompt then produces a clean, professional email ready to send not a template that needs another hour of editing.

The quality of Copilot’s output is directly tied to how complete your prompt is. By clearly defining Goal, Context, Source, and Expectations, you turn Copilot from a “rewriter” into a reliable drafting assistant.

Why Prompt Coach Beats Reading a Cheat Sheet

Cheat sheets and one-off training sessions don’t move the needle on Copilot adoption because prompting isn’t an information problem. It’s a habit problem. People know they should add context. They forget in the moment because they’re busy and the blank prompt box doesn’t ask for anything specific. It just sits there, mocking you with its emptiness.

Prompt Coach changes that by interrupting the bad habit at the exact moment it’s happening. You write a weak prompt, the agent flags it, asks the missing questions, and you end up with a strong prompt and a small lesson about why it’s stronger. Repeat that loop fifty times across a couple of weeks and the structure stops feeling like a checklist and starts feeling like the only sensible way to ask for anything.

That’s the real value here. Not that Prompt Coach writes your prompts for you, but that it trains you to write them yourself. And once you’ve internalized Goal, Context, Source, and Expectations, every other Copilot experience in Microsoft 365 gets dramatically more useful overnight.

Getting Started

Prompt Coach is available as an installable agent from the Microsoft 365 Copilot Agent Store. Install it once, pin it in your Copilot app, and use it as your sparring partner for any prompt you’re not sure about. Especially the high-stakes ones, where a generic output would actually cost you time.

The first week will feel slow. By the third week, you’ll be writing prompts that include all four pillars without thinking about it, and the people on your team who skipped this step will be wondering why your Copilot outputs are so much better than theirs.

It’s because you stopped guessing.

And, if you’re lucky, your spouse stopped guessing too.

Introduction

The era of open-ended AI ideation is ending. What’s replacing it is disciplined product work. Sessions are no longer judged by how inspiring they sound, but by what they actually enable. Teams aren’t tired of AI. They’re tired of pilots that never ship, noise without signal, and dashboards that can’t prove value.

Brainstorming still matters. But after an expensive huddle, the question that lingers is simple. What did we build that someone can actually use?

You hear it a lot lately. SaaS is dead. ERP is dead. That’s overstated. Deals are still being signed. Platforms are still being bought. What’s really dying is patience. Organizations are reacting to years of bold promises followed by uneven delivery. Capabilities sold as transformative end up incremental. Timelines stretch. Value becomes harder to explain.

Disappointment comes first. Then fatigue. Then frustration. Eventually it shows up where it always does. Tighter budgets. Slower buying cycles. Less trust in the partners brought in to help. Not because the models don’t work, but because the outcomes haven’t matched the rhetoric.

That tension is reshaping how leaders think about AI and transformation. Ideas alone aren’t enough anymore. Activity isn’t progress. What matters is whether the work leads to something shippable, measurable, and owned. If it doesn’t, it blends into the growing pile of initiatives that sounded promising and changed very little.

That shift in expectation is the real story.

Fear of Being Left Behind

A major driver behind many of these costly sessions is fear. Fear of being left behind. AI is everywhere and it’s moving fast. Organizations don’t have to wonder if their competitors, suppliers, or customers are investing in it. They are. That creates pressure to act. Invest now. Build now. Ship something now. And that pressure isn’t imagined. It’s justified.

The problem is what happens next.

Too many teams stop at awareness. We know the market expects AI. We know our competitors are using it. So motion becomes the goal. More tools. More pilots. More demos. Less clarity. The focus turns outward when it should be turning inward.

The harder questions get skipped. Is AI creating business value? Are operations actually better, or just different? Are employees more effective, or simply surrounded by tools they didn’t ask for? When those answers are unclear, the issue isn’t speed. It’s intent.

Knowing others are “doing AI” doesn’t make an organization stronger. Improvement does. That requires stepping back from the noise and being honest about what’s working, what isn’t, and why. AI has to earn its place like any other serious capability. Through outcomes, not excitement.

This is where many strategies start to wobble.

Educate

I recently participated in a hackathon, and the problem showed up almost immediately. The group didn’t have a baseline. Not on the tools. Not on the environments. Not on how anything connected. We could have pushed through and checked the box. That would have been easy. It also would have been meaningless.

The issue wasn’t effort or intelligence. It was context. Basic concepts like environments and connectors became blockers, not because they were complex, but because they were unfamiliar. That raised an uncomfortable question. Who owns that gap? The organization? The facilitator? Me? The goal was to move fast and show what the tools could do. Without shared understanding, speed just amplified confusion.

What helped wasn’t more features. It was grounding. A short deck. High-level. No hype. What each tool does. Where it fits. How the pieces connect. That alone changed the room. Once everyone had a shared mental model, we could build. No-code and low-code tools did the rest. The work improved. The conversation shifted.

That’s when the real lesson landed.

We didn’t need better tools. We needed more time to educate before execution. AI is still intimidating for a lot of people. The anxiety is real, especially for those who fear displacement. That fear doesn’t come from the technology itself. It comes from not understanding how humans stay in the loop and where judgment still matters.

Education isn’t optional. It’s the prerequisite. Organizations either invest in it deliberately or pay for it later through rework, confusion, and missed value. Tools don’t fail on their own. They fail when people are asked to use them without context.

Move with Intent

Once education is in place, the next step is execution. Not rushed execution. Intentional execution.

A colleague shared something that stuck with me. The best hacks start with use cases people already recognize. Real work. Familiar pain. Problems the room doesn’t need explained. When everyone can rally around the same use case, momentum follows. When they can’t, even strong builds struggle to land.

For this hack, I came in top-heavy. Too much solution. Not enough grounding. Combined with the earlier education gap, it could have gone sideways fast. We started with the tech when we should have started with the work.

If you want value from a hackathon, poll the group first. Ask simple questions. What task eats up your time every week? What work do you dread because it’s manual? What would make your day easier if it disappeared? Those answers matter more than any roadmap or demo.

What came out of this hack wasn’t flashy. It didn’t need to be. We used a SharePoint list, built a Copilot Studio agent, and added two flows to review vendor documents for compliance. Work that was previously manual became automated. No tab switching. No new windows. The value was immediate because it showed up where the work already happens.

That’s the difference intent makes. If we had identified that use case upfront, we could have scoped tighter and built cleaner. What took eight hours might have been much closer to production-ready. Not because we worked harder, but because we worked on the right thing from the start.

Don’t Take My Word for It

Collaboration between consultants and organizations matters more than most people admit. Real collaboration means challenge. You’re writing the check. We need you for references and repeat work. The incentives are aligned. So push us.

If an explanation doesn’t make sense, say so. If the value isn’t clear, ask why. That tension is healthy. It leads to better thinking, better designs, and better outcomes. It keeps everyone honest.

This work is expensive. AI credits cost money. Implementations cost money. Time costs money. And something will get implemented whether you’re in the loop or not. Staying silent doesn’t reduce risk. It just shifts it.

A lot of fatigue doesn’t come from bad intent. It comes from disengagement. Being too hands-off. Not asking why a solution is framed a certain way. Sometimes the answer isn’t an agent. It’s an automation. Sometimes that automation just needs a prompt. Other times it needs semantic search, OCR, or better data upstream.

The effort might be small. It might be significant. It might stretch the budget. That’s part of the work. What causes problems is assuming the first idea is the right one and letting it move forward unchecked.

The road to poor implementations is paved with good intentions. The antidote is simple. Stay involved. Ask questions. Challenge assumptions. That’s how AI stops being noise and starts delivering value.

Conclusion

AI isn’t failing organizations. Undisciplined execution is.

The shift happening right now isn’t about tools, platforms, or models. It’s about expectations. Leaders are no longer impressed by ambition alone. They want evidence. They want things that work. They want outcomes they can point to and defend. That’s not resistance to AI. That’s maturity.

Fear will keep driving investment. That won’t change. Education will keep determining whether those investments pay off. That shouldn’t be optional. And execution, when it’s grounded in real use cases and challenged at every step, is what separates progress from noise.

Hackathons, pilots, and workshops can still be powerful. But only when they’re anchored in shared understanding, familiar work, and clear intent. Otherwise, they become expensive rehearsals for things that never ship.

The same goes for partnerships. Consultants don’t need blind trust. They need engaged counterparts who ask hard questions, demand clarity, and stay involved. That pressure doesn’t slow things down. It prevents waste. It makes the work better.

AI will continue to move fast. Budgets will continue to tighten. Patience will continue to thin. The organizations that succeed won’t be the ones doing the most. They’ll be the ones doing the right things, in the right order, for the right reasons.

Educate first. Execute with intent. Stay involved. Challenge everything that doesn’t clearly deliver value.

That’s how AI stops being a distraction and starts becoming a capability.

For years I built automations wrong. It wasn’t that I didn’t know the technology. I was asking the wrong questions. A mentor taught me something that changed how I work: focus on the outcome. Transparent moment here — there were times I didn’t serve my customers as well as I could have because my thinking was too tactical, too event-driven, and not anchored to the goal.

Most automation workflows follow the same pattern: a trigger fires, actions run, decisions branch, and then the workflow stops until it fires again. Those steps matter. But when you step back and ask what all of those steps are actually trying to accomplish, you land on a more important question. What is your goal?

I meet clients constantly and they almost always lead with the same question: “can this tool meet my needs”? That’s fair. But here’s what I’ve learned. Every tool requires some concessions. If it can’t get you to your goal, it’s not the right tool regardless of how many features it has.

I want your business. That’s honest. But more than that, I want to earn the kind of relationship where you come back whether we sign this SOW or not, whether it’s next week or two years from now. That only happens if I actually help you get somewhere.

That question applies to how I run my own day too. I started asking myself what success actually looks like before I sit down to work, and the answer shaped everything. I want one place that reflects my entire day. Meetings, tasks, notes, all current, all in one spot. That goal is what drove me to build the morning process I now run every day with Claude Cowork as the orchestrator.

The Technology

The stack is intentionally minimal. Claude Cowork acts as the orchestrator, the intelligence that decides what needs to happen and in what order. It connects to Notion via the Notion MCP server, which gives it the ability to read and write directly to my Notion workspace. An AI orchestrator, a communication protocol, and a single workspace destination.

Each morning, the process kicks off by pulling my meetings for the day and placing them into a Notion database. From there it creates a daily digest, a dedicated entry that surfaces those meetings alongside the tasks I need to complete. It also creates a daily notes page and links it directly into the digest so everything is connected before I’ve touched a single thing manually.

Why the Goal-Driven Aspect Matters

Here’s where most automation falls short. It runs a checklist. Step one, step two, step three, regardless of what’s already been done, what’s changed, or what’s actually needed. That’s not intelligent orchestration. That’s a script with better branding.

What I wanted instead was a system oriented around a goal: my day workspace is current and usable. That’s it. Everything else, syncing meetings, creating the digest, linking notes, refreshing tasks, is in service of that goal. The orchestrator doesn’t ask what did I do yesterday. It asks what does today’s workspace need right now.

That distinction matters because my day doesn’t stop at 8am. Meetings get added, priorities shift, and sometimes I need the digest to reflect something that happened after the morning run. A goal-driven system handles that naturally. A midday refresh doesn’t restart the workflow from scratch. It checks what’s stale and updates only what needs updating. The digest gets updated, not recreated. The notes page preserves what I’ve written. Meetings that changed get synced and the ones that didn’t are left alone.

The Real Goal

What I’m ultimately working toward is managing my entire day from one place. Not a dashboard, not a report. A living workspace I can trust to be accurate whenever I look at it. The morning process gets it ready. The daytime refresh keeps it honest. Claude Cowork stops being an automation tool and starts being something closer to a daily operating system.

The goal isn’t to run a workflow. The goal is to always know where things stand.

Intro

The Power Platform is one of the most capable low-code ecosystems available today. Power Pages, Dataverse, Power Automate. When used together, teams can deliver real business solutions quickly, often without writing a single line of code.

But every platform has boundaries. And when those boundaries are crossed, users feel it immediately.

This is the story of a client who built the right solution on the right platform until scale turned a 60‑minute processing delay into a serious risk to adoption. The fix was not a wholesale rewrite or a departure from Power Platform. It was a single, targeted Azure Function that reduced processing time to under five minutes.

---

The Setup: A Well-Designed System With a Hidden Ceiling

The client built a customer intake system using Power Pages. Users completed a detailed, multi-question form, and each answer influenced which recommendations would be unlocked for their profile. Those recommendations were stored and managed in Dataverse.

The decision engine lived in Power Automate. When a form submission arrived, a flow iterated through every question, evaluated the response, applied business rules, and wrote the appropriate recommendations back to Dataverse.

From a design standpoint, the solution made sense. The logic was clear, the flow was readable, and for a time, it worked exactly as intended.

Until it didn’t.

---

The Breaking Point

The issue was not flawed logic. It was the execution model.

Power Automate processes loops sequentially. Each question required its own iteration. A check, a condition, and one or more Dataverse writes. Multiply that by dozens of questions per submission and the cost became obvious.

A single form submission took close to 60 minutes to fully process.

At low volume, this delay was tolerable. Users submitted a form and eventually saw their recommendations appear. But as usage increased, the system began to strain.

Submissions backed up. Users refreshed pages, assumed something had broken, or abandoned the process altogether. Support tickets increased. What had once been an inconvenience became a user experience problem that threatened confidence in the entire platform.

---

The Pull of Staying Low-Code

The initial instinct was to optimize the existing flow. Could loops be consolidated? Could conditions be simplified? Could parallel branches help?

The hesitation was understandable. The client had invested heavily in Power Platform. Their team knew it well, governance was in place, and introducing custom code meant new pipelines, monitoring, and skill sets.

But after profiling the flow, the conclusion was unavoidable. The bottleneck was structural. As long as the logic ran inside a sequential loop, no amount of tuning would produce the performance gains the platform needed.

---

A Surgical Fix

Rather than re-architect the system, we proposed a targeted change: move the recommendation processing logic out of Power Automate and into a JavaScript Azure Function.

Not a rewrite. Not a migration away from Power Platform. Just a surgical swap.

The Azure Function would receive the form submission data, evaluate all recommendation rules in a single execution, and write the results back to Dataverse in one pass. No per-question looping. No waiting for each iteration to finish before starting the next.

---

Building the Bridge

The most time-consuming part was not the code. It was extracting the business logic.

The recommendation rules lived across dozens of Power Automate actions, conditions, and expressions. Translating that into JavaScript meant reverse-engineering the flow, rule by rule.

We worked closely with the client to document every decision path, including edge cases and conditional dependencies that were not immediately obvious from the flow diagrams. Some rules were simple mappings. Others involved layered conditions such as “if Question A is X and Question C is Y, unlock Recommendation Z.”

The Azure Function connected to Dataverse using the Web API, with proper authentication, logging, and error handling built in. Unlike the original flow, the new solution provided clear, centralized visibility into execution and failures.

Testing was deliberate. We ran historical submissions through the function and compared the results to the Power Automate outputs, ensuring parity. Edge cases that had occasionally caused the flow to stall or skip records were handled explicitly in code.

---

The Result

The impact was immediate.

Processing time dropped from 60 minutes to under five minutes, a reduction of more than 90 percent.

Users submitted forms and saw recommendations populate almost immediately. The backlog disappeared. Support requests stopped. Most importantly, the platform could now scale without performance degrading as submission volume increased.

The broader architecture remained intact. Power Pages continued to handle the front end. Dataverse remained the system of record. Power Automate still orchestrated other workflows. The Azure Function simply replaced the one component that needed a different execution model.

---

The Bigger Lesson

Low-code does not mean no-code forever.

The Power Platform excels at accelerating delivery and empowering teams. But scalable solutions require understanding where the platform’s strengths end and where specialized tools belong.

The success of this project was not about abandoning Power Platform. It was about identifying a specific constraint, choosing the right tool to address it, and integrating that tool cleanly so the rest of the system continued to function exactly as before.

If your Power Platform solution is hitting performance limits, the answer is not always “optimize the flow.” Sometimes, it is a few hundred lines of code in exactly the right place.

Facing a similar challenge? We help teams strike the right balance between low-code speed and custom-code performance.

Introduction

When thinking about your Power Platform environment, it’s important to shift your mindset. Whether you’re a small business or a large enterprise, investing time upfront to secure your environment and follow best practices is crucial. One of the biggest reasons? Scalability.

In my opinion, some platform deployment failures stem from a lack of strategic planning for business growth. As your company scales, new challenges will emerge. While we can’t predict every obstacle, there are common patterns in how businesses and applications evolve. And if you believe AI agents will make business applications obsolete, let’s clarify something—policy applies to both.

At its core, policy isn’t about what you implement; it’s about how you implement it. It’s a strategic framework, not just a tactical checklist.

What are Data Loss Prevention (DLP) Policies?

According to this nice shiny definition found on Microsoft Learn:

Data Loss Prevention (DLP) is a critical aspect of maintaining data security and compliance within the Microsoft Power Platform ecosystem.

My definition is much shorter and it simply is: “You can’t do that because the organization said so!”

Connectors

DLP policies play a critical role in keeping company data from unintentionally ending up on platforms like LinkedIn. One of the Power Platform’s biggest strengths is its access to over 1,000 connectors—and if one doesn’t exist, you can build it. But realistically, do users need access to every connector? Do they need to create custom ones? The short answer is no.

Because anyone with an M365 license has access to the Power Platform, technically, anyone can be a maker. While Microsoft encourages citizen development by providing open access to the default environment, the responsibility of enforcing policies doesn’t fall on Microsoft—it falls on the organization. That means preventing data leaks and securing Power Platform solutions isn’t optional; it’s a core responsibility for license owners.

Strategic Thinking

The more I engage in governance projects, the more I notice a common trend—and it’s not the lack of policy that concerns me. What worries me most are the gaps in strategic thinking when it comes to the Power Platform. Too often, organizations approach it as just another tool rather than a foundational part of their technology strategy.

Like any enterprise software, the Power Platform needs a well-thought-out deployment strategy. It’s not just about setting up policies; it’s about ensuring long-term scalability, maintaining clean and reliable data, and prioritizing security. Without a strategic approach, organizations risk inefficiencies, data sprawl, and security vulnerabilities that could have been prevented.

Over time, little by little, I’ve been encouraged to see companies shifting their perspective. What was once seen as a “neat little toy” bundled with E3 licensing is now starting to be recognized as a critical piece of the technology roadmap—powering mission-critical applications and driving real business outcomes. I hope this trend continues. I hope implementation include a more sound approach.

The Consultants Responsibility.

It’s also up to the consultant. As we engage with clients and deploy the Power Platform, we have a responsibility to take real-world use cases—including the horror stories—and use them to shape better strategies moving forward. Experience is one of the best teachers, and it’s our job to ensure that lessons learned don’t go to waste.

I’ve worked with combative clients who initially saw no need for a strategic approach to Power Platform implementation—until I helped them see the bigger picture. Often, resistance comes from a lack of understanding, not a lack of willingness. Once decision-makers recognize the risks and long-term implications, they begin to appreciate the value of governance.

We also can’t assume that users and citizen developers will fully grasp the security risks tied to the connectors they use—that’s not their responsibility. It’s on us to establish the right policies, provide guidance, and build a framework that protects both the organization and its data. In governance, being proactive isn’t just a best practice—it’s a necessity.

Informing Governance as a Whole

In my experience, the more we discussed governance within the Power Platform, the more it prompted decision-makers to rethink governance across their entire IT landscape. These conversations often led to deeper questions: What hidden risks exist? Where are the data silos? Who has access to sensitive information that they probably shouldn’t?

The real value in these discussions is that while I’m advocating for a strategic approach to the Power Platform, I’m also making the case for stronger governance overall. It’s not just about one tool—it’s about creating a cohesive, well-managed IT environment that serves the entire organization. When governance becomes a priority, it enhances security, improves data integrity, and ultimately drives better business outcomes across all systems.

Some might argue otherwise, but let’s take a step back—where does the data powering the Power Platform actually come from? In many cases, especially when integrating with REST services to connect to a non-Dynamics ERP or even when working within Dynamics, the data originates from silos. These are the same silos feeding into ERPs, business processes, and, more concerningly, systems that IT may not even be aware of.

This is why governance isn’t just about securing the Power Platform—it’s about understanding and managing the entire data ecosystem. Without proper oversight, organizations risk building solutions on fragmented, uncontrolled, or even unauthorized data sources. Make governance a crucial part of not just platform strategy, but overall IT strategy.

Call to Action

If you’re struggling with governance, take action today:

• Engage Your Partner – If you have a trusted partner, reach out for an assessment to identify gaps and improve your strategy.

• Tap Into the Community – If you have general questions, the Power Platform community (myself included) is here to help. Don’t hesitate to ask.

• Leverage Microsoft Tools – Install the CoE Starter Kit to gain insights and control over your environment.

• Educate Yourself – Explore Microsoft Learn for governance best practices and guidance.

Governance isn’t just a checkbox—it’s an ongoing effort. Take the next step today!

1. Introduction
2. Governance
3. The reasons that we’re here
   1. Lack of Version Control
   2. Deployment Instability
   3. Difficult to troubleshoot issues
4. Deploy managed solutions
5. Call to Action

Introduction

I don’t want to be the bearer of bad news—well, maybe just a little. My goal is to save you from yourself, so let me be clear: WE DO NOT CREATE UNMANAGED LAYERS IN PRODUCTION!

If you’re serious about maturing on the Power Platform, there are a few fundamental principles you need to grasp. I get it—the way Power Platform is set up, with everyone having a default environment, can feel like the wild west. But there are some non-negotiables. At the very least, you should be working with two environments—ideally, three: one for development, one for testing, and one for production-ready solutions. You know, a proper application lifecycle management (ALM) process—the same concept they drilled into us in college.

In theory—and in practice, based on what I’ve seen over the years (including my own mistakes)—you can do whatever you want. But at some point, you need to stop, take a step back, and ask yourself: Is a “hot fix” in production really worth the risk?

My answer? Absolutely not. And here’s why.

Governance

Yes, the G word—governance. Autonomy is great—until there’s a data breach. Then suddenly, we’re all asking how our favorite retailer leaked our PII (Personally Identifiable Information), and I’m staring at an email telling me to cancel my credit card, pack up, and start a new life.

Okay, maybe this article isn’t that dramatic—but it could be. Governance isn’t just a Power Platform concern; it applies everywhere. And while we champion secure backends like Dataverse, security only works if we take governance seriously. So, do yourself a favor—treat it like it matters. Because it does.

I have the privilege of working alongside some of the world’s premier experts in governance and compliance, partnering with some of the biggest names in business. And time and time again, we find organizations falling into one of two categories:

The Gentleman’s Approach

These organizations recognize the power of Power Platform but haven’t fully deployed it across their enterprise. They want to get ahead of the chaos by implementing governance before things spiral out of control.

Please Save Us

On the other hand, some organizations have already deployed Power Platform—without guardrails. Now, it’s out of hand, and they’re desperately looking for a way to regain control before things get worse.

If you’ve taken the Gentleman’s Approach, thank you. It makes life so much easier when we can focus on methodology and toolkits to set you up for long-term success.

If you’re in the Please Save Us camp, thank you as well. Acknowledging the problem and committing to steering your organization in the right direction is a crucial step.

The Problem with Poor Implementations

Here’s the thing—lack of governance in Power Platform leads to poor adoption. We have this powerful platform at our fingertips, but if security gaps, broken processes, or unchecked risks get in the way, no one wants to use it—or worse, no one can use it safely.

CIOs and the Tough Questions

Do CIOs make my job harder when it comes to governance? Yes. And they should. The tough questions need to be asked. Don’t just take my word for it—press me, challenge me, ask for sources. This is your organization, your investment, your future.

As a consultant, I care deeply about the services I provide, but at the end of the day, I will roll off your project at some point. My goal? To leave your organization better than I found it. And that is part of the reason we don’t create unmanaged layers in production!

The reasons that we’re here

Lack of Version Control

It’s right there, staring you in the face. You can do it. Just pop that flow open, add that missing action, and everything is right with the world—until it’s not.

Whatever the reason, you must operate with the mindset that tweaking production directly is not acceptable. You cannot predict unexpected behavior, and doing so completely undermines your version control and environment strategy.

If you have a production environment (and please don’t tell me it’s the default environment—that’s a conversation for another day) and some form of environment strategy, respect it.

Make your changes in the lower environments, test them, get sign-off, and deploy to production—the way it should be done.

Deployment Instability

In production, or at least in managed solutions within production, we have what are called solution layers. (I even included a nice, shiny image above to illustrate this—you’re welcome.)

When you create unmanaged layers, you introduce the possibility of deployment failures down the line. The artifacts and components in future deployments weren’t designed to handle the unexpected behaviors you introduced by manipulating a solution directly in production.

Save your deployments. Do it the right way.

Stick to the process—develop, test, get approval, deploy. Your future self (and your team) will thank you.

Difficult to troubleshoot issues

The degree of difficulty in troubleshooting can vary—but it becomes exponentially harder when you don’t even know what you’re looking for.

The unpredictability of removing a single component, a line of code, or an action in a flow can drive even the most rational person up a wall. One small tweak can have ripple effects you didn’t anticipate, turning a simple fix into a time-consuming nightmare.

Let’s avoid unnecessary cleanup, frustration, and sweat-inducing emergencies. Follow best practices, respect your environments, and don’t create an unmanaged layer in production.

Regardless of which camp you fall into, governance matters—whether you’re planning ahead or trying to clean up the mess.

Deploy managed solutions

This should go without saying—but I’ve seen it all. I’ve been on engagements where entire production environments were packed with unmanaged solutions, and it took months to convert everything to managed.

I want my clients to be set up for success, even if it means being a thorn in someone’s side. I get that introducing complexity, governance, and strategy might seem like extra overhead for IT. But trust me—it’s worth it.

Now, think about the alternative: years of unmanaged layers, uncontrolled deployments, and an unrestricted environment that you still call production. The overhead and nightmares that come with that far outweigh the effort of doing things the right way from the start.

If your goal is to build a mature Power Platform model, then you need a strategy in place. Create the necessary environments, security groups, and pipelines to establish a structured, secure, and scalable framework.

Call to Action

It All Starts with Education

Educate your business units, educate IT, heck—educate your dog if you have to. A mature Power Platform adoption is an organizational effort, not just an IT initiative. Do it the right way.

Use the Right Tools

You have plenty of tools at your disposal:

✅ The CoE Starter Kit – Provides a holistic view of your environment.

✅ Power Platform Admin Center – If you’re not ready for the CoE, at least establish a management strategy here.

✅ Security Groups (M365 or Entra ID) – Set them up early to enforce governance and access control.

One Rule Above All

Whatever you do, do NOT create unmanaged layers in production.

1. Introduction
2. The Logic Engine Behind Power Apps
3. Solution
   1. Canvas App
      1. Project Proposal Main Grid
      2. Project Proposal Entry Form
   2. Power Automate
      1. Handling Scope Logic

Introduction

One would think that by now, we’d all be settled on what Power Automate can do. But surprisingly, that’s not the case. It feels strange to still use the word “potential” when talking about Power Automate, especially since I’ve seen it achieve some pretty amazing feats. It has served as an integration point between the Power Platform and external systems, connected Azure and the Power Platform, and even acted as the logic layer for Power Apps. Yet, I still find myself in conversations with customers, exploring the true depth of its power and capabilities.

Over the next few weeks, I’ll be sharing more about what Power Automate can do. This week we’ll be talking about Power Automate as the logic layer for Power Apps. Follow along to learn more!

---

The Logic Engine Behind Power Apps

Power Apps is very capable. The problem is that the more complex your logic gets, the more complicated your formulas become. In my experience as a Power Platform developer, it’s rare to build a solution without involving at least one Power Automate flow. These flows are usually triggered by something happening in Power Apps—either directly when the app triggers an automation or once a record that was changed in the app meets certain conditions (like a CRUD operation in Dataverse, SQL Server, or SharePoint).

---

Solution

Below is a refined version of your text, maintaining a casual style and clear flow:

---

Our solution will include two components: Power Apps and Power Automate. We’ll be working on a “Project Proposal” process, where every proposal requires approval. Depending on factors like scope or budget, the proposal may need multiple approvers or just one. I won’t walk through the entire build here since this post is purely informational, but I will share screenshots and add details to illustrate each step.

---

Canvas App

Project Proposal Main Grid

When you first open the app, you’ll see a main grid listing all project proposals. Each row shows basic details like project name, budget, primary approver, and scope. This screen lets you quickly scan and select any proposal for more information.

---

Project Proposal Entry Form

This is where you enter all the core information for a new project proposal. It includes fields for basic details like project name, estimated budget, and scope. Once you fill out the form and submit, the proposal is added to Dataverse and triggers the Power Automate flow to handle scope logic.

---

Power Automate

Handling Scope Logic

The crux of this solution is how we’re handling our logic. Sure, I could have written an expression with multiple If statements—maybe even nested ones—to get the result I wanted. But instead, I’m passing the necessary parameters to the Flow and letting Power Automate handle the conditional logic. If I ever want to add more conditions, I can do it in a visual way without diving into Power Fx.

Power Automate also offers other logic controls beyond simple If conditions, such as switch statements and parallel branches. This gives you a drag-and-drop interface to manage complex pathways—like sending notifications to different groups or looping through multiple records—without having to manually write or manage code. It’s all about making your logic more transparent and maintainable, so you can expand on it as requirements evolve.

Thank you for reading!!

1. Introduction
2. The Role of Proof of Concepts
3. Rapid Prototyping
4. Conclusion

Introduction

As a consultant, I receive many questions about the Power Platform and its viability as a SaaS solution:

• “Is it secure?”

• “Is it mature enough to handle enterprise-grade solutions?”

• “Why not just use a ‘pro’ developer?”

These are all valid questions because they ultimately point to a larger, fundamental question that organizations typically have — and it can often be summed up with one word: HOW.

While “why” is often the first lens through which we view a problem, I’ve found that dwelling too long on the “why” can sometimes create more uncertainty than clarity. “Why” tends to be conceptual, inviting philosophical or theoretical discussions that don’t always lead to actionable steps. On the other hand, “how” shifts the conversation toward execution. It’s grounded, specific, and provides a strategy to address the questions at hand.

Take security, for example. If someone asks me why the Power Platform is secure, I could say, “It’s built on Microsoft’s trusted infrastructure.” While this is a fair response, it often leads to more follow-up questions: “Why is Microsoft’s infrastructure trusted?” or “Why should I believe it’s secure for my use case?”

Instead, focusing on the how delivers a clearer picture. For instance, how is the Power Platform secure? Through Azure Entra ID (formerly Azure AD), which enforces strong authentication, conditional access, and Single Sign-On (SSO). It goes further by integrating Multi-Factor Authentication (MFA) to add an extra layer of protection against unauthorized access. This level of detail gives key stakeholders in organization such as the CIO, the developer, or IT, tangible reasons to trust the platform.

The same shift from “why” to “how” applies when organizations are exploring the Power Platform’s broader potential. And this is where Proof of Concepts (POCs) come in.

The Role of Proof of Concepts

Proof of Concepts bridge the gap between “why” and “how.” They take abstract ideas and translate them into tangible solutions. A POC allows an organization to validate a concept, ensuring it meets their specific needs before committing to a full-scale implementation.

For example, when someone questions the Power Platform’s ability to handle enterprise-grade solutions, a POC can demonstrate how the platform seamlessly automates workflows, integrates data, and scales to meet business demands. It provides a real-world answer to the hypothetical “what ifs.”

By focusing on the how with a POC, we not only provide clarity but also give stakeholders the confidence they need to invest in the solution. POCs empower decision-makers to move forward with certainty, backed by a tangible demonstration of the platform’s capabilities.

Rapid Prototyping

When it comes to the Power Platform, one of Microsoft’s standout features is its low-code/no-code approach. While planning and requirements gathering remain basic necessity for any enterprise solution, the development time is reduced.

Take Canvas Apps as an example. These are web applications, but unlike the earlier days of web development, where every pixel and element had to be meticulously coded, Canvas Apps simplify the process. They allow developers to visually design the interface by dragging and dropping components onto a canvas. This lets them spend more time focusing on integrating and leveraging backend data sources—whether through Power Automate flows or connectors that directly link the app to the necessary data.

This shift in development approach transforms timelines. What used to require four weeks of intensive coding can now be accomplished in two weeks. The focus shifts from manual coding to refining security, optimizing processes, and achieving meaningful business outcomes.

Yes, investing time and resources in the Power Platform is a commitment, but it’s one that accelerates outcomes. Development on the platform allows us to either achieve success more quickly or “fail fast,” providing valuable insights along the way.

When we fail fast, we uncover lessons that inform better decisions and sharper strategies. When we succeed, we’re not just building solutions—we’re celebrating the realization of a clear path forward. Either way, the Power Platform ensures we’re moving with purpose, minimizing delays, and maximizing the value of our efforts.

Conclusion

If you’re using an M365 license, whether it’s E5 or a lower tier, you already have access to the Power Platform. Chances are, these tools are at your fingertips, yet they might be overlooked in favor of subscriptions to other software.

This is where a Proof of Concept (POC) on the Power Platform becomes invaluable. A POC will do one of two things:

1. Draw you in – It can showcase the Power Platform’s potential, demonstrating its value as an enterprise solution tailored to your needs.

2. Drive you forward – It can help you reach a clear conclusion, whether that’s investing in the Power Platform or exploring alternative solutions.

But here’s the key: how would you know if you didn’t try it?

A POC offers the opportunity to explore, test, and validate the Power Platform’s capabilities within your unique business context. It’s a low-risk, high-reward approach to uncovering whether this suite of tools can transform your processes and deliver the outcomes you’re seeking.

Thank you for reading!

1. Introduction
2. SharePoint/Microsoft Lists
3. Solution
   1. Available Templates
   2. Step 1: Create list from template
   3. Step 2: Be creative!!
   4. Extra

Introduction

Recently, someone asked me what I do for a living. My standard response is, “I am a Microsoft consultant.” I phrase it this way because the scope of Microsoft’s ecosystem is truly vast. Before I started consulting organizations on tools like Azure and Power Platform, I didn’t fully appreciate just how expansive Microsoft’s solutions really are.

The response I got was a little different than what I usually hear from business users, and I believe it was shaped as much by geography as by the products themselves. Milwaukee, WI, where I’m based, is a city historically known for heavy manufacturing, motorcycles, and beer.

This industrial legacy extends across Wisconsin, which has long been rooted in factories and industries, often relying on ERPs like Epicor or SAP. While Microsoft products are widely used here, they’re often limited to familiar tools like Word, Excel, and Outlook. However, Microsoft is far more than Word—it’s a robust platform that includes Azure cloud services, enterprise solutions like Dynamics F&O and Business Central, and the Power Platform. These tools empower both pro developers and low-code creators to build innovative solutions that drive business transformation.

Now, with the introduction of generative AI and Copilot, the Microsoft ecosystem has expanded even further, unlocking new possibilities for productivity and automation.

For those who still know Microsoft primarily for Word, I’m continuing a mission I started earlier this year: raising awareness of the incredible features included with Microsoft 365 licensing. Today, my focus is on the Business Standard license, specifically how it enables rapid development of custom business applications using SharePoint and Microsoft List templates. Let’s dive in and explore how you can make the most of these tools!

SharePoint/Microsoft Lists

One of the key benefits of a Business Standard license is access to SharePoint. SharePoint is an incredibly powerful tool, offering exceptional value for its cost. It serves as a collaborative workspace with features like built-in document management, intranet capabilities, and the ability to host and manage data in lists.

One of the key benefits of a Microsoft 365 Business Standard license is access to SharePoint, a robust tool offering exceptional value. SharePoint serves as a collaborative workspace with features like built-in document management, intranet capabilities, and the ability to host and manage data in lists.

While we won’t delve into all of SharePoint’s functionalities, let’s focus on its versatile lists feature. These lists are powerful tools for organizing and managing data, and you don’t need to access SharePoint directly to use them. The Microsoft Lists application provides an intuitive interface to work with these lists, making them a convenient and powerful data source for your business needs.

A significant advantage of Microsoft Lists is its accessibility across multiple platforms. You can manage your lists on the go using the Microsoft Lists mobile app, available for both iOS and Android devices. Additionally, while there isn’t a dedicated desktop app for macOS, you can use Microsoft Lists as a Progressive Web App (PWA) on your Mac. This setup allows you to work with your lists directly from your desktop, providing a seamless experience across devices.

This cross-platform availability ensures that you can access and manage your data whenever and wherever you need it, enhancing productivity and collaboration within your organization.

Solution

The template we’ll focus on today is the Asset Management template. While there are many templates to choose from, this one offers a great starting point for tracking and managing assets. It’s important to remember that you’re not limited to the fields provided in the template. SharePoint lists are customizable, and adding a new field to tailor the template to your specific needs is relatively easy.

If the out-of-the-box template meets most of your requirements but falls short in one or two areas, simply modify it by adding the necessary fields. This flexibility allows you to make the template truly your own while saving time and effort on development.

Available Templates

For posterity these are the templates available in SharePoint/Microsoft Lists:

1. Issue tracker

2. Employee onboarding

3. Event itinerary

4. Asset manager

5. Recruitment tracker

6. Travel requests

7. Travel requests with approvals

8. Work progress tracker

9. Content scheduler

10. Content scheduler with approvals

11. Playlist

12. Gift ideas

13. Expense tracker

14. Recipe tracker

15. Reading list

16. Apartment hunting

17. Job application tracker

18. Product support metrics

Step 1: Create list from template

In this step, we’ll select the Asset manager template. This will guide you through a wizard-like experience. On the next screen, you’ll see a preview of how the list will look when populated with data. From there, you’ll name your list and choose the option to create it. In just a few seconds, you’ll have a functioning data source for your asset management process.

Step 2: Be creative!!

The next steps are entirely up to you. There are countless stories waiting to be told through data. As a business application developer, I tell the story of business data using tools like Power Apps and Power Automate. A data or business intelligence analyst might choose to use Power BI to craft insightful reports from the same data. The key takeaway here is that we now have a central repository for our data—one that was created quickly, can be easily iterated upon, and serves as a foundation for exploring what’s possible with Microsoft 365 licensing.

If you’re a CIO or business user, this approach can help you realize the potential of the Power Platform. It’s perfect for spinning up a quick proof of concept (POC) to demonstrate not just the art of the possible, but the art of what is. And what is—that Microsoft is far more than just Word. It’s an expansive, powerful platform ready to transform the way you work.

Extra

Next, I’ll share images of an application and flow I built using this list as the foundation. By starting with the Asset Manager template, I was able to significantly reduce the time spent planning out the architecture and get straight to work. This allowed me to focus on the “extras”—how I wanted the app to look and how I wanted to structure my flows.

In total, it took me about three hours to build and iterate on the process, refining my ideas about how everything should function. By integrating this data source with the Power Platform, users can rapidly develop solutions tailored to meet specific needs, enabling faster delivery and greater flexibility.

1. Introduction
2. Solution
   1. Step 1: Microsoft Forms
   2. Step 2: Microsoft Planner
      1. Create New Plan
         1. Select ‘New Plan’
         2. Name your plan
         3. Set Privacy and Sensitivity
         4. Create
      2. Buckets
         1. Creating New Buckets
         2. Add new bucket
         3. Enter bucket name: {Name of your bucket}
         4. Tasks
   3. Step 3: Power Automate
      1. Trigger
         1. When a new response is submitted
         2. Action (Get response details)
         3. Action (Update task details)
   4. End to end test

---

Introduction

I believe Microsoft 365 licenses often go underutilized, with many businesses purchasing them without fully exploring their potential. Time and again, I implement solutions for enterprise clients whose needs might not initially seem to require all M365 apps. However, I see these applications as building blocks for powerful solutions in today’s workplace.

I’m passionate about empowering organizations to achieve more, and I believe Microsoft shares this vision, as reflected in the capabilities offered in their standard licenses. One app with great potential is Microsoft Planner. While Planner isn’t as feature-rich as Project or DevOps, it’s a strong alternative to tools like Trello and the former and can significantly benefit task management.

In this discussion, we’ll explore how to enhance Planner using Power Platform, particularly Power Automate. You’ll gain insights into Planner itself and see how Power Automate extends its functionality with M365 components. Best of all, this solution doesn’t require premium licensing—so if you have at least a Business Standard license, you’re good to go!

---

Solution

Our solution will utilize three main components: Microsoft Forms, Microsoft Planner, and Power Automate.

• Front-end: We’ll use Forms to collect input from prospective customers.
• Automation: Power Automate will process this input, creating a follow-up task in Planner for each prospect.
• Back-end: Planner will guide the onboarding journey for each customer. Once they’re onboarded, their information will be stored in a SharePoint list, ready for use in a Canvas App for customer management (to be introduced in the next discussion).

This streamlined approach ensures a smooth transition from prospecting to customer onboarding.

---

Step 1: Microsoft Forms

We’ll start by creating a basic form in Microsoft Forms, which is fortunately very user-friendly. The field types are limited, so it’s hard to go wrong here. For this solution, Forms is a solid choice since we’re only collecting general data—not sensitive information. It’s akin to signing up for a newsletter (unless, of course, it’s from a political party during election season!). Overall, Forms is a safe and straightforward option for our data collection needs.

For clarity, Microsoft Forms provides several field types, including choice, text, date, ranking, Net Promoter Score, file upload, rating, and Likert scale. In our form, we’ll use the text field type for each of our four questions, with all fields set as required. The fields will be:

1. First Name
2. Last Name
3. Email
4. Reason for contacting us

This setup keeps things simple and captures just the essential information.

---

Step 2: Microsoft Planner

The next component of our solution is Microsoft Planner. There are multiple ways to create a plan in Planner, but since the goal is to encourage users to explore business applications they already have, we’ll stick with the standard, non-premium approach.

For fully automated plan creation, the Graph API for Planner can be used, either through a custom connector or by making HTTP requests in Power Automate. However, for this solution, we’ll take a straightforward approach by manually creating the plan directly in the Planner interface.

Create New Plan

Navigate to Planner and take the following steps:

Select ‘New Plan’

Name your plan

Set Privacy and Sensitivity

Create

Buckets

When you create your plan in Microsoft Planner, you’ll see it displayed in a board view or Kanban view, where each category is referred to as a bucket. You can customize these buckets based on your onboarding strategy for prospects, organizing them in a way that best fits your workflow.

Creating New Buckets

Follow these steps to create new buckets. You can create as many as needed for your process. For example, I created three buckets: ‘To do,’ ‘Won,’ and ‘Lost.’

Add new bucket

Enter bucket name: {Name of your bucket}

Tasks

Each bucket holds tasks that are linked to it. While you can create tasks manually, we rely on automation to handle this. When a new form submission is received, a task will automatically be created in the ‘To do’ or starting bucket.

---

Step 3: Power Automate

Our flow will be simple: we’ll take the form responses and automatically create a Planner task to follow up with the client.

Trigger

When a new response is submitted

When a new form response is submitted, our flow will trigger automatically. Make sure to select the correct form from the dropdown menu in Power Automate to ensure the flow works with the form you’re using.

Action (Get response details)

The next step in the flow is to add the action to Get Response Details from the form submission. Select the same form as the Form Id that you want to receive responses from. Then, use the dynamic content from the previous step to set the Response Id and retrieve the submission details.​

The only available text field we can use is the Title field. To make it work, we’ll use dynamic content from the Get response details action, specifically the First Name, Last Name of the submitter. This information will be combined in the Title field so the agent in Planner will easily identify who to follow up with.

Action (Update task details)

After creating the task, we need to update its details to include relevant information from the submitter, such as their email address. Additionally, we will add a checklist to help the agent track the necessary steps for completing the task efficiently.

Using the dynamic content from the previous action, we will set the Task Id, update the Description field with the necessary data (such as the submitter’s email), and create a checklist item to ensure the agent follows up by emailing the prospect.

End to end test