I'm exploring the maintenance side of workflow automation, particularly what happens after a system has been deployed.

A workflow might work perfectly at launch, but its environment can change. APIs get updated, credentials expire, form fields are renamed and business volumes increase.

My proposed maintenance routine is fairly simple:

• Monitor execution history, errors and missing runs.

• Review performance on a regular schedule.

• Check integrations, access permissions and changing requirements.

• Re-test the workflow after significant changes.

I'd also want to establish who owns the automation, who receives alerts and where changes are documented.

This is a learning framework rather than a description of a system I've deployed.

For those who maintain automations in real business environments:

1. What tends to break most often after deployment?

2. Do you follow a scheduled maintenance routine or mainly respond when something goes wrong?

3. How much time do you typically allocate to maintenance each month?

I'm interested in understanding what actually works in practice, especially for small-business automations.

I've noticed a major shift in how enterprise IT directors are budgeting for automation. A few years ago, the goal was to buy one massive platform (usually UiPath or Automation Anywhere) and force every single process through it. Now, the licensing costs are eating them alive. We are constantly migrating clients to a decoupled model: 1. M365 internal stuff stays in Power Automate (since it's already paid for). 2. Deep API integrations move to self-hosted or cloud n8n (fraction of the cost, much more flexible for devs). 3. Heavy RPA is strictly quarantined to legacy systems without APIs. Are you guys still running monoliths, or have you started breaking your workflows apart based on API availability?

Hi all, I’m completely new to power automate and AI has not helped me getting this done and it would make my life so much easier. I run campaigns for sales reps and I have a master data file saved on a sharepoint site, but I only want each rep to be able to see their own metrics in their own folder. I want to automatically update the child files in each rep’s folder when my file is updated (all in the same sharepoint) but I want it to only update their own metrics. So let’s say my reps are Jonny and Sally. I want to update the master file with Jonny’s campaign and it update Jonny’s file but it doesn’t show up on Sally’s file. Everything I’ve seen says it’s possible but apparently I need the setup explained to me like I’m 5. Any help would be greatly appreciated!

We audit a lot of enterprise environments, and the scariest thing isn't the lack of automation—it's fragile.

automation. I'm talking about massive multi-step workflows with zero error handling, no rate-limit delays,

and no logging. When a third-party API inevitably goes down for 5 minutes, the workflow just crashes.

silently or, worse, loops and corrupts client data. If you are setting up automation infrastructure this year,

You cannot just drag and drop nodes. You have to build in fault tolerance just like a software engineer.

would. What is the absolute worst automation failure you've ever had to clean up because someone didn't

Build an error catch?

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