Speaker 1: Ever feel like your power Platform deployments are a black box.
Speaker 1: You ship an update, hold your breath, and just hope
Speaker 1: it works across dev, test and prod. What if you
Speaker 1: could actually control and see every stage of your ALM
Speaker 1: process using GitHub actions, with no more guessing or manual patchwork.
Speaker 1: Let's pull back the curtain on how each component, source control,
Speaker 1: automation and secure variables really connects. This isn't just another walkthrough.
Speaker 1: This is the why most guides leave out, so your
Speaker 1: next deployment doesn't leave you guessing. So why power platform
Speaker 1: al feels like a maze. If you've ever tried deploying
Speaker 1: a power app and felt that creeping uncertainty, like something
Speaker 1: important must have slipped through the cracks, You're not alone.
Speaker 1: On paper, power Platform promises easy app development, but behind
Speaker 1: that friendly facade, ALM is anything but straightforward. A web
Speaker 1: app deploys from source control, builds in a pipeline, and
Speaker 1: lands in production with predictable behavior. Power Platform, on the
Speaker 1: other hand, hides half the logic inside drag and drop
Speaker 1: UIs connect screens and formulas you can see in any
Speaker 1: Git repo. So even if you follow every step from
Speaker 1: those high level admin guides, you still run into odd
Speaker 1: hard to diagnose failures once business critical apps leave development.
Speaker 1: Let's look at the ALM guides floating around. Most of
Speaker 1: them will walk you through exporting a solution zip and
Speaker 1: importing it somewhere else. Simple enough, right, But the how
Speaker 1: is just one layer. What they skip is the why?
Speaker 1: Why does power platform deployment break in ways that regular
Speaker 1: code never does. That's what causes endless confusion. The root
Speaker 1: of the problem is that logic, connections and configure in
Speaker 1: power apps aren't stored like classic code. You're not just
Speaker 1: cloning a repo and watching unit tests, So when you
Speaker 1: try to move your app, all those hidden dependencies connections
Speaker 1: to Outlook, share Point, custom APIs don't always travel neatly
Speaker 1: inside that zip file. Here's the scenario. You get a
Speaker 1: shiny new app working in the dev environment, you export
Speaker 1: a solution, import to test, and suddenly have the flows
Speaker 1: stop working. It's rarely just a file problem. Instead, connections
Speaker 1: are point to the wrong place, permissions don't line up,
Speaker 1: and data policies block connections that seemed fine a few
Speaker 1: minutes ago. Now imagine doing this across three environments dev,
Speaker 1: test and PROD, with each one using different connections, data
Speaker 1: protection policies, approvers, and admin guards. You can't copypaste your
Speaker 1: way out of it. The research backs up what admins
Speaker 1: and makers see every week. The majority of failed power
Speaker 1: Platform deployments come from missing connector references or mismanaged environment variables.
Speaker 1: Missing a connector reference just means the flow can't find
Speaker 1: its outlook or data verse connection, So the minute you
Speaker 1: try to run your app or flow in another environment,
Speaker 1: you get runtime errors. And because environment variables work differently
Speaker 1: in power Platform compared to other Microsoft three sixty five products,
Speaker 1: they trip up even experienced developers. Variables are supposed to
Speaker 1: handle endpoints, keys, or tenant specific configs, but if someone
Speaker 1: forgets to update them after exporting a solution, even a
Speaker 1: harmless looking change can break a live app. A lot
Speaker 1: of us fall into the same trap. At first, you
Speaker 1: might think exporting a solution ZIP bundles everything needed, but
Speaker 1: it actually skips over dynamic connector references. For example, say
Speaker 1: you have an app that uses an HTTP connector for
Speaker 1: a third party service in dev. When you import into
Speaker 1: test or, that exact connector instance won't exist. The connector
Speaker 1: reference inside your app points to a missing object and
Speaker 1: flows inside the solution quietly break until a user or
Speaker 1: admin manually recreates and remaps connections. If you have more
Speaker 1: than one maker or admin, it's even easier to lose
Speaker 1: track of which reference goes where, and nobody wants that
Speaker 1: it worked in dev post mortem. Another wrinkle service principles.
Speaker 1: Most folks start out using user accounts to export and
Speaker 1: import solutions because it's faster to get started. But when
Speaker 1: you try to automate with GitHub actions or any CI system,
Speaker 1: using a person's credentials quickly dead ends. You'll hit permission walls,
Speaker 1: sometimes without clear error messages or even trigger compliance audits
Speaker 1: because you're running critical deployments under a personal account instead
Speaker 1: of something meant for automation. Service principles essentially app identities
Speaker 1: created in as you're ad handle all the permissions, logging,
Speaker 1: and auditing your pipeline needs. Without them, your automation chain
Speaker 1: turns into a patchwork of person to person handoffs, and
Speaker 1: you never know who changed what. Source control turns into
Speaker 1: a wildcard too. With regular code, you have commit histories,
Speaker 1: prs and blame tools. Power platform Solution files only represent snapshots,
Speaker 1: which means you're missing granular change tracking logic tucked away
Speaker 1: in a canvas, apps, screen formulas, or in lightly documented
Speaker 1: flows isn't visible until you export against Someone tweaks a
Speaker 1: flow setting in the UI, and good luck finding out
Speaker 1: why downstream environments suddenly behave differently. The end result, managing
Speaker 1: ALM for power Platform feels like solving a puzzle with
Speaker 1: half the pieces missing or at least hidden under the box.
Speaker 1: Invisible dependencies, environment specific connectors, and variables that you can't
Speaker 1: see in code all muddle the usual develop workflow. And
Speaker 1: that's before you deal with the fact that production environments
Speaker 1: almost always have stricter permissions, different data policies, and audit
Speaker 1: requirements that aren't obvious in devor test. But here's the upside.
Speaker 1: This complexity isn't random. There's a practical reason for why
Speaker 1: power Platform handles source variables and connectors in such a
Speaker 1: unique way. It tries to let business users build powerful
Speaker 1: apps without worrying about code. The side effect is you,
Speaker 1: as the person setting up automation, need to track what's
Speaker 1: hiding under the hood. If you know where those invisible
Speaker 1: wires run, you can fix or avoid most of the
Speaker 1: foot guns that derail power Platform ALM. Now, if all
Speaker 1: this sounds like a lot to juggle. You're not wrong,
Speaker 1: but there are four ALM pillars that actually help untangle
Speaker 1: this mess. Source, build, test, and deploy. Each has its
Speaker 1: quirks in power Platform, but together they put structure back
Speaker 1: into what otherwise feels like chaos the core ARM system, Source, build, tests, deploy.
Speaker 1: Every time someone asks for a power Platform pipeline that
Speaker 1: just works, the first thing that comes to mind are
Speaker 1: those four dusty ALM pillars. Source, build, test, deploy. In
Speaker 1: traditional devland, you could almost run these in your sleep.
Speaker 1: Power Platform doesn't let you off that easy. Suddenly. Source
Speaker 1: doesn't mean code. It means wrangling with solution files, exporting
Speaker 1: zipped bundles packed with apps, flows, and sometimes connectors pretending
Speaker 1: to be part of the source. Let's start with the basics,
Speaker 1: then pick apart what makes each pillar a little strange
Speaker 1: in this world. You've got your solution zip file. It's
Speaker 1: not code in the usual sense. Open it up and
Speaker 1: you're greeted with XML and JSON explainer files. Not the
Speaker 1: logic you'd spot in typescript or CI. But this is
Speaker 1: the source for power Platform. Teams often get tripped up here.
Speaker 1: It looks portable until you realize most changes, like updating
Speaker 1: a formula in a screen or tweaking a flow's logic
Speaker 1: aren't obvious until you export a fresh solution zips. So yes,
Speaker 1: you can version these solution files in get, but unless
Speaker 1: you're disciplined about exporting after every relevant edit, your history
Speaker 1: has glaring gaps. Now comes configuration. For regular apps, you
Speaker 1: might store connection strings in a config file and call
Speaker 1: it a day. Power Platform smuggles environment specific data inside
Speaker 1: these solutions. It's not just environment variables, it's connector references,
Speaker 1: dynamic endpoints, rolls, and permissions bundled alongside the business logic.
Speaker 1: If you miss updating these before exporting from dev or test,
Speaker 1: you're locking in pointers to the wrong place. I've watched
Speaker 1: teams religiously commit their solutions zip files, only to deploy
Speaker 1: and realize half their app is still talking to the
Speaker 1: dev data verse instead of PROD because nobody remapped connector references.
Speaker 1: Then we have built. The word build usually brings up
Speaker 1: images of compiling code and watching green ticks. In a
Speaker 1: CI job with power Platform, the build processes about stashing
Speaker 1: those ZIP bundles, double checking schema, and verifying dependencies In
Speaker 1: a GitHub actions pipeline, a bill job grabs committed solution
Speaker 1: file then uses Microsoft's power Platform CLI to unpack, validate,
Speaker 1: and repack the solution. The validation step is where the
Speaker 1: magic or chaos happens. It might catch broken references or
Speaker 1: unsupported actions, whereas if a change in your flow relies
Speaker 1: on a custom connector that never made it into source control,
Speaker 1: your build silently packages something incomplete. Here's where things get tricky.
Speaker 1: Those build jobs are less about compiling and more about
Speaker 1: orchestrating a reliable export and making sure what's inside is shippable.
Speaker 1: Teams who skip this or rush it quickly land in
Speaker 1: situations where a build technically succeeds, but what ends up
Speaker 1: in UAT or PROD is missing half its intended features.
Speaker 1: Microsoft keeps pushing the message that solution files make ALM portable,
Speaker 1: but there's always a footnote. Portability depends on connectors being
Speaker 1: properly mapped and rolls set up across environments. Testing is
Speaker 1: the next source spot in a web app pipeline. Automated
Speaker 1: tests might run unit tests or UI checks. For power Platform.
Speaker 1: What counts as a test is for debate. Sometimes it's
Speaker 1: solution validation. In other words, does the solution open and
Speaker 1: do key dependencies resolve? Other times, it's running test flows
Speaker 1: or checking that connectors respond in a test environment. A
Speaker 1: lot of times testing is manual because validating business logic
Speaker 1: inside a canvas app isn't wired into automated pipelines yet.
Speaker 1: But you can automate checks to spot missing connectors, validate
Speaker 1: critical flows, or even paying a test environment just to
Speaker 1: prove credentials are working. Deployment drives the pain home. When
Speaker 1: a standard app deploys, you might just push a web
Speaker 1: artifact onto Azure. With power platform, you have to map connections,
Speaker 1: assign permissions, update secrets, swap environment variables, and finally trigger
Speaker 1: and import using a service principle, never a regular account.
Speaker 1: Otherwise you're stuck with audits and permission denials. GitHub actions
Speaker 1: can tie this process together, but only if each job
Speaker 1: knows which environment to target and which secrets to use.
Speaker 1: I've seen teams try to shortcut this by using a
Speaker 1: single set of credentials across dev and PROD, which is
Speaker 1: a recipe for chaos, data leaks, permission errors, and broken
Speaker 1: features that only show up in one environment. Take a
Speaker 1: real world team I worked with a few months back.
Speaker 1: They did most things right standard Git repos, version solution, zips,
Speaker 1: and clear branching, but their pipeline always broke at deployment.
Speaker 1: Why they never bothered to swap environment variables or update
Speaker 1: connector references before importing into PROD That left key flows
Speaker 1: pointing to the wrong end points with data trickling into
Speaker 1: the wrong systems. The fix scripted steps in their GitHub
Speaker 1: pipeline that swapped variables and remapped every connector on import.
Speaker 1: Microsoft's own guidance is blunt about this. Use solution files
Speaker 1: for moving things between environments, but always handle connector references
Speaker 1: and role mapping as part of your pipeline. They point
Speaker 1: out that skipping these steps is the number one way
Speaker 1: to break apps, especially as environments get more locked down.
Speaker 1: Once you treat source, build, test, and deploy as connected
Speaker 1: moving parts, not just isolated steps, it's easier to see
Speaker 1: why so many ALM attempts fall over and how you
Speaker 1: can actually troubleshoot issues instead of crossing your fingers. Next,
Speaker 1: let's get into how GitHub Actions coordinates this dance triggers,
Speaker 1: branching and job separation that keep your power platform automation
Speaker 1: both flexible and secure. GitHub Actions connecting the dots with
Speaker 1: triggers and jobs. If you've waited for a GitHub Actions
Speaker 1: pipeline to finish after updating your power AUP. You already
Speaker 1: know automation doesn't mean instant, and it definitely doesn't mean magic.
Speaker 1: Most teams hit that wall right after the excitement of
Speaker 1: seeing their first workflow run. You set up a script,
Speaker 1: wire it into your repository, and expect every new commit
Speaker 1: to roll out cleanly across all environments. Then reality checks in.
Speaker 1: Instead of just kicking off a script, GitHub Actions uses
Speaker 1: a logic chain built around triggers, jobs, and handoffs between environments.
Speaker 1: That order and structure is what keeps deployments from becoming
Speaker 1: a tangle of failed steps and strange errors. The starting
Speaker 1: point in this system is the trigger. Most first timers
Speaker 1: create a workflow that fires on every push or or
Speaker 1: whenever a pool request lands in the main branch. On
Speaker 1: the surface, that looks like best practice. Why not run
Speaker 1: your pipeline every time work changes? Here's the catch. When
Speaker 1: you only set a trigger on Maine, everything gets funneled
Speaker 1: through a single track. What if changes need to hit
Speaker 1: dev but not test or PROD. What if you're ready
Speaker 1: to push to PRAD but test is still running Validation
Speaker 1: Teams that stick to one size fits all triggers tend
Speaker 1: to run into problems where features meant for development environments
Speaker 1: sneak into production or test deployments suddenly overwrite PROD settings.
Speaker 1: You can branch workflows for each environment, dev, test, and
Speaker 1: PROD and set up very specific triggers for each. For example,
Speaker 1: set up a workflow that only runs on pushes to
Speaker 1: a dev branch, or fire a different workflow when someone
Speaker 1: merges into release PROD. And This approach gives more control
Speaker 1: and creates a clear fence between work in progress and
Speaker 1: life changes. But a lot of teams never revisit their
Speaker 1: triggers after creating them. That's how secrets from one environment
Speaker 1: can slip into another and configument for dev ends up
Speaker 1: in PROD by accident. One team I worked with tried
Speaker 1: to run their entire ALM process from a single workflow.
Speaker 1: For a while. It seemed fine until someone noticed that
Speaker 1: a production database connection string showed up in the dev environment.
Speaker 1: They didn't realize their secrets were being shared between jobs,
Speaker 1: and one's code moved between environments, those secrets leaked with it.
Speaker 1: It wasn't an obvious crash or error, it was silent.
Speaker 1: This kind of data spill is more common than you'd think,
Speaker 1: especially if you don't set up your workflows to separate
Speaker 1: secrets and environment variables. Each job in a GitHub Actions
Speaker 1: workflow handles a clear piece of the process. One job
Speaker 1: might handle exporting the solution from a source environment that
Speaker 1: Another job takes care of validation, unpacking, scanning through solution metadata,
Speaker 1: checking all the dependencies, and making sure connector references exist.
Speaker 1: Next comes the job that prepares the environment specific variables,
Speaker 1: translating the solution so it fits its target environment. The
Speaker 1: last job triggers the import process, using service principles to
Speaker 1: write changes into the right environment. You might think of
Speaker 1: environment variables and secrets as basic placeholders, but in practice
Speaker 1: they're the glue holding everything together. Connection strings, API keys,
Speaker 1: shared passwords. They all need to be swapped between jobs,
Speaker 1: but they can never leak across boundaries. In power platform ALM,
Speaker 1: you may have a different data verse connection for each environment,
Speaker 1: or need to swap end points depending on which flow
Speaker 1: or power app you're targeting. If you reuse variables or
Speaker 1: hard code secrets, you end up with either a brittle
Speaker 1: pipeline or worse, significant security risks. The import process depends
Speaker 1: on pulling secrets only from the right vault, so production
Speaker 1: isn't exposed by test or dev mishaps. A good mental
Speaker 1: model for secrets in GitHub actions is to picture each
Speaker 1: environment as having its own digital vault, a locked box
Speaker 1: only the right jobs can see. GitHub gives you precise controls.
Speaker 1: You can scope secrets to environments, so a job running
Speaker 1: in dev can't access credentials and vice versa. Set up
Speaker 1: these vaults, and even if someone tweaking the pipe tries
Speaker 1: something risky, environment protection rules prevent a misstep from crossing over.
Speaker 1: Microsoft's and GitHub's own documentation. Both hammer this point. They
Speaker 1: recommend environment protection rules and strict secret scoping to stop
Speaker 1: cross environment leaks before they even start. Without that kind
Speaker 1: of protection, even the best designed ALM workflows fall apart.
Speaker 1: Imagine a workflow deploying to PROD while still holding onto
Speaker 1: a DEV connection string or a test environment suddenly with
Speaker 1: access to PROD data. It doesn't always break things visibly.
Speaker 1: Sometimes it just means compliance flags go off or logs
Speaker 1: fill up with subtle errors that slowly pile into bigger problems.
Speaker 1: This is why branching workflows and scoping secrets aren't just
Speaker 1: advanced topics. They're the safety net that keeps your automation
Speaker 1: from quietly unraveling. There's also value in splitting workflows not
Speaker 1: just by environment, but by responsibility. Code that exports and
Speaker 1: validates solutions shouldn't even know how to deploy or swap secrets.
Speaker 1: If every job handles one piece of the puzzle, it
Speaker 1: becomes much easier to spot where things break, roll back
Speaker 1: and audit changes after the fact secrets stay in their vaults,
Speaker 1: jobs follow clearly scoped permissions, and pipeline failures point straight
Speaker 1: to the piece that needs fixing. Understanding how GitHub actions
Speaker 1: hands off work from one job to another while keeping
Speaker 1: secrets tightly scoped and triggers clearly defined is what takes
Speaker 1: alm from a hopeful experiment to a reliable, secure, and
Speaker 1: predictable practice. This workflow segmentation isn't just about matching best practices.
Speaker 1: It's what blocks quiet security leaks and accidental overrides, and
Speaker 1: it cuts off a whole class of invisible errors before
Speaker 1: they start to haunt your environments. Now, with the pieces
Speaker 1: working together through properly scoped automation, it's time we tackle
Speaker 1: another friction point, connectors, service principles and the small but
Speaker 1: critical pitfalls that can stall your deployments right as you
Speaker 1: get confident, secret service principles and the trouble with connectors.
Speaker 1: If you've ever tried moving a power app or flow
Speaker 1: from dev to praud, you know the story. Things work
Speaker 1: flawlessly in one environment, then as soon as you switch over,
Speaker 1: everything grinds to a halt or gives you those mysterious
Speaker 1: connection errors. It isn't unique to a specific team. Every
Speaker 1: power Platform admin eventually runs into this wall. The root
Speaker 1: of the problem lies in how connectors and secrets behave
Speaker 1: behind the scenes. You can't just export a solution zip
Speaker 1: from development and expect it to work somewhere else because
Speaker 1: the wires it depends on change with every environment. Take
Speaker 1: connector references for starters. In Power Platform, a connector is
Speaker 1: never just a static bit of information bundled into your app.
Speaker 1: It's dynamic, mutable, and often unique per environment. When you
Speaker 1: export your solution, connector references act almost like bookmarks. They
Speaker 1: point to connection objects that only exist in the environment
Speaker 1: they were built in. So when you import into test
Speaker 1: or PROD, your fancy HTTP endpoint or data verse link
Speaker 1: doesn't necessarily get recreated the same way or at all.
Speaker 1: This is where teams get caught out. If DEV is
Speaker 1: using a connector to data and that exact configuration isn't
Speaker 1: mirrored in PROD, your flow or app either fails silently
Speaker 1: or hangs on the first attempt to connect. A lot
Speaker 1: of folks try to get around this by sharing user
Speaker 1: credentials across environments. They figure if you use the same
Speaker 1: account or password that created the connection in DEV, maybe
Speaker 1: it'll just work in PROD. The reality is this invites
Speaker 1: a host of problems, everything from permission denials to compliance
Speaker 1: audit triggers. Microsoft's own guidance is clear using individual user
Speaker 1: credentials for automated deployments just isn't viable or secure. It
Speaker 1: puts your automation at the mercy of password resets and
Speaker 1: can leave a muddy trail in your audit logs. There's
Speaker 1: no clear accountability, and eventually permissions block the pipeline when
Speaker 1: the original user is flagged, removed, or loses access. Enter
Speaker 1: service principles if you haven't worked with them. Picture a
Speaker 1: service principle as a digital extra set of hands, purpose
Speaker 1: built for automation. Unlike a regular user, a service principle
Speaker 1: is tied to an app registration in as You're ad
Speaker 1: not a real person. You give it the minimum permissions
Speaker 1: needed to run your deployment tasks. That sounds simple, but
Speaker 1: the payoff is big. Instead of relying on a user
Speaker 1: who could leave the organization or change roles, deployments stay consistent, auditable,
Speaker 1: and traceable. Every environment gets access only to the right
Speaker 1: connections and resources, and any changes are logged under this
Speaker 1: robot account. When something fails, you have a clean audit
Speaker 1: trail and you don't end up with orphaned flows. Nobody
Speaker 1: can fix on the problem of mapping connectors. Consider what
Speaker 1: happens when environments drift apart. Maybe the dev team got
Speaker 1: approval for a new custom connector. Let's say it hits
Speaker 1: a sandbox API. When it comes time to move to PROD,
Speaker 1: that connector isn't just missing, it may not even be
Speaker 1: allowed by organizational data policies. If you forget to remap,
Speaker 1: the app calls out to the wrong endpoint or breaks entirely.
Speaker 1: I saw this landhard at a healthcare group recently. One
Speaker 1: missed connector mapping triggered the use of test data in
Speaker 1: production and near created a compliance incident. There. Automated pipeline
Speaker 1: exported everything as planned, but the connector reference inside the
Speaker 1: solution still pointed back to an old test database that
Speaker 1: wasn't flagged by power platform until real data started flowing
Speaker 1: through the wrong pipes. Environment variables step in to ease
Speaker 1: some of this pain. Unlike hard coding endpoints or apikeys,
Speaker 1: environment variables let you separate what changes across environments from
Speaker 1: what stays the same. You can swap out endpoints, apikeys,
Speaker 1: or other secrets with each deployment without rewriting your app
Speaker 1: or flow. For example, a flow that works with a
Speaker 1: dev data verse table can be reconfigured on import to
Speaker 1: use the prod table simply by changing the environment variable
Speaker 1: inside your deployment process. GitHub actions pipelines make this practical.
Speaker 1: Each job can inject the right value at the right time,
Speaker 1: but even here discipline is key. Forget to update a
Speaker 1: variable or let secrets leak across environments and suddenly your
Speaker 1: workflow is exposed. Microsoft emphasizes the need to scope secrets
Speaker 1: carefully and map connector references intentionally. Their DLP data loss
Speaker 1: prevention policies exist for a reason, to keep sensitive information
Speaker 1: from wandering between environments or surfacing in the wrong place.
Speaker 1: If you try to bypass these by sharing variables or connections.
Speaker 1: You'll trip over corporate security or compliance controls. More importantly,
Speaker 1: you lose predictability because there's no longer a line between
Speaker 1: what's meant for DEV versus test or PROD. The benefit
Speaker 1: when you get all of this right is hard to overstate.
Speaker 1: Service principles combined with well managed environment, variables and properly
Speaker 1: mapped connectors transform your pipeline. Your deployments become predictable. When
Speaker 1: things break, you have a clear chain of custody and
Speaker 1: know exactly where to look. Was it a connector, mapping
Speaker 1: a variable or a missed permission. Auditors can follow changes,
Speaker 1: and there's no suspense when someone leaves the organization or
Speaker 1: changes passwords. It all comes down to handling secrets, connectors,
Speaker 1: and service principles like they matter because in power platform
Speaker 1: ALM they do. Misstep and hours of manual patching follow.
Speaker 1: Get them right, and your pipeline finally works the way
Speaker 1: it should, resilient, secure, and transparent. When things do go wrong,
Speaker 1: the troubleshooting process doesn't start from square one. You already
Speaker 1: have the evidence of what moved, who moved it, and how,
Speaker 1: and that brings us to the last piece, what to
Speaker 1: do when ALM still throws a wrench in the works
Speaker 1: and how to unstick even the most tangled deployments. If
Speaker 1: you've built power platform solutions for a while, you know
Speaker 1: ALM isn't just about copying files and hoping for the best.
Speaker 1: Each piece the solution, files, connectors, service principles, and environment
Speaker 1: variables serves a real purpose, and understanding how they interact
Speaker 1: is what lets you avoid costly surprises down the line
Speaker 1: when Microsoft moves the goalposts or another connector changes. The
Speaker 1: teams that adapt the fastest are the ones who actually
Speaker 1: know why each step matters and don't just tick boxes.
Speaker 1: Want to share something that broke spectacularly or quietly in
Speaker 1: your deployment, Drop it below and we'll dig into it together.