The Workbench

Building Power Automate Flows with Claude Code and FlowAgent

2026-08-13T07:00:00.000-04:00

For the past week, my team and I have been heads-down building a Business Central to Dynamics 365 CE billing integration: posted sales invoices, applied cash receipts, subscription cancellations, and the product registry automation that ties them all together. Every one of those integrations is a Power Automate cloud flow, and every one of them was developed, debugged, and verified with Claude Code driving Power Automate directly, through a tool called FlowAgent. Suffice to say, this changed how I think about building flows, so I figured I would write up what we learned while it is still fresh.

Now, keep in mind this is not a review written after a demo. This is written after shipping three production-bound flows through dozens of iterations, a full test campaign, and a healthy number of defects found and fixed along the way. The scars are real!

What FlowAgent is

FlowAgent is an MCP server that ships inside the power-automate plugin from the good folks at Microsoft, published in the open source power-platform-skills repository. MCP, the Model Context Protocol, is the standard that lets an AI coding assistant call real tools instead of just talking about them. Once the plugin is installed, Claude Code gains a set of Power Automate operations it can invoke on its own:

List environments and flows, and set a working environment and current flow
Read a flow's full definition -- this is, the JSON under the designer
Edit, validate, and publish flows
Read run history, run details, and per-action inputs and outputs from any run
Inspect connections, connectors, and operation schemas
Search connector operations and get expression help

The plugin also bundles a Microsoft Learn MCP server, so the assistant can pull official documentation while it works, plus a set of skills -- guided workflows -- for creating, debugging, and diagnosing flows.

You may be asking, "why does this matter when the assistant can already tell me what to build?" Very simple: without FlowAgent, the AI describes a flow and you go click it together in the designer. With FlowAgent, the assistant reads the actual flow, makes the actual edit, publishes it, watches the actual run, and reads the actual error. The feedback loop that used to run through your eyes and your mouse now runs at tool speed.

Setting it up

The prerequisites are modest: Claude Code, Node.js, the Azure CLI logged into your tenant -- FlowAgent uses it for authentication -- and ideally the Power Platform CLI (pac) for solution work. Installation is two commands from within Claude Code:

claude plugin marketplace add microsoft/power-platform-skills
claude plugin install power-automate@power-platform-skills

A few things to note before moving on. The first command registers Microsoft's repository as a plugin marketplace; the second installs the power-automate plugin from it. After both commands complete, restart your Claude Code session, because plugins attach at session start. Then run the plugin's setup skill once: it verifies Node, the Azure CLI login, and the Power Automate token, and lets you pin a working environment so every later operation lands where you expect.

Two lessons from our own installation that may save you an afternoon:

NOTE: check which Claude Code binary you are actually running. We had an old standalone CLI on the PATH that predated the plugin system entirely, and it silently swallowed the plugin subcommands as if they were prompts. The VS Code extension ships a current CLI in its resources\native-binary folder; that one worked immediately.

NOTE: do not hand-edit the plugin registration files. Our first attempt at manual registration produced a "marketplace configuration corrupted" state that even blocked removal. Resetting the marketplace file and using the real CLI commands fixed it in minutes.

Debugging: the single biggest win

When a flow fails, the assistant pulls the run, walks the failed action, reads its exact inputs and outputs, and correlates all of it with the flow definition in one pass. Early in the project, this alone paid for the whole setup. As it turns out, our invoice flow had been silently broken for about two weeks, because the web services it called no longer existed, and the failure was masked by trigger noise. Two weeks! Nobody noticed, and frankly, nobody was going to: reading run histories systematically across hundreds of runs is exactly the kind of work a human never quite gets around to. Claude Code found it, remapped both HTTP calls to the replacement services, and verified the fix against a live run.

The same loop caught subtler things. A negative credit line on an invoice was failing because the CRM connector rejects negative discount amounts. The failed runs told the whole story: header created, positive line created, credit line refused. Reading the actual action outputs turned a vague "totals are off in CRM" report into a precise defect, a designed fix, and a verified repair, all inside one working session.

Edits go where edits belong

Our standing rule became: the cloud flow is the working copy, and the local solution source is the versioned mirror. Small, surgical changes go through FlowAgent's edit and publish tools. After every applied change, pac solution sync pulls the new definition into a git repository and the change gets a changelog entry. The assistant does all of this in one motion, so the discipline actually holds. Every flow change in this project, and there have been many dozens, is in version control with a written rationale.

For large edits, there is a practical workaround worth knowing: tool payloads truncate somewhere around 5 KB, so a big definition rewrite goes through the solution route instead. Edit the definition JSON locally, then pac solution pack, pac solution import, and publish. Same destination, different door. The assistant learned to choose the route based on the size of the change.

Verification stopped being optional

Because the assistant can resubmit a stored run and then read the new run's results, "deploy and hope" turned into "deploy and prove." Our habit became: make the change, resubmit a known trigger event, read every action's output, compare the CRM records against Business Central truth, and only then call it done.

During the test campaign, this cadence caught a deployment race where a managed export picked up a stale version and the target environment silently skipped the import as already installed. In turn, a resubmit against what turned out to be the old definition briefly looked like a test result. The lesson is now procedure: after every deployment, read the definition back from the target before trusting any run.

The rough edges, honestly

FlowAgent is genuinely useful and genuinely version one. Things we hit, and how we worked around them:

Solution-aware flows do not appear in the flow list, which only shows personal-scope flows. The workaround is to address your flow by its ID directly. Once pinned as the current flow, everything else works.
The resubmit and diagnose tools had bugs in the version we used; both threw type errors. We resubmitted runs through the underlying Power Automate REST API instead, which the assistant handles just fine, and filed the issues upstream with the plugin's built-in report-issue skill.
Importing a solution leaves flows stopped, and validation errors surface at activation time, not import time. Publishing or activating after import is a required step, not a nicety.
Connection authorization is per connection, not per flow. A brand new flow referencing a shared connection needs one activation by the connection's owner; after that, other makers can deactivate, edit, and reactivate freely. Knowing this pattern saved us from repeatedly misdiagnosing authorization failures.

None of these were blockers. All of them are the kind of thing you want written down before you start, which is exactly why they are written down here.

What it added up to

In a bit under a week of working sessions, this setup carried us through:

Remediation of six pre-existing defects in an inherited flow, including moving a plaintext secret into Azure Key Vault and parameterizing every environment-specific value into environment variables
A ground-up rebuild of the invoice flow onto a customer ledger trigger, eliminating an entire class of draft-noise and race-condition bugs
A cash receipts flow built from a feasibility stub to feature complete in a single day, across four live-verified iterations
A registry automation flow that replaced two hardcoded legacy flows with one table-driven design
A full staging test campaign in which every planned scenario across three flows fired live, with every defect found along the way fixed and re-verified

Could a person do all of that in the portal designer? Eventually. But the honest answer is that the verification depth is what a person would not do. Reading every action output of every test run, reconciling every synced record against the source system to the penny, and writing it all down as you go is precisely the tedious, high-value work that an agent with real tool access does without fatigue.

If you try it

Three practices made the difference for us, and none of them are about the tool itself:

Keep a changelog and a git mirror from day one. The agent moves fast; the paper trail is what lets you trust the speed.
Decide your edit routing up front. Cloud as working copy, local as mirror, one commit per applied change. Ambiguity here is how definitions drift.
Insist on live verification. The agent can prove its work against real runs. Make it do so every time, and "it should work" disappears from your vocabulary.

One last thing, because it matters: FlowAgent will not design your integration for you, and it should not. The design conversations, the business rulings, and the judgment calls stayed firmly human in our project. What it collapses is the distance between a decision and a verified, versioned, running flow -- a distance that used to be measured in hours of clicking and is now measured in minutes of reading the agent's evidence.

If you take FlowAgent for a spin, please drop a note in the comments describing your experience, including the rough edges you find; that feedback is exactly what makes open source tooling like this get better.

Until next post!

MG.-
Mariano Gomez Bent
Former Microsoft BizApps MVP

Same Agent, Two Architectures: When MCP Wins (and When It Doesn't)

2026-08-11T09:35:27.912-04:00

I know, I know. It has been almost five years since my last post, and in that time the masthead changed, the name changed, and frankly, the entire technology landscape changed with them. But I did not want to relaunch this blog with a ceremonial hello-world post, so instead, this first post from The Workbench starts out the way many of my posts have over the years: with a question.

The question comes up in just about every architecture review I sit in these days, whether in my day job as CTO or in conversations with folks in the community, and it goes something like this:

"Should we be using MCP for our Copilot Studio agents?"

I will be the first to tell you this is the wrong question. And rather than argue the point in the abstract, I built the same agent twice to prove it. Let's see how it's done!

Background

Model Context Protocol -- MCP for short, introduced by the folks at Anthropic -- has gone from curiosity to checklist item in record time, much like microservices did a few years back, and just like then, everyone wants to know where it fits before anyone has agreed on when it should. So, I put together a lab around a fictional but very realistic engineering program called Project Orion: a customer-facing web application mid-way through a major release cycle, with its operational truth split across two systems, the way it always is in real life:

GitHub Issues holds the code-level activity: 35 issues covering bugs, feature work, blockers, and performance problems.
A SQL Server database holds the delivery truth: five sprints of history, 70 work items, and 30 days of health metrics, including a release readiness score, critical bug counts, blocker counts, and velocity trend.

Now, the seeded data tells a story on purpose. Sprint 3 completed 38 of 45 points. Sprint 4 dropped to 33 of 44 with 11 points of rollover. The latest health snapshot shows a release readiness score of 52, three critical bugs, three blockers, and a velocity trend of Declining. Suffice to say, this project is quietly going sideways, and the signals are scattered across two systems that do not talk to each other.

With the stage set, I built the same agent twice in Microsoft Copilot Studio and asked both versions the same questions.

Version 1: the connector agent

The first agent uses nothing but the GitHub connector. Ten minutes of work, most of which is authentication, and here is the part that surprises people every time I demo it: this agent is good.

Ask it "What critical bugs are open in Project Orion?" and it answers cleanly, with issue numbers, titles, and labels. Ask it "What issues are labeled as blocked?" and it nails that one too. For questions whose answer lives entirely inside GitHub, the connector agent is fast, correct, and required exactly zero infrastructure from me -- no server to provision, nothing to patch, and it sits comfortably inside the tenant's existing governance and data loss prevention story, which your IT department will certainly appreciate.

Now, that's all cool, but then you ask it the ONE question your VP actually cares about: "What is blocking the Project Orion release?"

And there it is -- the ceiling! The agent can see three critical bugs in GitHub, so it reports three critical bugs. It cannot see that the release readiness score sits at 52 and falling, it cannot see that velocity has declined two sprints in a row, and it cannot see that two of the blocked work items have been stalled for over a week. Keep in mind, its answer is not wrong. It is something worse than wrong: it is confidently incomplete. A stakeholder reading that answer would walk away thinking the release has three bugs to fix, when the data says the release is structurally at risk.

In the lab version of this agent I made the limitation explicit, and I recommend you do the same for any single-source agent you ship. Its instructions include the following line:

"I can only see GitHub Issues data. For full project health including sprint metrics and release readiness, you would need access to the project health database."

An agent that states its blind spots is an agent you can trust. An agent that answers everything with whatever fraction of the truth it can reach is a liability wearing a chat interface. It just doesn't work!

Version 2: the MCP agent

The second agent is the same Copilot Studio agent rebuilt on two MCP servers: the GitHub MCP Server for issue data, and a custom TypeScript MCP server I wrote that fronts the Project Orion SQL database.

The custom server exposes seven tools, and I would encourage you to study the tool list closely, because this is where the real design work lives. These are not generic "run a query" endpoints; each one answers a question a human being would actually ask:

get_current_sprint: the active sprint with planned versus completed points
get_sprint_history: velocity and completion history across completed sprints
get_critical_work_items: open Critical and High priority items, including blocked ones
get_work_items_by_sprint: work items for a sprint, optionally filtered by status
get_latest_health_metrics: the current health snapshot, readiness score included
get_health_metrics_trend: readiness score over the last N days
get_stalled_work_items: items sitting in Active or New with no movement

Two implementation details will save you a considerable amount of head scratching, so pay close attention. First, as it turns out, Copilot Studio speaks HTTP, not stdio. Most MCP tutorials out there show the stdio transport, because that is what desktop clients use, but Copilot Studio requires the streamable HTTP transport running in stateless mode, with a fresh transport and server instance created for each incoming request. For brevity sake, I am only showing the shape of it:

// Copilot Studio requires HTTP transport in stateless mode
const transport = new StreamableHTTPServerTransport({
  sessionIdGenerator: undefined, // stateless: critical for Copilot Studio
});
// a fresh server + transport pair is created per incoming request
app.post('/mcp', async (req, res) => {
  const server = buildProjectOrionServer();
  await server.connect(transport);
  await transport.handleRequest(req, res, req.body);
});

Second, validate your tool inputs. The model -- not you, not your code -- is choosing the parameter values at runtime, so every tool takes a schema, not a prayer:

server.tool(
  'get_health_metrics_trend',
  'Returns the release readiness score trend over the last N days ' +
  'to show whether project health is improving or declining.',
  { days: z.number().optional().default(14) },
  async ({ days }) => {
    const rows = await getHealthMetricsTrend(days);
    return { content: [{ type: 'text', text: JSON.stringify(rows) }] };
  }
);

A few things to note before moving on. That tool description string is not documentation for humans; it is the interface the model reasons over when deciding which tools to call and in what combination. Write your tool descriptions the way you would write requirements for a sharp new team member, because for all practical purposes, that is exactly what they are.

The moment it earns its keep

Now ask the rebuilt agent the same question: "What is blocking the Project Orion release?"

This time the agent calls get_critical_work_items and get_latest_health_metrics on the SQL side, pulls the open critical issues from the GitHub side, and then does the thing no single-source agent can do: it correlates. The three critical GitHub bugs map to blocked work items in the sprint; the blockers explain the 11 points of rollover in Sprint 4; the rollover explains the declining velocity trend; and all of it together explains a readiness score of 52. And voila! The answer reads like something a good release manager would write, complete with a one-line risk summary at the end, because the agent finally has the same field of vision the release manager has.

Ask it "Are there any patterns between our open GitHub issues and our sprint health?" and it produces an answer that did not have a data path to exist in Version 1. That is the difference, and it is worth being precise about it: not better answers to the old questions, but answers to questions that were previously UNANSWERABLE.

What MCP costs you

Here is the part the hype conveniently skips, and the part I lean on hardest whenever I present this material: everything above has a bill attached.

With the connector agent, Microsoft runs the integration. With the MCP agent, I run the integration. In the lab, the server is a TypeScript process on my laptop reached through an Azure Dev Tunnel, which is perfectly fine for a demo and perfectly irresponsible for production.

NOTE: the moment this architecture goes to production, you own hosting, authentication, TLS, availability, logging, patching the SDK, and the security review for a brand-new surface area that reaches directly into a database. The connector came pre-governed; your MCP server is governed by whatever you remembered to build.

So the honest comparison is not "MCP versus connector." It is "cross-source reasoning versus operational simplicity." Sometimes that trade is spectacular, and sometimes it amounts to buying yourself a server bill to answer questions a connector already answered. It is your job as an architect to know which of the two situations you are standing in.

The decision signal

After building both versions side by side, the rule I trust fits in one sentence:

When your agent needs to reason across sources it did not know about at design time, that is your MCP signal.

In practice, I walk through the following four questions:

Does the answer live in one system? Use the connector. You are done, and you inherited Microsoft's operations team for free.
Does the answer require correlating two or more systems in a single reasoning pass? That is your MCP signal. No amount of prompt engineering will give a single-source agent data it cannot reach.
Will the source list grow? MCP servers compose. Adding a third source to the Orion agent is another server registration, not a rebuild.
Can you operate a service? If the answer is no, that is not a character flaw, but keep in mind the connector ceiling is your ceiling until that answer changes.

Build it yourself

Everything in this post is reproducible from the lab I published for my Community Summit NA 2026 session in Nashville, "Same Agent, Two Architectures: When MCP Wins (And When It Doesn't)". The repository contains the SQL schema and seed data, a script that creates all 35 GitHub issues, scaffold prompts for the MCP server and a Next.js health dashboard, and the Copilot Studio prompts for both agents -- including the intentionally limited one:

github.com/dgpblogster/project-orion-lab

You need VS Code, Node 18+, SQL Server Express, the GitHub CLI, Azure Dev Tunnels, and a Copilot Studio license -- a trial works just fine. Budget an afternoon, and make sure you build toward the moment where you ask both agents the release-blocker question back to back, because watching one agent hit the ceiling and the other reason straight through it will teach you more about agent architecture than any slide deck, including mine. The effort is well worth it!

If there is interest, my next installment will walk through hardening this MCP server for real production use -- authentication, hosting, and telemetry -- so please drop a note in the comments if you would like to see that. It is good to be back at the bench.

Until next post!

MG.-
Mariano Gomez Bent
Former Microsoft BizApps MVP

Power Apps - Application Monitoring with Azure Application Insights

2021-08-12T15:09:00.002-04:00

In this video, learn to enable Power Apps Application Monitoring with Azure Application Insights.

The following topics are covered in this video:

(0:00) - Intro

(0:36) - What is Azure Application Insights

(1:32) - The timesheet app

(2:12) - Creating an Application Insight for the timesheet application

(3:55) - Identify and copy the application instrumentation key

(4:09) - Enabling the timesheet application with the instrumentation key

(5:32) - Working with Application Insights

(8:06) - Outro

For additional information on Azure Application Insights, please follow these resources:

Microsoft Docs - What is Azure Application Insights? here

Adam Marczak - Azure for Everyone: Azure Application Insights Tutorial, here

To check out my YouTube channel visit: https://youtube.com/user/mgomezb1

LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

Power Platform ALM - Visual Studio Code Extensions

2021-08-03T15:46:00.000-04:00

Learn about Power Platform extension for Visual Studio Code and how this toolset is improving both the code first developer experience and strengthening the ALM story.

The following topics are covered:

(0:00) - Intro
(1:16) - Installing the Power Platform extensions for Visual Studio Code
(2:13) - Working with the Power Platform CLI inside of Visual Studio Code
(3:42) - Authenticating to your environment from Power Platform CLI
(7:18) - Saving your canvas app to your local machine
(8:55) - Unpacking your canvas app
(10:19) - Using Visual Studio Code to make changes to your application
(11:50) - Packing and uploading your application changes
(13:55) - Outro

To check out my YouTube channel visit: https://youtube.com/user/mgomezb1

LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

Power Automate | Passing Collections from Power Automate to Power Apps (Revisited)

2021-08-02T17:31:00.004-04:00

I revisit an old video I did couple years ago showing how to pass collections from Power Automate to Power Apps.

This time around, I show how to leverage arrays to accomplish the same. This time around you will learn about:

To check out my YouTube channel visit: https://youtube.com/user/mgomezb1

LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

AI Builder Form Processing: Multi-layout Form Processing

2020-11-10T14:00:00.003-05:00

AI Builder Form Processing Multi-layout Form Processing has been one of the most requested features and is now available in preview for you to test. This feature allows you to process forms with a variety of different layouts (but similar in content) with a single model, which brings this feature one step closer to a scalable enterprise solution.

In this video I cover the following:

- Creating a model
- Form collections
- Training the form processing model
- Publishing the form processing model
- Testing the model

For additional information, please refer to:

Create a form processing model - click here
AI Builder form processing announcement - click here

To check out my YouTube channel visit: https://youtube.com/user/mgomezb1

LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

Power Platform: Application Lifecycle Management (Part 3/3) - Build and Release Pipelines

2020-10-20T16:15:00.000-04:00

Welcome to the final episode of Power Platform Application Lifecycle Management. In parts 1 and 2 you saw how to prepare your environments, set up an Azure DevOps project, and define Service Connections to your Power Platform environments.

In this, the final installment of this 3-part series, you will learn how to create the Build and Release pipelines using the Power Platform Build Tools to take your Power Platform solution from an environment, through source code control, through staging and production deployments.

Topics covered:

- Power Platform source code control with Azure Repos
- Build and Release pipelines
- Sharing your solution

References:

Power Platform Build Tools webinar - https://youtu.be/Qwue8fwetJA

Solutions Overview and Limitations - click here

To check out my YouTube channel visit: https://youtube.com/user/mgomezb1

LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

Power Platform: Application Lifecycle Management (Part 2/3) - Solutions and DevOps

2020-09-22T17:00:00.001-04:00

In the previous installment, you saw how to work through a set of prerequisites to get you going in your Power Platform Application Lifecycle Management journey. In this video, I will work through building an app and adding it to a solution and show you some additional Azure DevOps configuration options to link your repository to your Power Platform development environment.

Topics Covered:

1. Building app based on template
2. Adding your app to a solution
3. Linking your DevOps project to your Power Platform environment

References:
Power Platform Build Tools webinar - https://youtu.be/Qwue8fwetJA

Solutions Overview and Limitations - click here

To check out my YouTube channel visit: https://youtube.com/user/mgomezb1

LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

Power Platform: Application Lifecycle Management (Part 1/3) - Prerequisites

2020-09-14T15:42:00.000-04:00

This series is in response to multiple requests by my viewers to address the topic of Power Apps Application Lifecycle Management (ALM). This series is intended to breakdown the entire process in as much detail as possible, without lengthy explanations on how to get it done or, as often happens, little to no explanations on how you arrived at a particular step or result.

My first installment will focus on Prerequisites, this is, what you need to have in place to get started. I will walk you through provisioning your Power Platform Dev, QA, and Production environments, along with installing the Power Platform Build Tools and setting up your Azure DevOps project. I also explain the concept of solutions in Power Platform and why they are important to your ALM strategy.

Topics covered:

1. Creating Power Platform Environments
2. Azure DevOps and Installing Power Platform Build Tools
3. Creating an Azure DevOps Project
4. Solutions

References:
Power Platform Build Tools webinar - https://youtu.be/Qwue8fwetJA

Credits:
Summer - Bensound - Royalty free music at https://www.bensound.com

To check out my YouTube channel visit: https://youtube.com/user/mgomezb1

LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

Power Automate: Transfer records from SharePoint list to Azure SQL database

2020-09-03T11:29:00.001-04:00

Majority of times, when we are working with various data sources, we want information to go from one source to another, conditioned to the occurrence of an event. Today, I will show you how to transfer records from a SharePoint list to Azure SQL database tables in response to a timesheet approval event. In the process, you will learn how I leveraged the existing Power Apps Expense template app and converted it into a Timesheet app for the purpose of recording time for various activities

Power Apps: Save Mixed Reality pictures to SharePoint

2020-08-10T14:57:00.000-04:00

In this video you will learn how to save pictures taken in Power Apps Mixed Reality or Augmented Reality viewer to a SharePoint document library.

Some topics covered include: Power Apps ForAll(), With(), Mid(), and Len() functions, the Self operator. Learn to use the Power Automate SharePoint connector and the Create File action, and the base64toBinary() function in an expression. Finally, you will see how you can call a flow from Power Apps to make it all work like a single application.

To check out my YouTube channel visit: https://youtube.com/user/mgomezb1

LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

Power Automate: Working with Microsoft Graph API and Teams Connector

2020-07-28T21:33:00.003-04:00

In this video you will learn the basics of the Microsoft Graph API, how to use Graph Explorer, register an application to use Microsoft Graph in Azure Active Directory, and build a simple flow that will use the Teams Connector and Graph API to list a set of tabs in a Teams channel.

Other topics covered are: compose and HTTP actions, using the compose action as an alternative to variables, using the filter array action to filter the results in a JSON payload.

References:
Microsoft Graph: https://graph.microsoft.com

Credits:

Creative Minds - Bensound - Royalty free music at https://www.bensound.com

To check out my YouTube channel visit: https://youtube.com/user/mgomezb1

LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

Power Automate: Calculate Soundex of a word with a flow

2020-07-07T09:25:00.001-04:00

In this video, I will be showing you how to use Power Automate to calculate the Soundex value of a word using a flow. This calculation uses the American standard algorithm, but can be adapted to support other algorithms developed for the English language.

In building the workflow you will learn how to use the Scope, Compose, and Append To String actions, the Do Until and If Then control structures, along with the substring(), replace(), add(), and mult() functions. Please leave your comments below.

References:
Wikipedia Soundex entry - https://en.wikipedia.org/wiki/Soundex

Downloads:
Power Automate Cookbook: Click here

To check out my YouTube channel visit: https://youtube.com/user/mgomezb1

LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

Power Automate: Building a REST endpoint with the HTTP Request connector

2020-06-19T18:41:00.000-04:00

In this video I show you how to build a REST endpoint with the Power Automate HTTP Request connector to be used as a web service to transfer data to a on-premises SQL database. In the process, I will be using Postman API development platform to test the endpoint and submit data to a Microsoft Dynamics GP company database via its eConnect API stored procedures.

To check out my YouTube channel visit: https://youtube.com/user/mgomezb1

LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

Power Apps: Calculating various dates with date functions

2020-06-10T16:58:00.000-04:00

In this article, I will show you how to leverage the DateDiff(), DateAdd(), Weekday(), DateValue(), and Day(), and Today() functions to calculate all sort of dates that are typical to business applications: first and last day of previous month, first and last day of previous quarter, first and last day of previous week, first and last day of current month, first and last day of current quarter, first and last day of current week, first and last day of next month, first and last day of next quarter, first and last day of next week, etc.

Let's begin:

Each calculation is self-contained for convenience sake, which means the only dependency is on the cdt context variable.

Current Date

UpdateContext({cdt:Today()});

Note: you could also use the Now() function, but be aware that this function also includes the timestamp.

First Day of Previous Month

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            mts: DateDiff(
                rootdate,
                cdt,
                Months
            ) - 1
        },
        DateAdd(
            rootdate,
            mts,
            Months
        )
    )
)

Last Day of Previous Month

DateAdd(cdt, -Day(cdt), Days)

First Day of Current Month

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            mts: DateDiff(
                rootdate,
                cdt,
                Months
            )
        },
        DateAdd(
            rootdate,
            mts,
            Months
        )
    )
)

Last Day of Current Month

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            mts: DateDiff(
                rootdate,
                cdt,
                Months
            ) + 1
        },
        With(
            {
                FirstNxtMonth: DateAdd(
                    rootdate,
                    mts,
                    Months
                )
            },
            DateAdd(
                FirstNxtMonth,
                -1,
                Days
            )
        )
    )
)

First Day of Next Month

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            mts: DateDiff(
                rootdate,
                cdt,
                Months
            ) + 1
        },
        DateAdd(
            rootdate,
            mts,
            Months
        )
    )
)

Last Day of Next Month

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            mts: DateDiff(
                rootdate,
                cdt,
                Months
            ) + 2
        },
        With(
            {
                FirstNxtMonth: DateAdd(
                    rootdate,
                    mts,
                    Months
                )
            },
            DateAdd(
                FirstNxtMonth,
                -1,
                Days
            )
        )
    )
)

First Day of Previous Quarter

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            qtrs: DateDiff(
                rootdate,
                cdt,
                Quarters
            )
        },
        DateAdd(
            rootdate,
            qtrs - 1,
            Quarters
        )
    )
)

Last Day of Previous Quarter

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            qrtr: DateDiff(
                rootdate,
                cdt,
                Quarters
            )
        },
        With(
            {
                NxtQrtr: DateAdd(
                    rootdate,
                    qrtr,
                    Quarters
                )
            },
            DateAdd(
                NxtQrtr,
                -1,
                Days
            )
        )
    )
)

First Day of Current Quarter

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            qtrs: DateDiff(
                rootdate,
                cdt,
                Quarters
            )
        },
        DateAdd(
            rootdate,
            qtrs,
            Quarters
        )
    )
)

Last Day of Current Quarter

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            qrtr: DateDiff(
                rootdate,
                cdt,
                Quarters
            ) + 1
        },
        With(
            {
                NxtQrtr: DateAdd(
                    rootdate,
                    qrtr,
                    Quarters
                )
            },
            DateAdd(
                NxtQrtr,
                -1,
                Days
            )
        )
    )
)

First Day of Next Quarter

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            qrtr: DateDiff(
                rootdate,
                cdt,
                Quarters
            ) + 1
        },
        With(
            {
                NxtQrtr: DateAdd(
                    rootdate,
                    qrtr,
                    Quarters
                )
            },
            DateAdd(
                NxtQrtr,
                0,
                Days
            )
        )
    )
)

Last Day of Next Quarter

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            qrtr: DateDiff(
                rootdate,
                cdt,
                Quarters
            ) + 2
        },
        With(
            {
                NxtQrtr: DateAdd(
                    rootdate,
                    qrtr,
                    Quarters
                )
            },
            DateAdd(
                NxtQrtr,
                -1,
                Days
            )
        )
    )
)

First Day of Previous Week

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            diffval: DateDiff(
                rootdate,
                cdt,
                Days
            ),
            Offset: 1 - Weekday(cdt)
        },
        DateAdd(
            cdt,
            Offset - 7,
            Days
        )
    )
)

Last Day of Previous Week

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            diffval: DateDiff(
                rootdate,
                cdt,
                Days
            ),
            Offset: 1 - Weekday(cdt)
        },
        DateAdd(
            cdt,
            Offset - 1,
            Days
        )
    )
)

First Day of Current Week

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            diffval: DateDiff(
                rootdate,
                cdt,
                Days
            ),
            Offset: 1 - Weekday(cdt)
        },
        DateAdd(
            cdt,
            Offset,
            Days
        )
    )
)

Last Day of Current Week

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            diffval: DateDiff(
                rootdate,
                cdt,
                Days
            ),
            Offset: 1 - Weekday(cdt)
        },
        DateAdd(
            cdt,
            Offset + 6,
            Days
        )
    )
)

First Day of Next Week

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            diffval: DateDiff(
                rootdate,
                cdt,
                Days
            ),
            Offset: 1 - Weekday(cdt)
        },
        DateAdd(
            cdt,
            Offset + 7,
            Days
        )
    )
)

Last Day of Next Week

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            diffval: DateDiff(
                rootdate,
                cdt,
                Days
            ),
            Offset: 1 - Weekday(cdt)
        },
        DateAdd(
            cdt,
            Offset + 13,
            Days
        )
    )
)

You can download the application on the Power Apps Community apps gallery

To check out my YouTube channel visit: https://youtube.com/user/mgomezb1
LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

Power Apps: Mixed Reality spatial controls

2020-06-08T12:35:00.000-04:00

For the final installment of the Power Apps Mixed Reality series, I'm going to show you how to use the MR spatial controls, Shape in MR and Measure in MR. You will get to understand a bit more about the available properties for these controls and how they interact with collections and galleries to produce an app.

To check out my YouTube channel visit: https://youtube.com/user/mgomezb1

LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

Power Apps - Mixed Reality 3D Viewer and MR Viewer controls

2020-05-28T23:43:00.003-04:00

In this video, I show you how Power Apps Mixed Reality works from the ground up. We will build a simple app that leverages the 3D Viewer and MR Viewer controls to display a 3D model of Star Trek's USS Endeavour. Somewhere, I also introduce the use of the Power Apps Self operator and show you how you can capture images from your Augmented Reality (AR) experience and store them in a collection

To check out my YouTube channel visit: https://youtube.com/user/mgomezb1

LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

Fun and Non-Traditional uses for Power BI, Power Apps and Power Automate

2020-05-28T23:37:00.000-04:00

In this video, I teamed up with fellow Microsoft MVPs, Belinda Allen and Daniel Christian, to show some non-traditional use cases for Power Platform. You will see examples on motion and creating motion patterns for things like the Solar System in Power Apps, cool data analysis of everything from the lottery numbers to UFO sightings to fact checking politicians in Power BI, and a showcase of Star Trek's Starfleet with using mixed reality, along with some Galaga game concepts, all in Power Apps.

Recorded at the Virtual Power Platform World Tour held on May 14, 2020.

To check out my YouTube channel visit: https://youtube.com/user/mgomezb1

LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

#Hack4GoodMBAS 2020 Global Hackaton

2020-05-06T16:59:00.000-04:00

This past weekend, I was privileged to participate on the 24-hour Hack4Good MBAS 2020 global hackathon, carried out prior to the Microsoft Business Applications Summit 2020.

The theme for this hackathon revolved around COVID-19 and challenged all participating teams to create innovative solutions leveraging the entire Microsoft stack to solve a single problem. The hackathon involved teams from across all continents.

From left to right and top to bottom, me, Vivek Bavishi, Jon Levesque, April Dunnam, Geetha Sivasailam, and Joe Unwin, collectively Team FlowFam.

Our use of Microsoft Power Platform, Mixed/Augmented Reality, and advanced search and location services and data storage allows this solution to be used in several settings, but we decided to build a tool that could potentially help government and city planning officials, along with military engineers to quickly locate facilities and public spaces, measure and create floor plans, quickly calculate and plan bed space requirements, and place a request for beds to fill the space.

This 5 minutes video summarizes our 24 hour effort - more to come!

Here's the announcement by the judges evaluating the #Hack4GoodMBAS hackathon solutions. Our solution, SpaceR, was selected with one other among 11 teams participating across the Americas and has been entered into a pool of world finalists (APAC, EMEA, AMER) where it will be evaluated by a team of Microsoft judges.

Winner will be announced at the next Microsoft Business Applications Summit which you can register and attend for free.

⚠️ From the archive: the video that originally appeared here is no longer publicly available. It may still be viewable directly on YouTube.

To check out my YouTube channel visit: https://youtube.com/user/mgomezb1

LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

Power Platform Share with Steve, Mariano, and Belinda (Episode 7)

2020-05-01T11:17:00.001-04:00

I caught up with fellow MVP’s Steve Endow and Belinda Allen again for our Power Platform Share and have invited a special guest, fellow MVP Reza Dorrani to present some of the latest Power Platform features and stuff he's been working on. Suffice to say Reza blew us away with his COVID-19 tracker while showing some of the new mapping and geospatial capabilities available with Power Apps.

To check out my YouTube channel visit: https://youtube.com/user/mgomezb1

LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

Working Remotely with Microsoft Dynamics GP

2020-05-01T10:59:00.000-04:00

I had a chance to sit down with fellow MVPs Belinda Allen and Shawn Dorward, GPUG All*Star Amber Bell, and Zubin Gidwani from Dynamic Budgets to talk about "Work from Home" strategies with Dynamics GP amidst the Coronavirus stay at home orders

Each one of us was tasked with presenting a rapid fire session outlining an approach to work remotely with Microsoft Dynamics GP.

To check out my YouTube channel visit: https://youtube.com/user/mgomezb1

LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

Power Apps - Introduction to Mixed Reality

2020-04-17T09:03:00.003-04:00

This is the first video in a 2-part series that explains some of the basic concepts behind Mixed Reality. Learn what is a model, how you can compose a model file, pack it for consumption by Power Apps and having fun while doing it all.

Disclaimer:

I am no mixed reality expert. This is just my personal experience trying to understand the elements and concepts behind it for the everyday citizen developer. I don't talk about Azure Mixed Reality or anything the Azure platform has to offer to developers. This is a simple "here's how you compose and pack a model for use with Power Apps Mixed Reality" video.

References:

GLTF to GLB Packer - click here
Microsoft 3D Viewer - click here
Microsoft Paint 3D support documentation - click here

To check out my YouTube channel visit: https://youtube.com/user/mgomezb1

LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

Power Virtual Agents - Create a Chat Bot for your on-premises ERP

2020-03-23T14:44:00.001-04:00

This video shows how you can combine the power of Microsoft Power Virtual Agents chat bots and Power Automate flows with your on-premises data to provide an all around navigation-free user experience.

While this video features Microsoft Dynamics GP as the on-premises ERP, technically speaking, you could create a chat bot for just about any ERP system in the market, whether on-premises or in the cloud. In fact, why stop at ERPs?

Reference:

Power Virtual Agents page - click here
Use Power Virtual Agents Connector to build Power Automate flows for your bot - click here

To check out my YouTube channel visit: https://youtube.com/user/mgomezb1

LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

Power Apps - Using Azure Text Analytics to monitor Coronavirus COVID-19 updates

2020-03-14T15:10:00.003-04:00

In this video I describe a Disease Monitor App I created as part of the #TemplatesForHumanity effort championed by Keith Wathling (Twitter: @KeithWathling) a couple years ago and that I have completely rehauled to support Coronavirus with an updated interface and approach to retrieve sentiment analysis with Azure Text Analytics.

You will learn about:

Using Text Analytics API in Power Apps (click here)
Power Apps Collections (click here)
Power Apps UpdateIf() function (click here)

References:

Download this app from my GitHub repo here.
#TemplatesForHumanity on Twitter here.

To check out my YouTube channel visit: https://youtube.com/user/mgomezb1

LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

Using Power Apps & Power Automate with On-Premises Data

2020-03-05T20:04:00.000-05:00

Hello everyone!

I sit down with Samuel Adranyi (@sadranyi) from Ghana, on his Power Series show, to demystify the user of Microsoft Power Apps and Power Automate with on-premises data. We cover the On-premises Data Gateway, its architecture, hybrid connectors, and provide a couple samples on accessing on-premises ERP data with both Power Apps and Power Automate.

References:

What is the On-premises Data Gateway? - click here
Install an on-premises data gateway - click here

To check out my YouTube channel visit: https://youtube.com/user/mgomezb1

LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP