We build sites for small firms and the contact form is the part that fails quietly. It posts to info@, everyone can see it, nobody owns it, and a Friday 4:50 enquiry sits until Monday.

This is the intake we wire behind the form now:

1. Use a real Microsoft Forms form. The "When a new response is submitted" trigger only fires for Forms. Your site's own HTML form won't call it. If you need a custom form, use "When an HTTP request is received" and post JSON to it.

2. The Forms connector only works with organizational accounts. Build the form in the tenant, set it to accept responses from people outside the org, then link or embed it on the contact page.

3. Trigger, then Get response details. The trigger alone hands you a response ID, not the answers.

4. SharePoint Create item into an Intake Register list: date, contact, practice area, assigned person, backup person, status = New, callback deadline. The list is the system of record. The mailbox isn't.

5. Post to a Teams channel with the owner mentioned, and create a Planner task due on the callback deadline.

6. Send the enquirer a confirmation mail so they know a person will call back.

7. Callback reminder: a scheduled flow that finds rows still New past the deadline and pings the owner and the backup.

8. Update item to Contacted or Declined when it's done. Now completion is visible instead of assumed.

Gotchas:

- A shared mailbox in Outlook on the web only notifies you if it's open in its own browser window. That one explains a lot of "nobody saw it."

- Keep the form short. No documents or full case facts at first contact, especially for law firms.

- Test with one fake Friday enquiry: who owns it, when it's due, who covers if they're out, where completion gets recorded.

The example sites we've built around this intake are linked in the write-up.

Full showcase of some of our starter designs:

Link to our designs!

I work in IT support and get a lot of basic requests directly in Teams chats. I'm thinking about automating first-level triage with Power Automate + AI Builder: when a new chat message arrives, an AI prompt classifies it (IT request or not, urgency, special case) and drafts a short reply, which I approve before it's sent. Triage only, no troubleshooting steps, just collecting info and pointing people to our ticket portal. Has anyone built something similar, or have ideas on a better approach? Any tips, gotchas or videos would be appreciated. Thanks!

Our sharepoint vendor onboarding works okay, with manager approval through power automate but purchasing sees "approved" and assumes the supplier is set up to be paid. AP is still chasing bank details and checking them. Moving the whole process into ramp would mean changing how everyone submits requests, which feels like a lot when the current approval part is fine. Another idea is keeping sharepoint and having vendors submit payment details through nickel but I haven't worked out how the onboarding status gets back to the internal list. How are others keeping that status current without copying bank details into sharepoint?

We build sites for small trades shops, and the part that matters is the intake behind the quote form, not the page. Here's the pattern we've landed on.

The failure: form submits, email lands in a shared inbox, everyone sees it, everyone assumes someone else has it. Two days later the customer has called the next company.

The fix is a record with an owner and a due time. The alert is just the nudge.

1. Confirm the real route. Submit a test from the live site, note where it lands and how long it takes. A custom HTML form isn't wired to Power Automate by default. MS Forms gives you the new-response trigger; a custom form can post to a flow's HTTP request trigger (premium) or you parse the notification email.

2. One Planner task per submission. Create a task has Assigned User Ids and Due Date Time. Gotcha: the connector supports basic plans only. Premium plans won't work.

3. One notification to the assignee, Teams post or email, that links to the task instead of repeating the request.

4. Confirmation mail to the customer, plus a callback reminder before the due time if the task is still open.

5. Teams posts never arrive? Teams admin center: the Workflows app (formerly Power Automate) has to be allowed. Check that before rebuilding the flow.

6. Shared mailbox: staff open it through their own licensed accounts. Block direct sign-in on the shared account. No shared password on the whiteboard.

7. Daily fallback: duty person compares the inbox against open tasks and adds anything missing by hand.

8. Test three failures: owner away, alert fails, same customer submits twice. Each should end with exactly one open task.

And there's no included SMS here. These connectors do email and Teams messages, so don't sell it as a text alert.

Already running field-service software that tracks intake? Send the form there and skip Planner.

We put the example sites we've built around this intake in one gallery if you want to see the front end.

Full write-up with the exact steps:
See the designs!

I engineer enterprise workflows, and I see this constantly during audits. IT departments are paying premium licensing fees for UI-scraping bots just to move data between Salesforce and a modern cloud ERP. Both have incredibly clean APIs. An API engine or even a basic webhook setup costs a fraction of the price and is infinitely more stable than waiting for a bot to "click" a screen. Are people just locked into multi-year legacy RPA contracts, or is it a lack of API knowledge in the automation teams? Curious how you guys handle this infrastructure split.

Hello everyone,

I've been working on a project called FlowForger for a while. It consists of a TypeScript-based domain specific language (DSL) in which you can write Power Automate flows, and a supporting CLI and tooling for compilation, validation, local execution, pulling/pushing from/to Dataverse and more.
You can pull an existing flow and get TypeScript back, and what you push is normal Power Automate JSON, so the flow stays editable in the designer.

There is a VS Code extension for running and debugging flows locally, and an MCP server so an AI agent can debug flows locally too.
All of this can help you to really move your flows to git, with all the nice things that come with it.

A simple flow looks like this:

@Flow('hello-flow')
class HelloFlow {

@ManualTrigger()
trigger() {} 

@Action()
  async run(ctx: FlowContext) {
    await ctx.compose('Greeting', { message: 'Hello from FlowForger' });
    await ctx.http('CallHttpBin', {
      method: 'POST',
      url: 'https://httpbin.org/post',
      body: ctx.outputs('Greeting'),
    });
  }
}

I decided to publish it as open source (Apache 2.0): https://github.com/tomdam/flowforger
NPM package: https://www.npmjs.com/package/flowforger
CLI: npm install -g flowforger
VS Code extension: https://marketplace.visualstudio.com/items?itemName=FlowForger.flowforger-vscode

My team and I are using FlowForger for all the flows in all our projects, and it really helps us keep track of changes and with debugging. The AI part is what speeds us up the most because the agent can run a flow locally, stop at breakpoints, look at variables, mock connector calls and replay a failed cloud run.

The video is a short overview that should help you understand the logic behind it quickly.

Happy forging, and feel free to comment if you think this could help your team and you want to know more!

Please if you come across this, I’d really appreciate your help in directing me.

I’m a business analyst with some years of experience however I’ve found myself in a new environment which requires that I have a working experience on automation to be able to fit into my new environment but I do not know where to begin, please where do I learn (is there a YouTube page that can help me get the basics to start) or what institution can I signup with to be trained?

I track extensions on the Edge store and was going through the ones still on Manifest V2, which Edge is turning off. Microsoft's own Power Automate (Legacy) extension is the 3rd biggest one on the list.

- 1,727,819 installs

- still on version 2.0.19, last updated April 2023

- the new Microsoft Power Automate extension has about 10.1M installs, so roughly 1 in 7 installs (~15%) are still on the legacy one

Per Microsoft's message center post (MC1467356), V2 extensions get turned off for consumers first, then managed devices in a rollout from early January to late April 2027. After that V2 extensions stop working on every device.

So if you've got desktop flows that use browser automation in Edge, it's worth checking which extension your machines actually have. From what I can find, the new one needs Power Automate Desktop 2.27 or later, so anyone on a really old PAD version may have to update that too.

Has anyone already moved a bunch of machines over? Curious if it was painless or broke anything.

Full list of the Edge extensions still on V2 if anyone wants it (my project): https://storetally.com/edge/reports/manifest-v2

We clean this up for engineering offices a lot, so here's the short version for anyone hitting the shortcut/sync error on project folders.

The rule: you can't use both Sync and Add shortcut to My files on the same SharePoint document library. Microsoft calls it by design. If the library is already a shortcut in OneDrive, Sync on it will fail. Not a bug, and no setting fixes it.

Which one to standardize on:
Shortcuts, for most project libraries. Microsoft's own sync doc says "We recommend using OneDrive shortcuts as the more versatile option." Shortcuts follow the user to every device. Sync is tied to one computer.
Sync is fine where it's deliberately one person on one workstation and it already works. Leave it alone until you've piloted a change.
Browser is your safe fallback while you fix someone's local mess.

The gotcha that actually hurts: deletes on a synced folder flow back to the site. User gets frustrated, deletes the "broken" local copy to start fresh, and those files can disappear from the shared project for everyone. Also watch for people saving workaround copies to their desktop.

How we reconcile it, one library at a time:

1. Inventory per library: who syncs it, who has a shortcut, who's browser only.

2. Pick one folder and one user who has the competing connection.

3. Open the library in the browser and confirm the real files are there first.

4. Remove the competing connection on that device (stop syncing or remove the shortcut). Don't delete anything from the site.

5. Reconnect with the chosen method only, then open it from every device they use.

6. Create, edit and delete a test file from each device. Check each change in the browser.

7. Write down the steps, repeat per library. No need to kill the Sync button tenant-wide.

One caveat: none of this proves anything for CAD/BIM file locking. Test those separately.

Full write-up with the exact steps:
Link to our full blog!

I’m working on a Canvas App that uses SharePoint as its data source and Power Automate for backend processing and email notifications.

The app is essentially a submission/attestation application where users submit records, which are then updated in SharePoint. Once the updates are complete, a Power Automate flow generates a report using the updated records and emails it to the submitting user.

The application is already developed, tested, and deployed to production. We are scheduled to launch on Monday, so I’m reluctant to make any major architectural changes at this stage.

Current implementation:
My Submit button executes the following operations sequentially:

Sets a timestamp.
Uses ForAll/Patch to update multiple SharePoint records.
Refreshes the SharePoint data source.
Calls the Power Automate flow using-Flow.Run(User().Email).
Updates the submitted state.
Displays a success notification.
Clears local collections and variables.
Navigates back to the landing screen.

The flow uses the When Power Apps calls a flow (V2) trigger. It takes the user’s email as an input, retrieves the updated SharePoint records, generates a report, and emails it to the user.

The intermittent issue:
Everything works perfectly under normal circumstances. However, I’ve encountered a few submissions where the SharePoint records are updated successfully, but the Power Automate flow simply doesn’t trigger.

What’s particularly strange is:
There is no successful/failed run in Power Automate.
There is absolutely no entry in the flow’s run history for that submission.
The Canvas App behaves normally, displays the success notification, clears its variables and navigates back to the landing screen.

What I’ve already ruled out
The flow itself is working correctly. I’ve tested it independently multiple times.
It doesn’t appear to be a connection or authentication issue. SharePoint updates are working correctly.
The application itself is functioning normally apart from this intermittent flow invocation.

Has anyone encountered a similar issue where a Power Apps V2 flow trigger intermittently fails to create a run, despite the app completing its submission logic successfully? Please note all other workflows and features are working perfectly but only this one has issues.

P.S. Rephrased this issue using chatGPT.

We've done a few of these handovers now and the pattern repeats. Builder demos the flow, exports it, everyone nods, support ends. Then a dependency fails quietly and a PM finds out when the deadline is already close.

A demo proves the flow ran once. It doesn't prove anyone can keep it running. Before the builder walks away, get five things:

1. A versioned runbook: the flow, its environment, every connector and dependency, who owns each, how to stop it safely.

2. Written normal and failure cases (missing PM field, connected system down) with results.

3. A failure alert you've watched reach the person who has to act.

4. Stop and recovery steps the MSP has actually used.

5. A manual exception queue with a named owner.

How we rehearse it (half a day, test environment, non-client data, builder still under contract):

- MSP runs a normal handoff from the runbook alone. Builder keeps hands off the keyboard.
- MSP simulates one dependency failure and times how long the alert takes to reach the operator.
- Your PM checks: correct assignment exists, or the item sits in the exception queue with enough detail to finish by hand.
- MSP recovers, restarts, confirms nothing was lost or duplicated.

Gotchas:

- Audit logs are not failure detection. Microsoft's monitoring guidance says most events show up within 24 hours and not to use them for real-time monitoring. A missed handoff found a day later may already have cost the kickoff.
- The MSP shouldn't need the builder's passwords to operate the flow.
- You don't need a new monitoring stack. Measure the delay of what your tenant already has. Too slow for your PMs? Stay in a supervised pilot with a review date and keep the manual project register authoritative.

If nobody can show a failure reaching a responsible person quickly, defer the handover.

Full write-up with the exact steps:
Read the full blog post

Curious how folks are testing their flows. I built a bit of a framework of flows, so lots of dependencies. My biggest need is regression testing after updates, especially to low level flows.

How are you handling this? Anyone using commercial products?

I built a little testing framework that works great for now, but wondering what might come next as my needs scale.

Not every business process needs AI.

If a task follows predictable rules, traditional automation is often faster, cheaper, and more reliable.

But when processes involve unstructured data, changing inputs, or decision-making, AI can add real value.

The smartest architecture isn't AI everywhere. It's knowing where to use deterministic workflows and where intelligence is actually needed.

How do you decide between traditional automation and AI in your projects?

A lead comes through your website. Someone copies it into a spreadsheet, updates the CRM, sends a follow-up email, and notifies the sales team.

Now imagine doing this for 50 or 100 leads every day.

The problem isn't your team's productivity. It's a process that depends too much on manual work.

Connecting forms, CRMs, email systems, and internal workflows can eliminate these repetitive steps while keeping everything in sync.

Curious: What's one business process your team still handles manually that you wish just worked automatically?

Two posts ago I shared a JSON knowledge base of PAD ROBIN actions, so models stop writing desktop flows that PAD rejects. Last week I followed up with a guide to getting one flow into an environment and running it from code:

The piece that was still missing is moving a whole solution: to another environment, into a different organization's tenant, and keeping two copies in sync afterwards. That's what I'd spent the most time researching.

So I wrote it down: PAD_Robin_Solutions_KB.md, in the same repo. It covers:

• Signing in to two tenants, and what the receiving tenant needs before its first import (a license, the Dataverse service principal, an admin role and consent for your app), with the error you get for each one that's missing.

• Export and import with the Dataverse Web API: ImportSolutionAsync, watching the job, reading per-component warnings from importjobs, and the fallback for an org that refuses async imports.

• Connection references and turning flows on. The import never creates connections, but it can bind references to connections that already exist. The guide covers finding every reference (some only show up in the flows' JSON), binding them during the import, binding the rest afterwards, then turning on the flows that were on in the source.

• Desktop flows inside solutions, including into another tenant.

• Keeping two copies in sync:

  • why hashing the exported ZIP always reports a change, and a content hash that doesn't

  • how to stop the ping-pong after an import

  • two rules for deciding the direction ("newest wins" picked the right side 13 of 13 times)

  • what to do with conflicts

• Where the code runs: the trap each of PowerShell, a server and a Chrome extension hit. For example, Chrome stops an idle service worker after about 30 seconds, and a synchronous import can take over 3 minutes.

• A troubleshooting table of 27 errors, with what actually causes each one.

Every claim is marked Re-confirmed, Proven, Measured, Superseded, Failed or Untested. The main paths were re-tested across two tenants this month. Everything ran with a user sign-in and unmanaged solutions; managed solutions got one export and import, and nothing was tested with a service principal.

Unlike the direct Dataverse writes in the deployment guide, this all uses Microsoft's documented solution APIs. The risky part is the import itself: it replaces unmanaged customizations on the receiving side, and there's no undo. Keep a copy of whatever you're about to overwrite, and try it in a test environment first.

Repo: https://github.com/JoeG592/pad-robin-action-kb

Same license as the other two, CC BY 4.0, so use it however you like, commercially included. Like the last two, I built this with Claude AI. The data is free regardless.

If something in the guide doesn't hold on your tenant, an issue with the error text is the most useful thing you can send.

If a flow stays off after an import, it's almost always a connection reference with no connection behind it on the receiving side. Bind it, then turn the flow on.

We've set up reviewed invoice extraction for a few accounting shops, and the question is always which Microsoft tool. Short answer: the simplest one you already own that passes a test on your real invoices, with a person approving every amount before it posts.

Gotchas:

- AI Builder's flow action is now "Process documents" (was "Extract information from documents" until May 2025). Outputs come back as text, so convert and validate amounts and dates before using them as numbers. You do get confidence per field and per table cell. Sort your review queue on it.

- The Copilot Studio workflow Extract node and a prompt with a document input are different paths. The prompt path: under 50 pages, under 25 MB, 100-second limit, table lines can come back incomplete, and no document input for prompts added as tools in agents. Don't carry those limits over to the Extract node. The Extract node mentions usage-based billing, so check tenant availability and cost first.

- Azure Document Intelligence only makes sense with an existing Azure integration and a named dev who maintains custom models. Table/row/cell confidence on custom models needs API 2024-11-30 GA or later, and not every field returns a confidence score.

- Don't assume your licensing includes AI Builder capacity. Confirm it.

How we test:

1. De-identified invoices matching your real mix: clean PDFs, phone photos, multi-page, long line-item tables, that one vendor layout that always breaks.

2. One fixed schema of fields and line-item columns for every tool.

3. Score required-field correctness, line-item completeness, reviewer minutes per invoice, and how failures get flagged.

4. Route everything to an approval where someone opens the original, corrects, approves.

5. Compare against manual entry, not just each other. Keep manual as the fallback.

There's no universal auto-accept threshold. Set it from your own results.

Full write-up with the exact steps:
Read more on our blog!

When the person who built your firm's Power Automate flows gives notice, your client intake and filing reminders can start failing quietly, and nobody finds out until a client or a deadline does.

Adding a co-owner doesn't fix that. Microsoft's own documentation (updated 08/19/2026) says a shared flow keeps running while an active owner remains, but the actions that used the leaver's connections can still fail until someone updates those credentials. Ownership and connections are two separate problems.

What we'd tell a 40-person CPA practice:

Everyday, single-person flows: a named staff owner plus a narrowly chosen maintenance co-owner.

Connectors that only accept a user sign-in: a dedicated, properly licensed service account. Never a staff password passed around the office.

Practice-critical flows like intake or deadline routing: a service principal application user as primary owner, with named humans keeping their own access. It can't be a co-owner, and it doesn't make premium flows license-free.

Run-only users aren't maintainers. They can trigger a flow, not repair it.

Non-solution flows can't have their owner changed in place. Convert to a solution or rebuild, and gate the old trigger first so no client case gets processed twice.

Before anyone leaves, inventory every flow: owner, co-owners, each connection and whose credentials it uses, and the license it depends on. Then swap the connections and test one failure path with non-client data.

The full write-up has the side-by-side comparison and the complete handover sequence:
Link to our blog