Speaker 1: Ever feel like deploying power platform solutions is one step forward,
Speaker 1: two steps back. If you're tired of watching your data
Speaker 1: verse changes break in QA or seeing dependencies tank your deployments, you're.
Speaker 2: Exactly who this video is for.
Speaker 1: Today, we'll break down the Azure DevOps pipeline component by component,
Speaker 1: so your deployments run like a well oiled machine, not
Speaker 1: a gamble. Curious how rollback really works when automation gets complicated,
Speaker 1: Let's unravel what the dogs never tell you manual deployments
Speaker 1: versus automated pipelines where the pain really starts. If you
Speaker 1: work with power platform, you've probably had that moment. Hours
Speaker 1: of tweaking a model driven app, finessing a power automate flow,
Speaker 1: carefully tuning security roles the whole checklist. You've double checked
Speaker 1: every field, hit export solution, uploaded your ZIP, and crossed
Speaker 1: your fingers as QA gets a new build. Then right
Speaker 1: as everyone's getting ready for a demo or go live,
Speaker 1: something falls over, a table, doesn't show up, a flow
Speaker 1: triggers in the wrong environment, or worse, the import fails
Speaker 1: with one of those cryptic error codes that only means
Speaker 1: something somewhere didn't.
Speaker 2: Match up the room suddenly feels quieter.
Speaker 1: That familiar pit in your stomach sets in, and it's
Speaker 1: back to trying to hunt down what failed, where and why.
Speaker 1: This is the daily reality for teams relying on manual
Speaker 1: deployments in Power Platform. You're juggling solution exports to your desktop,
Speaker 1: moving ZIP files between environments, sometimes using an old Excel
Speaker 1: sheet or a team's chat to log what's moved and when.
Speaker 1: If you miss a customization, maybe it's a new table
Speaker 1: or a connection reference for a flow. Your deployment is
Speaker 1: halfway done but completely broken. The classic it works in dev,
Speaker 1: but QA has no clue what you just sent over.
Speaker 1: Now everyone's in slack or teams trying to figure out
Speaker 1: what's missing or who last exported the real version of
Speaker 1: the app. Manual deployments are sneakier in their fragility than
Speaker 1: teams expect. It isn't just about missing steps. You're dealing
Speaker 1: with environments that quietly drift out of alignment over weeks
Speaker 1: of changes. DEV gets a new connector or permission, but
Speaker 1: no one logs it for the next deployment. Maybe if
Speaker 1: someone tweaks a flow's trigger details, but only in DEV.
Speaker 1: By the time you're in production, there's a patchwork of
Speaker 1: configuration drift. Even if you try to document everything, human
Speaker 1: error always finds a way in one late night change,
Speaker 1: after a stand up an overlooked security role or a
Speaker 1: hand migrated environment variable, suddenly you're chasing a problem that
Speaker 1: wasn't obvious two days ago, but is now blocking user
Speaker 1: adoption or corrupted data in a critical integration. Here's a
Speaker 1: story that probably sounds familiar. A business critical power automate
Speaker 1: flow was humming along in DEV, moving rows between debtaverse
Speaker 1: tables using some new connection references. Export to QA import
Speaker 1: looks fine, but nothing triggers. After hours of combing through
Speaker 1: logs and rechecking permissions, someone realizes the QA environment never
Speaker 1: had the right connection reference. There's no warning in the UI,
Speaker 1: nothing flagged in the import step. It required a deep
Speaker 1: dive into solution layers and component dependencies, and meanwhile the
Speaker 1: business had a broken process for the better part of
Speaker 1: a week. Microsoft openly calls out this pain point in
Speaker 1: their documentation, which is almost reassuring even experienced administrators. Folks
Speaker 1: who live and breathe data verse loose track of hidden
Speaker 1: dependencies or nuanced environment differences, stuff that barely gets a
Speaker 1: line in the docks is often the exact thing that
Speaker 1: derails a go live. These aren't rookie mistakes. They're the
Speaker 1: fallout of a platform that's flexible but quietly full of
Speaker 1: cross links and dependencies. When you rely on people to
Speaker 1: remember every setting, it's just a matter of time before
Speaker 1: something slips. So the big pitch is automation, as your
Speaker 1: DevOps sits at the edge of this problem, promising to
Speaker 1: turn those manual, error prone steps into repeatable, traceable, and
Speaker 1: hopefully bulletproof pipelines. The idea looks good on paper. You
Speaker 1: wire up a pipeline, feed it your power platform solution
Speaker 1: and let it handle the heavy lifting. Solution gets exported,
Speaker 1: imported dependencies are checked, and if anything fails you spot
Speaker 1: it right away. You get real timestamped logs, so there's
Speaker 1: no more wondering if Alice or Bob has the latest
Speaker 1: copy done right. Every deployment is versioned and traceable back
Speaker 1: to source. No more dependency roulette or last minute surprises.
Speaker 1: And here's the number everyone likes to share in presentations.
Speaker 1: Teams that move from manual processes to automated pipelines see
Speaker 1: feedback loops that are not just faster but actually close
Speaker 1: the door on most failed deployments. Sure, mistakes still happen,
Speaker 1: but they're caught early and you don't spend hours untangling
Speaker 1: what went wrong. More importantly, you get auditability. You can
Speaker 1: trace each deployment, know exactly who shipped what and yes,
Speaker 1: pinpoint where and how something failed. But the reality is
Speaker 1: this is about trust, not just speed. If your team
Speaker 1: can't trust the deployment process, if every release feels like
Speaker 1: a dice roll, then every good feature you build is
Speaker 1: at risk. Stakeholders hesitate to release, users get frustrated by
Speaker 1: outages or missing features. The promise of rapid low code
Speaker 1: innovation falls flat when the last mile remains unreliable. Automation
Speaker 1: isn't just about saving time or impressing leadership by going DevOps.
Speaker 2: It's the only.
Speaker 1: Realistic way to deliver power platform solutions that work the
Speaker 1: same way every single time, across every environment. So with
Speaker 1: automated pipelines you get predictability. You get a reliable record
Speaker 1: of every deployment, dependency and step taken. True CICD for
Speaker 1: power platform becomes possible, and troubleshooting becomes a matter of
Speaker 1: logs not guesswork. Of course, none of this happens by magic.
Speaker 1: Automation is only as strong as the links between your
Speaker 1: pipeline and your environments. That's where things can still go sideways.
Speaker 1: So next up, let's talk about wiring up Azure DevOps
Speaker 1: to your power platform in a way that's stable, secure,
Speaker 1: and doesn't break at three in the morning. The glue
Speaker 1: service connections and agent pools that don't break. If you've
Speaker 1: tried connecting Azure DevOps to power Platform and watched the
Speaker 1: pipeline instantly throw a permissions error or just hang for
Speaker 1: what feels like forever, you're in good company. Nearly every
Speaker 1: team hits this wall at some point. The pipeline might
Speaker 1: be beautifully designed, your YAMA might be flawless, but just
Speaker 1: one misconfigured service connection or missing agent setting and you're
Speaker 1: staring at authentication errors or wondering why nothing ever kicks off.
Speaker 1: The reality is power platform deployments live or die on
Speaker 1: what's happening behind the scenes, what I like to call
Speaker 1: the invisible plumbing. We're talking about service connections, authentication flows,
Speaker 1: agent pools, and those little settings that quietly hold everything
Speaker 1: together or quietly wreck your day. Let's be honest, the
Speaker 1: concept feels deceptively simple. You create a service connection in
Speaker 1: Azure DevOps, give it some credentials, point it at your environment,
Speaker 1: and get back to building your flows under the hood.
Speaker 1: Though it's a web of permissions, tokens and API handshacks.
Speaker 1: Miss one and you might break not just your pipeline,
Speaker 1: but potentially the underlying integration for everyone else using the
Speaker 1: same service principle. This isn't just theoretical. I've seen teams
Speaker 1: work perfectly for months only to run into a single
Speaker 1: deployment that refused to go through. It always comes down
Speaker 1: to some backstage detail, an expired secret role missing from
Speaker 1: the service account, or a changed permission scope in as
Speaker 1: your active directory. Worst case, you can accidentally lock yourself
Speaker 1: or your team out of environments if you get too
Speaker 1: aggressive with role assignments. Imagine the setup you finally get
Speaker 1: approval to use a service principle for your pipeline, aiming
Speaker 1: for real security and separation of duties. The theory makes sense.
Speaker 1: You've got one identity per environment and everything should just work.
Speaker 1: But then deployment day comes. You run your pipeline and
Speaker 1: it fails at the very first authentication step. The error
Speaker 1: messages are obscure. You dig through logs, only to find
Speaker 1: that you missed a tiny data verse role assignment one checkbox,
Speaker 1: and now your agent can't access the environment. Of course,
Speaker 1: the logs don't call this out. They just spit back
Speaker 1: a generic not authorized message. So you're poking around the
Speaker 1: Azure portal at eleven PM, toggling permissions and hoping not
Speaker 1: to break something else in the process. It's equal parts
Speaker 1: frustrating and completely avoidable. There's a pattern here. One missed
Speaker 1: permission or a non standard setup can block the whole show.
Speaker 1: This is why best practice is to use a dedicated
Speaker 1: service principle. And here's the kicker. Don't just assign it
Speaker 1: admin rights everywhere out of convenience. Assign only the minimal
Speaker 1: data verse roles needed for its specific environment and task.
Speaker 1: That might sound like overkill if you're new to DevOps,
Speaker 1: but in the real world this saves you from someone
Speaker 1: accidentally deleting or corrupting data because an all powerful service
Speaker 1: principle had access everywhere. It also means rolling keys or
Speaker 1: changing secrets is cleaner. If you need to revoke a
Speaker 1: connection from QA, you don't risk blowing up production. Teams
Speaker 1: that stick to this separation rarely have the all environments
Speaker 1: go down.
Speaker 2: Panic.
Speaker 1: Now let's talk about agent pools, because oddly they're usually
Speaker 1: treated like an afterthought. You get two main options, Microsoft
Speaker 1: hosted agents and self hosted agents. Most folks grab whatever's
Speaker 1: default in their Azure DevOps project and hope it just works.
Speaker 1: For basic dot net or web jobs. This usually flies,
Speaker 1: but with power Platform you'll eventually hit a wall. Microsoft
Speaker 1: hosted agents are great for basic build tasks, but since
Speaker 1: they're dynamically provisioned and shared, you can't guarantee all pre
Speaker 1: RECs are present, like specific versions of the power Platform
Speaker 1: built tools or custom PowerShell modules you need for more
Speaker 1: complex solution tasks. Plus, if you need custom software or
Speaker 1: integration anything that isn't in the standard image, you're stuck
Speaker 1: and good luck troubleshooting isolated failures across environments you don't own.
Speaker 1: Self hosted agents give you full control over the environment,
Speaker 1: which is a blessing and a curse. On one hand,
Speaker 1: you can pre install build tools, SDKs, scripts, whatever your
Speaker 1: project requires. If you've got unique connectors or a stable
Speaker 1: set of dependencies, this can save piles of time. On
Speaker 1: the other hand, you're fully on the hook for machine updates, patching,
Speaker 1: and keeping the agent up and running. Still, plenty of
Speaker 1: teams prefer this route, especially if their power platform work
Speaker 1: includes a lot of custom build steps or integrations that
Speaker 1: don't play well with the shared Microsoft images. One tip
Speaker 1: that gets overlooked always run a dry run, test your
Speaker 1: service connection and do a trial export before you feed
Speaker 1: anything important through your pipeline. Just because your pipeline says
Speaker 1: connected doesn't mean it has the right level of access
Speaker 1: for every operation. You want to perform that test export.
Speaker 1: It's your safety net. You'll catch permissions gaps, roll issues,
Speaker 1: and even basic network weirdness before you're knee deep in
Speaker 1: a production deployment. Better to find out now than when
Speaker 1: you're racing against the go live windows. So what you
Speaker 1: really want is reliability without surprises. Durable service connections and
Speaker 1: agent pools are the foundation for everything that comes after.
Speaker 1: Get these wrong, and it doesn't matter how polished your
Speaker 1: YAML or how fancy your pipeline tasks are, they'll fail
Speaker 1: because the basics aren't wired upright. Once you nail this
Speaker 1: invisible plumbing, the rest of the pipeline process falls into
Speaker 1: place with a lot less drama a lot more predictability.
Speaker 1: The headaches move from why did my pipeline never start
Speaker 1: to how do I make my pipeline even smarter? Which
Speaker 1: is a much more fun problem to solve. With those
Speaker 1: connections stable and your agents reliably humming along, you've just
Speaker 1: cleared the first real hurdle. But solid plumbing isn't guaranteed
Speaker 1: to catch solution issues before they hit production. Next up,
Speaker 1: let's dive into how automated checks and validations protect your
Speaker 1: environments from silent errors before they spread. Automated guardrails dependency
Speaker 1: checks and pre deployment validations. If you've ever watched a
Speaker 1: power platform deployment pass in DEV, go through the motions
Speaker 1: in QA and then set off alarms the minute it
Speaker 1: lands in production, you know where this is heading. Problems
Speaker 1: almost never announce themselves ahead of time. Instead, you get
Speaker 1: those quietly hidden dependencies, the kind that sit two or
Speaker 1: three clicks deep in a canvas app or buried inside
Speaker 1: a model driven apps subflows. As far as DEV is concerned,
Speaker 1: everything looks good, but production, with its own connectors, different
Speaker 1: licensed users, or a subtle difference in data verse security roles,
Speaker 1: finds the weak link immediately. Now people are scramblings. Sometimes
Speaker 1: the only warning you get is a user saying, hey,
Speaker 1: this data isn't updating or support ticket with a stack
Speaker 1: trace that offers nothing helpful the underlying problem. No one
Speaker 1: checked if all the moving pieces actually survived the move.
Speaker 1: This is why dependency checks and pre deployment validations aren't
Speaker 1: just nice to have there your pipeline's immune system. Think
Speaker 1: of them as traveling ahead of your deployment and shining
Speaker 1: a flashlight into all the corners where issues love to hide.
Speaker 1: These automated guardrails catch things like missing child flows, absent
Speaker 1: connection references, or unmanaged components that never got added to
Speaker 1: your export. Without these checks, every deployment is an act
Speaker 1: of faith. You just hope the plumbing underneath your app
Speaker 1: looks the same in each environment, and you only know
Speaker 1: it didn't once the incident report lands in your inbox.
Speaker 2: I've seen this play out more times than I care
Speaker 2: to admit.
Speaker 1: One project had a recurring nightmare, a power automate flow
Speaker 1: that worked beautifully in every dev test, only to completely
Speaker 1: disappear from a production deployment.
Speaker 2: What happened.
Speaker 1: It turned out a quick fix had added a child
Speaker 1: flow as a dependency, and the export process didn't catch
Speaker 1: that the childflow was outside the managed solution. When that
Speaker 1: child flow failed to show up in quay and production,
Speaker 1: the parent logic just silently failed, no error, no warning,
Speaker 1: just a process that silently turned off and users confused
Speaker 1: about why their tasks were suddenly stuck. We only realize
Speaker 1: after enough users called out missing updates that someone finally
Speaker 1: found the missing link. By then, hours had gone into
Speaker 1: combing through export XML files and running manual checks. One
Speaker 1: overlooked dependency caused chaos that could have been flagged with
Speaker 1: the right guardrail in place. The real kicker is how
Speaker 1: preventable this is now. The tools like solution Checker in
Speaker 1: power Platform let you set up automated scans as a
Speaker 1: pipeline step, giving you upfront warnings about issues with solution layering,
Speaker 1: missing dependencies, app performance, and even security recommendations. The power
Speaker 1: platform built tools for Azure DevOps bring this even closer
Speaker 1: to CICD reality. With the right pipeline step, you're doing
Speaker 1: far more than a straightforward import export. You're running validation
Speaker 1: checks against both the solution and its connections to the
Speaker 1: target environment. If you have extra requirements, custom PowerShell scripts
Speaker 1: let you go even deeper, scanning for things like required
Speaker 1: environment variables, validating connections for premium APIs or checking permission
Speaker 1: scopes on AD integrated flows. What's interesting is just how
Speaker 1: much these automated guardrails catch compared to the old exported
Speaker 1: and hope methods. Community studies say these checks flag up
Speaker 1: to seventy percent of the issues before anything goes live.
Speaker 1: That means fewer after hours calls, fewer catch up sprints
Speaker 1: to fix what broke, and way fewer awkward meetings explaining
Speaker 1: to leadership why a golf became a go LIMP. Microsoft's
Speaker 1: own research and case studies back this up. Teams running
Speaker 1: pre deployment validation as a rule see a dramatic drop
Speaker 1: in production breakage and problems get caught so early they
Speaker 1: barely register as incidents. A solid pipeline step for this
Speaker 1: is straightforward but effective. Export your solution from source, but
Speaker 1: before you even consider importing it to the target environment,
Speaker 1: kick off a sequence that runs solution checker and any
Speaker 1: custom tests you've added. Don't just stop at the build.
Speaker 1: Run queries against the production data verse to make sure
Speaker 1: the entities you're about to overwrite don't have schema differences
Speaker 1: that will cause a silent error. Validate connection references don't
Speaker 1: assume everyone who had permissions in dev or QA will
Speaker 1: have the same role in PROD. Having these steps in
Speaker 1: the pipeline means the script fails early if anything's missing,
Speaker 1: and you get useful logs telling you exactly where the
Speaker 1: gap is. These automated checks are the difference between spending
Speaker 1: your day building useful features and spending your evening firefighting
Speaker 1: broken deployments. They don't just keep the environment stable, they
Speaker 1: actually give the entire team confidence that changes moving through
Speaker 1: the pipeline haven't skipped some crucial step or missed a
Speaker 1: last minute dependency. It turns deployment day from something tense
Speaker 1: into something routine. When someone asks did the deployment finish,
Speaker 1: you can actually answer with more than I think so
Speaker 1: because you've got the guardrails to prove it. It's easy
Speaker 1: to dismiss pre deployment checks as another box to, but
Speaker 1: in the power platform world they save more time and
Speaker 1: phase than almost any other automation. Instead of working backwards
Speaker 1: from outages and complaints, you're getting proactive sentinel alerts, early,
Speaker 1: actionable and tied directly to components. Think of them less
Speaker 1: as a safety net and more as a radar system
Speaker 1: of course, even with the best guardrails in place, things
Speaker 1: can still go sideways. Nothing's bulletproof, and every team needs
Speaker 1: a way to back out changes when something slips past.
Speaker 1: So let's get into what a real rollback and backup
Speaker 1: plan looks like for power Platform beyond just hoping the
Speaker 1: undoe button works when things break building a real rollback
Speaker 1: and backup strategy.
Speaker 2: Let's talk about what rollback.
Speaker 1: Really means for power Platform because it's easy to assume
Speaker 1: there's a big undue button waiting to rescue you when
Speaker 1: a deployment melts down. But unlike code projects, where a
Speaker 1: rollback is just a Git reset or a package redeploy,
Speaker 1: the power Platform world is far less forgiving. There is
Speaker 1: no native revert deployment option. Once an import happens, changes
Speaker 1: are baked into the environment. Tables might update, components, shift versions,
Speaker 1: and data relationships can quietly reshuffle themselves. If something fails
Speaker 1: mid import, the result could be half a solution deployed,
Speaker 1: broken integrations, or users locked out of apps they rely on.
Speaker 1: The stakes are rarely obvious until they hit, and by
Speaker 1: then the fix requires finesse. The hard truth is that
Speaker 1: a botched import leaves your environment in a kind of limbo.
Speaker 1: Some components might upgrade, others stay at their old version,
Speaker 1: and connections or roles could be in an undefined state.
Speaker 1: Configurations slip out of sync fast, and you're left with
Speaker 1: a system that doesn't really match what anyone intended.
Speaker 2: What looks like a.
Speaker 1: Minor tweak in a managed solution can knock out entire
Speaker 1: business processes downstream. This is where most admins get caught.
Speaker 1: There's a sense that you can just run it again
Speaker 1: or undo a step, when in practice you're dealing with
Speaker 1: a live application that users count on to do their jobs.
Speaker 1: Now picture the state with a real example. One large
Speaker 1: financial company had a new feature queued up for their
Speaker 1: power Apps portal, some workflow tweaks, a couple of shiny
Speaker 1: new dashboards, and a reconfigured data table. The change zipped
Speaker 1: through QA, so they greenlit the import to production late
Speaker 1: on a Friday, hoping to smooth things over before Monday's
Speaker 1: reporting deadline. The import erroored out halfway through the end result,
Speaker 1: users who logged in Monday morning found broken dashboards, failed automations,
Speaker 1: and a handful of canvas apps that wouldn't load. To
Speaker 1: make matters worse, their last full environment backup was weeks
Speaker 1: old and they hadn't exported the latest solution version after
Speaker 1: last minute dev changes, Restore options were limited, and the
Speaker 1: business lost a full day's worth of work while admins
Speaker 1: pieced the environment back together. No single step caused the disaster.
Speaker 1: It was a missed backup window, a belief in quick fixes,
Speaker 1: and a lack of flexible rollback planning that left them
Speaker 1: exposeds So what can you actually do to avoid ending
Speaker 1: up in rollback limbo? The first and most reliable layer
Speaker 1: is automating solution exports at every stage. Instead of trusting
Speaker 1: that latest version in a dev folder, your pipeline should
Speaker 1: automatically export the solution to a secure location, ideally into
Speaker 1: source Control. That way, every release, whether successful or failed,
Speaker 1: has a corresponding backup. If today's deployment goes south, you
Speaker 1: aren't stuck with whatever happens to be on your desktop.
Speaker 1: You always have access to the last known good package.
Speaker 1: Nightly environment backups are another practical move, even if you
Speaker 1: think you'll never need them. Microsoft does offer full environment
Speaker 1: backup features, especially for data verse environments, but you'd be
Speaker 1: surprised how many teams don't actually automate their use the
Speaker 1: official guidance is clear, always run a complete environment backup
Speaker 1: before touching production, Yet in the field a lot of
Speaker 1: teams rely on we'll do it if we remember. That
Speaker 1: works about as well as you'd expect once until it doesn't.
Speaker 1: Setting up nightly or pre deployment backups means you have
Speaker 1: a full snapshot to restore from if the wheels fall off.
Speaker 1: When paired with solution level exports, you can decide whether
Speaker 1: to re store an entire environment or just roll back
Speaker 1: a single solution, depending on the scale of the issue.
Speaker 1: Version solution files in source control might sound basic, but
Speaker 1: they're a life saver. Tracking every exported zip with commit history,
Speaker 1: branch naming, and pool requests brings power platform deployments closer
Speaker 1: to classic application life cycles. You get a full audit
Speaker 1: trail of what changed, when and by whom. If a
Speaker 1: rollback becomes necessary, you don't need to scramble, just redeploy
Speaker 1: the previous successful build. This isn't just convenient, it's one
Speaker 1: of the most reliable ways to restore business critical changes
Speaker 1: without collateral impact. When it's time to execute a real rollback,
Speaker 1: exported solution files are your lifeline. Start by restoring the
Speaker 1: previous solution version that you already validated in a lower environment.
Speaker 1: Rolling back to that known good state will reset your components, flows,
Speaker 1: and related customizations. You won't get a perfect time machine,
Speaker 1: Records or transactional data modified since the last deployment might
Speaker 1: still be at risk, but you can return the app
Speaker 1: to a working configuration, often.
Speaker 2: Within an app.
Speaker 1: For anything more severe a corrupted entity, lost relationships, or
Speaker 1: data integration issues, you might have to use that environment
Speaker 1: level backup or slice in individual table restores, depending on
Speaker 1: what's available. One lesson learned the hard way. Never assume
Speaker 1: your rollback plan is robust unless you've tested it in
Speaker 1: a sandbox. The difference between a theoretical and a real
Speaker 1: life recovery process is enormous. Without testing, you risk restoring
Speaker 1: incomplete dependencies or hitting import conflicts you didn't anticipate. Practicing
Speaker 1: your rollback isn't just busy work. It's what stands between
Speaker 1: a quick restore and an all day outage. A solid
Speaker 1: backup and rollback plan means deployment failures become a bump
Speaker 1: in the road, not a disaster that burns through your weekend.
Speaker 1: It's the kind of safety net that lets your team
Speaker 1: deploy with confidence and keeps the business running smoothly even
Speaker 1: when the unexpected happens. Now, all these moving parts, connections, guardrails,
Speaker 1: and recoveries feed into one larger question. How do you
Speaker 1: make sure your whole pipeline works together instead of against you.
Speaker 1: The line between a fragile deployment and one you can
Speaker 1: actually rely on never comes down to luck. It's how
Speaker 1: well you wire up each piece. Service connections that don't
Speaker 1: surprise you, agent pools that don't go dark mid build,
Speaker 1: and automated checks that actually do their job. With the
Speaker 1: right structure, you stop holding your breath on every release.
Speaker 1: Issues pop up early, not after the fact, and when
Speaker 1: things break, there's a plan. If you want to keep
Speaker 1: power platform working for your business and avoid late night fixes,
Speaker 1: subscribe and join the conversation.
Speaker 2: The real learning always happens on the next deployment.