Episode Details

You’ve automated a workflow with Microsoft 365, only to hit a wall with constant permission requests, broken background jobs, and security warnings. Why do custom app integrations feel so much riskier than they should? Today, I’m breaking down the hidden security traps of delegated permissions—and the smarter path almost nobody talks about: app-only permissions in Microsoft Graph.If you want safer, smoother Microsoft 365 integrations that just work, stick around. We’ll tackle exactly where most setups go wrong, and I’ll show you the step-by-step fix that unlocks seamless, secure automation.Why Delegated Permissions Break Your AutomationIf you’ve ever found yourself wondering why your Microsoft 365 automations stall out at the worst possible time, you aren’t alone. Maybe it’s late at night. You’ve set up Power Automate to sync files for accounting, and you think you’re set—but two hours later, that job throws a “please login” prompt or just quietly dies while nobody’s watching. The reason? Most custom apps and automations start with delegated permissions, because—honestly—it feels like the quickest way to get something working. Use a user’s credentials, check a box, and your app instantly inherits whatever that person can do. For a new project, that approach is often tempting. It’s practically encouraged by the UI when setting up flows, bots, or even one-off scripts.But there’s a catch that comes back to bite every single admin who tries to scale this model. Delegated permissions tie your automation to an actual human user. Under the hood, every API call is piggybacking on a real person’s permissions and session. That means anytime the user logs out, gets a new password, or leaves the company, your critical workflow grinds to a halt. The job doesn’t just hit pause; it fails—sometimes loudly with an error, sometimes in silence until someone starts asking about missing reports.Wake up calls usually come early. One morning you discover that automated file upload you tested for weeks suddenly failed at 2 AM. Support tickets pile up. The logs just show “authentication failed,” or sometimes nothing at all because a session silently expired. It’s not just about the inconvenience, either. There’s research showing that 70 percent of custom Microsoft 365 app support tickets boil down to issues with authentication and token handling—not the logic of the app itself. Most of those relate directly back to delegated permissions: session timeouts, invalid tokens, or missing MFA steps.It sneaks up on you in other ways, too. Delegated permissions are persistent headaches when users change roles or go out on leave. Your payroll bot or HR automation? Relying on an account tied to a real person is an accident waiting to happen. Even if you assign a special “service account,” someone’s going to forget the password expiration, or not realize the license is about to be removed. Internal audits end up flagging flows and bots that haven’t run in weeks because nobody even checked that a password needed updating.What’s worse is that the path of least resistance encourages risky shortcuts. Maybe your workflow needs to touch resources across SharePoint, Exchange, and Teams. You keep adding permissions to “make things work”—a little more mailbox access here, site collection access there, until suddenly the user tied to that process has more admin rights than your own IT staff. For the sake of reliable automation, teams sometimes grant global admin status to these accounts. Not because it’s smart, but because delegated permissions force your hand when automation becomes business-critical. That transfer of privilege isn’t theoretical—there are plenty of real-world stories about bots accidentally gaining far too much access because delegated accounts kept hitting permission errors.The cracks keep adding up. Let’s say you run a monthly reconciliation process for Finance. Every month, the Power Automate flow slows down—or worse, fails outright. Why? It depends on