u/TechCurious84

We've been using power automate for most our lighter workflows and it's been fine for what it is, until the workflow starts requiring state management, retries, auditability, and complex exception handling across multiple systems until eventually it feels like the workarounds become a bit more effort than building the integration properly in the first place.

What does a process actually look like when low code isn't the right fit and you need something with more infrastructure behind it?

Planning a Business Central migration and the consultants have given us a clean timeline with buffer hours built in. I believe in the plan.

I just don't believe a cutover has ever gone exactly to plan for anyone, ever. If you've been through one, what actually went sideways that the runbook didn't account for? Trying to mentally prepare the team rather than just hand them a Gantt chart and hope.

The standard advice for rolling out Infor CloudSuite across multiple sites is toget one site right, build a template, replicate. Makes sense in theory. In practice I've seen the template start fraying the moment site two has meaningfully different operations , different regulatory requirements, different 3PL setup, a legacy integration that wasn't in scope for site one.

Where does the template actually hold and where do you end up essentially reimplementing? And how do you govern scope creep when local teams start asking for customizations that undo the whole point of standardizing?

My manager wants to roll this out to more of the team (accounting) but I'm a little nervous about training overhead, since half our team is not super technical and gets thrown off by UI changes pretty easily. For anyone who's rolled this out more broadly, was there a noticeable adjustment period for regular users, or did they pick it up naturally?

 

Not a strict or universal rule but it's been consistent enough that It has to be thought about a bit imo.

The teams that ship tend to have someone who's comfortable making a call on "good enough for now" and moving. The ones that stay in planning tend to be optimizing for a perfect architecture that accounts for every future requirement before writing a line of production code.

The irony is that the second approach usually tends to produce worse long term outcomes. Requirements tend to change, the perfect schema you designed for doesn't match what the business actually needed six months later, and you've spent all that time protecting against a future that didn't arrive.

The "good enough for now" teams aren't being sloppy , they're just scoping tightly, shipping, learning from real usage, and iterating. Any of you noticed the same thing? or am I just pattern matching on a small sample?

 

We've had a few cases where predictive models performed well offline and in pilot testing, but didn't end up being used consistently in production decision-making. The breakdown happened during adoption, not performance. AUC, accuracy, forecast error, the metrics were generally acceptable for the use case.

The ones that DO get used tend to end up embedded directly into existing workflows. If people have to leave their normal tools to check a dashboard, it usually doesn't last. Output presentation matters too, especially around uncertainty. A single score with no context leads to either over trusting or complete dismissal.

Anyone who’s managed to get a model used in the real world, what was the thing that finally made it stick? like what actually changed between the ones people ignored after the pilot... Id appreciate it if you could give me some input, Thank you.

Something I've noticed across retail and manufacturing, is that every department is measured on their own KPIs, so when a new ERP comes in, the instinct is always the same, the rush to make the system fit around existing workflows rather than adapt to how the business actually needs to function as a whole. Everyone's optimizing for their own "corner" , to say.

What makes this troublesome in these sectors is how tightly everything is connected underneath. One quietly changed field in procurement can ripple into production timelines, floor space allocation, and cash flow projections before anyone notices. So by the time configuration starts, you're not building on clean, aligned processes, you're kind of digitalizing the same mess that was already there, just faster and at a much higher cost.

Those who've been through a big rollout here, what actually got departments out of their own heads before it was too late? Workshop formats, alignment sessions, governance structures before config,anything that genuinely worked would be really useful to hear.

Most of the enterprise AI conversations seem to hit a similar roadblock,in my experience, being that the data isn't ready.

But the phrase tends to mask two different realities. Sometimes the data is the problem, messy schemas, duplicated sources, inconsistent definitions, no clear lineage. In those cases, its simply a matter of engineering and cleaning up. When the data is actually in pretty good shape, it's still not “ready” because there is no shared “trust” in it. Ownership unclear; teams disagreeing on definitions; and governance has not caught up. The data is there to be used,kinda, but organizationally it's still fragmented. I’ve seen the second one treated like a data engineering issue when it’s really a coordination and accountability problem. That’s the one that gets missed a lot. 

What always seems to come up when it comes to enterprise automation: companies want to leverage their RPA bots for test automation regression test coverage, and then struggle with maintenance down the line. RPA production and test automation have entirely different purposes: one is about optimizing an existing process, the other is about asserting results and dealing with test data.

Wondering what configurations people are using in 2026. Are you maintaining two entirely distinct tool chains here, or have you found a way to make unified automation happen?

Is it the script maintenance, test data preparation or covering all of the cross-module flows in the ERP system that is proving difficult?

I’ve been closely following the shift in how we handle QA for complex ERP environments like CloudSuite 365, especially within manufacturing and retail. For years, the industry standard has been rigid, scripted automation but as rollouts get faster, those scripts often become a "maintenance cliff" that breaks the moment a business process or UI slightly evolves.
Lately, I’ve been looking into how AI agents can take on the more judgment-heavy tasks that traditional automation misses. Instead of just following a linear path, these agents seem to act as assistants observing regression cycles, flagging anomalies, and even adapting test data based on previous runs.
 
What’s particularly interesting is their potential to catch “silent” test failures. We’ve all seen cases where a script technically "passes," but the actual business logic like an inventory reconciliation or a multi-level BOM update is fundamentally broken. Moving toward autonomous validation feels like a necessary step to keep up with modern Go-Live schedules, but the transition isn't without its hurdles.
 
I’m curious to hear from other strategists or QA leads: Are you starting to blend autonomous agents into your ERP pipelines? Or are you sticking with traditional scripted frameworks for now? What’s been the biggest friction point in making that jump?