u/sam_ibrahim

After 5.5 years building and fixing Power Automate flows across enterprise projects, the same mistakes show up over and over. Not beginner mistakes — mistakes that experienced people make because they work fine until they don't.

1. No error handling whatsoever Most flows are built assuming everything will work. No try/catch scope, no failure branch, no notification when something breaks. The flow just silently fails and nobody knows until someone complains that nothing happened.

2. Testing only the happy path Everyone tests when the approver approves. Nobody tests what happens when the approver is on leave, rejects with no comment, or their license expires. Edge cases are where flows die.

3. Hardcoded values everywhere Emails, URLs, IDs, and environment-specific values buried inside actions. The moment you move from dev to production or someone changes a mailbox, the whole flow breaks and you spend an hour hunting down where that value was hardcoded.

4. No concurrency control on loops Apply to each runs in parallel by default. If you're writing to a SharePoint list or updating a record inside a loop without controlling concurrency, you'll get race conditions and duplicate or missing data.

5. Connections tied to one person's account Built the flow using your personal connection? The moment that person leaves the company or changes their password, every flow using that connection dies. Use service accounts.

6. No documentation Six months later nobody — including the person who built it — knows what the flow does, why certain conditions exist, or what that specific expression was supposed to handle.

Most of these take five minutes to fix during development and hours to debug in production.

If you're working on a Power Automate project and want a second pair of eyes, or need something built properly from the start. DM me.

See this come up constantly and the confusion always starts with how the question is framed.

Dataverse and SharePoint Lists are not two versions of the same thing. They solve different problems.

Dataverse is a purpose-built database for Power Platform. Proper table relationships, row-level security, business rules enforced at the data layer, calculated columns, and performance that handles millions of records without flinching.

SharePoint Lists is a lightweight data storage tool inside M365. Great for simple tracking, team collaboration, and small datasets. It was built to support SharePoint sites — not to power business applications.

So, the real question was never which one to pick. The real question is:

What exactly am I building?

Answer that honestly and the right choice becomes obvious:

• Small internal tool, limited users, simple data, tight budget → SharePoint Lists works fine
• Growing user base, multiple roles, table relationships, data integrity matters → Dataverse, no debate

The 5,000-row threshold in SharePoint Lists alone has broken more apps than bad code ever has. And migrating from SharePoint Lists to Dataverse mid-project is painful in a way that's hard to describe until you've done it.

The licensing cost of Dataverse is real. But so is the cost of rebuilding everything six months later.

Know what you're building first. The data source decision makes itself after that.

Happy to answer if anyone is planning a build and weighing both options. And if you're working on a Power Platform project and need a hand — whether it's architecture decisions like this or full development. DM me.

Hey,

I’ve been working with Power Platform full-time and freelancing for like 5.5 years, focused entirely on enterprise-level projects — most of my work has been with organizations of 200+ users across healthcare, manufacturing, finance, real estate, government, and more.

Over that time I’ve delivered a lot of solutions that actually moved the needle for clients, so I’ll share some real examples instead of just listing skills.

Some of what I’ve built:
Enterprise HR & Operations Portal (Power Pages + Dataverse)
External-facing portal for a large organization where employees, contractors, and managers each had different roles and access levels. Built on Dataverse with a complex security model — row-level security, business units, and custom API integrations pulling data from their ERP.
The client went from a fully manual process to a self-service system handling hundreds of requests per day.

Multi-Stage Procurement Approval System (Power Automate + Teams)
Full approval lifecycle for a manufacturing company — requisitions, budget checks, department head sign-off, finance review, and final authorization. Built with parallel branching, delegation logic, timeout handling, and full audit trail in Dataverse. Replaced a process that was running on emails and spreadsheets for years.

AI-Powered Document Processing (AI Builder + Power Automate)
Automated invoice and document intake for a finance client. AI Builder handled extraction, Power Automate handled routing and validation, and everything landed clean in Dataverse with zero manual entry. Cut processing time from days to under an hour.

Large-Scale Automation Overhaul (300+ flows)
Worked with a retail group that had a chaotic mix of legacy flows nobody fully understood. Audited, rebuilt, and restructured the entire automation layer — proper naming conventions, environment strategy, ALM with pipelines, and error handling that actually notifies the right people when something breaks.

Custom Connector + Third-Party API Integration
Built custom connectors for clients integrating with systems outside the Microsoft ecosystem — payment gateways, logistics APIs, government data services. Clean OAuth2 flows, proper error handling, and documented for internal teams to maintain.

A few things I’ve learned building at this scale:

•	Environment strategy and ALM are not optional on enterprise projects. They save you from yourself six months in.  
•	Dataverse security models need to be designed before a single table is created, not after the app is half built.  
•	Power Pages is seriously underused. For client-facing or partner portals it’s one of the strongest tools in the stack.  
•	AI Builder has matured enough to use in production. Stop sleeping on it.

I’m currently available for freelance projects.
If you’re building something complex, migrating off legacy systems, or just stuck on something that should work but doesn’t — I’d be glad to talk.
DM me or drop a comment. I’m also happy to answer technical questions here.