WEBVTT

1
00:00:00.080 --> 00:00:03.000
<v Speaker 1>Ever feel like your power Platform deployments are a black box.

2
00:00:03.160 --> 00:00:05.759
<v Speaker 1>You ship an update, hold your breath, and just hope

3
00:00:05.799 --> 00:00:08.599
<v Speaker 1>it works across dev, test and prod. What if you

4
00:00:08.599 --> 00:00:12.160
<v Speaker 1>could actually control and see every stage of your ALM

5
00:00:12.240 --> 00:00:16.000
<v Speaker 1>process using GitHub actions, with no more guessing or manual patchwork.

6
00:00:16.239 --> 00:00:20.199
<v Speaker 1>Let's pull back the curtain on how each component, source control,

7
00:00:20.320 --> 00:00:25.000
<v Speaker 1>automation and secure variables really connects. This isn't just another walkthrough.

8
00:00:25.160 --> 00:00:27.839
<v Speaker 1>This is the why most guides leave out, so your

9
00:00:27.960 --> 00:00:31.399
<v Speaker 1>next deployment doesn't leave you guessing. So why power platform

10
00:00:31.399 --> 00:00:34.439
<v Speaker 1>al feels like a maze. If you've ever tried deploying

11
00:00:34.479 --> 00:00:37.640
<v Speaker 1>a power app and felt that creeping uncertainty, like something

12
00:00:37.679 --> 00:00:40.600
<v Speaker 1>important must have slipped through the cracks, You're not alone.

13
00:00:40.920 --> 00:00:45.079
<v Speaker 1>On paper, power Platform promises easy app development, but behind

14
00:00:45.079 --> 00:00:48.359
<v Speaker 1>that friendly facade, ALM is anything but straightforward. A web

15
00:00:48.399 --> 00:00:51.920
<v Speaker 1>app deploys from source control, builds in a pipeline, and

16
00:00:52.000 --> 00:00:55.719
<v Speaker 1>lands in production with predictable behavior. Power Platform, on the

17
00:00:55.719 --> 00:00:58.960
<v Speaker 1>other hand, hides half the logic inside drag and drop

18
00:00:59.079 --> 00:01:02.079
<v Speaker 1>UIs connect screens and formulas you can see in any

19
00:01:02.079 --> 00:01:05.120
<v Speaker 1>Git repo. So even if you follow every step from

20
00:01:05.159 --> 00:01:07.959
<v Speaker 1>those high level admin guides, you still run into odd

21
00:01:08.079 --> 00:01:12.079
<v Speaker 1>hard to diagnose failures once business critical apps leave development.

22
00:01:12.200 --> 00:01:14.879
<v Speaker 1>Let's look at the ALM guides floating around. Most of

23
00:01:14.959 --> 00:01:17.599
<v Speaker 1>them will walk you through exporting a solution zip and

24
00:01:17.680 --> 00:01:20.879
<v Speaker 1>importing it somewhere else. Simple enough, right, But the how

25
00:01:21.000 --> 00:01:23.640
<v Speaker 1>is just one layer. What they skip is the why?

26
00:01:24.439 --> 00:01:27.680
<v Speaker 1>Why does power platform deployment break in ways that regular

27
00:01:27.719 --> 00:01:30.879
<v Speaker 1>code never does. That's what causes endless confusion. The root

28
00:01:30.920 --> 00:01:34.040
<v Speaker 1>of the problem is that logic, connections and configure in

29
00:01:34.120 --> 00:01:37.560
<v Speaker 1>power apps aren't stored like classic code. You're not just

30
00:01:37.640 --> 00:01:40.719
<v Speaker 1>cloning a repo and watching unit tests, So when you

31
00:01:40.760 --> 00:01:43.799
<v Speaker 1>try to move your app, all those hidden dependencies connections

32
00:01:43.799 --> 00:01:47.840
<v Speaker 1>to Outlook, share Point, custom APIs don't always travel neatly

33
00:01:47.959 --> 00:01:50.799
<v Speaker 1>inside that zip file. Here's the scenario. You get a

34
00:01:50.799 --> 00:01:53.400
<v Speaker 1>shiny new app working in the dev environment, you export

35
00:01:53.439 --> 00:01:56.040
<v Speaker 1>a solution, import to test, and suddenly have the flows

36
00:01:56.079 --> 00:01:59.560
<v Speaker 1>stop working. It's rarely just a file problem. Instead, connections

37
00:01:59.599 --> 00:02:02.480
<v Speaker 1>are point to the wrong place, permissions don't line up,

38
00:02:02.519 --> 00:02:05.799
<v Speaker 1>and data policies block connections that seemed fine a few

39
00:02:05.799 --> 00:02:09.680
<v Speaker 1>minutes ago. Now imagine doing this across three environments dev,

40
00:02:09.879 --> 00:02:14.240
<v Speaker 1>test and PROD, with each one using different connections, data

41
00:02:14.280 --> 00:02:17.759
<v Speaker 1>protection policies, approvers, and admin guards. You can't copypaste your

42
00:02:17.800 --> 00:02:20.400
<v Speaker 1>way out of it. The research backs up what admins

43
00:02:20.400 --> 00:02:23.719
<v Speaker 1>and makers see every week. The majority of failed power

44
00:02:23.759 --> 00:02:28.680
<v Speaker 1>Platform deployments come from missing connector references or mismanaged environment variables.

45
00:02:29.240 --> 00:02:32.800
<v Speaker 1>Missing a connector reference just means the flow can't find

46
00:02:33.000 --> 00:02:35.719
<v Speaker 1>its outlook or data verse connection, So the minute you

47
00:02:35.800 --> 00:02:39.520
<v Speaker 1>try to run your app or flow in another environment,

48
00:02:39.680 --> 00:02:44.439
<v Speaker 1>you get runtime errors. And because environment variables work differently

49
00:02:44.479 --> 00:02:48.080
<v Speaker 1>in power Platform compared to other Microsoft three sixty five products,

50
00:02:48.240 --> 00:02:51.479
<v Speaker 1>they trip up even experienced developers. Variables are supposed to

51
00:02:51.520 --> 00:02:55.479
<v Speaker 1>handle endpoints, keys, or tenant specific configs, but if someone

52
00:02:55.520 --> 00:02:58.759
<v Speaker 1>forgets to update them after exporting a solution, even a

53
00:02:58.800 --> 00:03:01.719
<v Speaker 1>harmless looking change can break a live app. A lot

54
00:03:01.719 --> 00:03:04.080
<v Speaker 1>of us fall into the same trap. At first, you

55
00:03:04.159 --> 00:03:06.919
<v Speaker 1>might think exporting a solution ZIP bundles everything needed, but

56
00:03:07.000 --> 00:03:10.400
<v Speaker 1>it actually skips over dynamic connector references. For example, say

57
00:03:10.400 --> 00:03:12.719
<v Speaker 1>you have an app that uses an HTTP connector for

58
00:03:12.800 --> 00:03:15.560
<v Speaker 1>a third party service in dev. When you import into

59
00:03:15.560 --> 00:03:19.120
<v Speaker 1>test or, that exact connector instance won't exist. The connector

60
00:03:19.159 --> 00:03:22.319
<v Speaker 1>reference inside your app points to a missing object and

61
00:03:22.400 --> 00:03:26.159
<v Speaker 1>flows inside the solution quietly break until a user or

62
00:03:26.199 --> 00:03:30.360
<v Speaker 1>admin manually recreates and remaps connections. If you have more

63
00:03:30.400 --> 00:03:33.919
<v Speaker 1>than one maker or admin, it's even easier to lose

64
00:03:33.960 --> 00:03:36.800
<v Speaker 1>track of which reference goes where, and nobody wants that

65
00:03:36.919 --> 00:03:41.719
<v Speaker 1>it worked in dev post mortem. Another wrinkle service principles.

66
00:03:42.360 --> 00:03:45.400
<v Speaker 1>Most folks start out using user accounts to export and

67
00:03:45.479 --> 00:03:48.919
<v Speaker 1>import solutions because it's faster to get started. But when

68
00:03:48.960 --> 00:03:52.080
<v Speaker 1>you try to automate with GitHub actions or any CI system,

69
00:03:52.159 --> 00:03:55.840
<v Speaker 1>using a person's credentials quickly dead ends. You'll hit permission walls,

70
00:03:55.879 --> 00:03:59.479
<v Speaker 1>sometimes without clear error messages or even trigger compliance audits

71
00:03:59.599 --> 00:04:03.159
<v Speaker 1>because you're running critical deployments under a personal account instead

72
00:04:03.199 --> 00:04:08.120
<v Speaker 1>of something meant for automation. Service principles essentially app identities

73
00:04:08.199 --> 00:04:11.759
<v Speaker 1>created in as you're ad handle all the permissions, logging,

74
00:04:11.840 --> 00:04:15.879
<v Speaker 1>and auditing your pipeline needs. Without them, your automation chain

75
00:04:15.919 --> 00:04:18.759
<v Speaker 1>turns into a patchwork of person to person handoffs, and

76
00:04:18.800 --> 00:04:21.639
<v Speaker 1>you never know who changed what. Source control turns into

77
00:04:21.639 --> 00:04:25.079
<v Speaker 1>a wildcard too. With regular code, you have commit histories,

78
00:04:25.120 --> 00:04:29.519
<v Speaker 1>prs and blame tools. Power platform Solution files only represent snapshots,

79
00:04:29.519 --> 00:04:33.120
<v Speaker 1>which means you're missing granular change tracking logic tucked away

80
00:04:33.120 --> 00:04:36.720
<v Speaker 1>in a canvas, apps, screen formulas, or in lightly documented

81
00:04:36.759 --> 00:04:39.759
<v Speaker 1>flows isn't visible until you export against Someone tweaks a

82
00:04:39.800 --> 00:04:42.000
<v Speaker 1>flow setting in the UI, and good luck finding out

83
00:04:42.000 --> 00:04:45.839
<v Speaker 1>why downstream environments suddenly behave differently. The end result, managing

84
00:04:45.879 --> 00:04:48.800
<v Speaker 1>ALM for power Platform feels like solving a puzzle with

85
00:04:48.879 --> 00:04:52.000
<v Speaker 1>half the pieces missing or at least hidden under the box.

86
00:04:52.120 --> 00:04:57.240
<v Speaker 1>Invisible dependencies, environment specific connectors, and variables that you can't

87
00:04:57.240 --> 00:05:01.120
<v Speaker 1>see in code all muddle the usual develop workflow. And

88
00:05:01.160 --> 00:05:04.240
<v Speaker 1>that's before you deal with the fact that production environments

89
00:05:04.279 --> 00:05:08.600
<v Speaker 1>almost always have stricter permissions, different data policies, and audit

90
00:05:08.639 --> 00:05:13.079
<v Speaker 1>requirements that aren't obvious in devor test. But here's the upside.

91
00:05:13.199 --> 00:05:16.480
<v Speaker 1>This complexity isn't random. There's a practical reason for why

92
00:05:16.519 --> 00:05:21.319
<v Speaker 1>power Platform handles source variables and connectors in such a

93
00:05:21.439 --> 00:05:24.879
<v Speaker 1>unique way. It tries to let business users build powerful

94
00:05:24.879 --> 00:05:28.839
<v Speaker 1>apps without worrying about code. The side effect is you,

95
00:05:29.160 --> 00:05:32.319
<v Speaker 1>as the person setting up automation, need to track what's

96
00:05:32.360 --> 00:05:35.240
<v Speaker 1>hiding under the hood. If you know where those invisible

97
00:05:35.240 --> 00:05:38.720
<v Speaker 1>wires run, you can fix or avoid most of the

98
00:05:38.759 --> 00:05:42.439
<v Speaker 1>foot guns that derail power Platform ALM. Now, if all

99
00:05:42.480 --> 00:05:44.839
<v Speaker 1>this sounds like a lot to juggle. You're not wrong,

100
00:05:45.000 --> 00:05:48.000
<v Speaker 1>but there are four ALM pillars that actually help untangle

101
00:05:48.040 --> 00:05:51.240
<v Speaker 1>this mess. Source, build, test, and deploy. Each has its

102
00:05:51.319 --> 00:05:54.399
<v Speaker 1>quirks in power Platform, but together they put structure back

103
00:05:54.439 --> 00:05:59.879
<v Speaker 1>into what otherwise feels like chaos the core ARM system, Source, build, tests, deploy.

104
00:06:00.279 --> 00:06:03.399
<v Speaker 1>Every time someone asks for a power Platform pipeline that

105
00:06:03.600 --> 00:06:06.040
<v Speaker 1>just works, the first thing that comes to mind are

106
00:06:06.079 --> 00:06:10.759
<v Speaker 1>those four dusty ALM pillars. Source, build, test, deploy. In

107
00:06:10.800 --> 00:06:13.639
<v Speaker 1>traditional devland, you could almost run these in your sleep.

108
00:06:13.720 --> 00:06:17.439
<v Speaker 1>Power Platform doesn't let you off that easy. Suddenly. Source

109
00:06:17.480 --> 00:06:21.720
<v Speaker 1>doesn't mean code. It means wrangling with solution files, exporting

110
00:06:21.839 --> 00:06:26.639
<v Speaker 1>zipped bundles packed with apps, flows, and sometimes connectors pretending

111
00:06:26.680 --> 00:06:29.720
<v Speaker 1>to be part of the source. Let's start with the basics,

112
00:06:29.959 --> 00:06:32.439
<v Speaker 1>then pick apart what makes each pillar a little strange

113
00:06:32.439 --> 00:06:35.199
<v Speaker 1>in this world. You've got your solution zip file. It's

114
00:06:35.240 --> 00:06:37.160
<v Speaker 1>not code in the usual sense. Open it up and

115
00:06:37.199 --> 00:06:40.680
<v Speaker 1>you're greeted with XML and JSON explainer files. Not the

116
00:06:40.680 --> 00:06:44.040
<v Speaker 1>logic you'd spot in typescript or CI. But this is

117
00:06:44.120 --> 00:06:47.279
<v Speaker 1>the source for power Platform. Teams often get tripped up here.

118
00:06:47.480 --> 00:06:51.360
<v Speaker 1>It looks portable until you realize most changes, like updating

119
00:06:51.360 --> 00:06:54.000
<v Speaker 1>a formula in a screen or tweaking a flow's logic

120
00:06:54.079 --> 00:06:57.519
<v Speaker 1>aren't obvious until you export a fresh solution zips. So yes,

121
00:06:57.560 --> 00:07:00.439
<v Speaker 1>you can version these solution files in get, but unless

122
00:07:00.439 --> 00:07:04.120
<v Speaker 1>you're disciplined about exporting after every relevant edit, your history

123
00:07:04.160 --> 00:07:08.160
<v Speaker 1>has glaring gaps. Now comes configuration. For regular apps, you

124
00:07:08.240 --> 00:07:11.319
<v Speaker 1>might store connection strings in a config file and call

125
00:07:11.319 --> 00:07:14.879
<v Speaker 1>it a day. Power Platform smuggles environment specific data inside

126
00:07:14.879 --> 00:07:19.639
<v Speaker 1>these solutions. It's not just environment variables, it's connector references,

127
00:07:19.720 --> 00:07:23.959
<v Speaker 1>dynamic endpoints, rolls, and permissions bundled alongside the business logic.

128
00:07:24.439 --> 00:07:28.759
<v Speaker 1>If you miss updating these before exporting from dev or test,

129
00:07:29.160 --> 00:07:31.639
<v Speaker 1>you're locking in pointers to the wrong place. I've watched

130
00:07:31.639 --> 00:07:35.879
<v Speaker 1>teams religiously commit their solutions zip files, only to deploy

131
00:07:36.000 --> 00:07:38.360
<v Speaker 1>and realize half their app is still talking to the

132
00:07:38.439 --> 00:07:42.560
<v Speaker 1>dev data verse instead of PROD because nobody remapped connector references.

133
00:07:43.079 --> 00:07:46.639
<v Speaker 1>Then we have built. The word build usually brings up

134
00:07:46.639 --> 00:07:49.600
<v Speaker 1>images of compiling code and watching green ticks. In a

135
00:07:49.639 --> 00:07:53.279
<v Speaker 1>CI job with power Platform, the build processes about stashing

136
00:07:53.360 --> 00:07:57.399
<v Speaker 1>those ZIP bundles, double checking schema, and verifying dependencies In

137
00:07:57.439 --> 00:08:00.879
<v Speaker 1>a GitHub actions pipeline, a bill job grabs committed solution

138
00:08:01.040 --> 00:08:05.399
<v Speaker 1>file then uses Microsoft's power Platform CLI to unpack, validate,

139
00:08:05.439 --> 00:08:08.240
<v Speaker 1>and repack the solution. The validation step is where the

140
00:08:08.240 --> 00:08:11.199
<v Speaker 1>magic or chaos happens. It might catch broken references or

141
00:08:11.279 --> 00:08:15.040
<v Speaker 1>unsupported actions, whereas if a change in your flow relies

142
00:08:15.079 --> 00:08:18.000
<v Speaker 1>on a custom connector that never made it into source control,

143
00:08:18.360 --> 00:08:22.519
<v Speaker 1>your build silently packages something incomplete. Here's where things get tricky.

144
00:08:22.920 --> 00:08:26.000
<v Speaker 1>Those build jobs are less about compiling and more about

145
00:08:26.160 --> 00:08:30.480
<v Speaker 1>orchestrating a reliable export and making sure what's inside is shippable.

146
00:08:30.959 --> 00:08:33.200
<v Speaker 1>Teams who skip this or rush it quickly land in

147
00:08:33.240 --> 00:08:36.600
<v Speaker 1>situations where a build technically succeeds, but what ends up

148
00:08:36.639 --> 00:08:39.399
<v Speaker 1>in UAT or PROD is missing half its intended features.

149
00:08:39.759 --> 00:08:43.440
<v Speaker 1>Microsoft keeps pushing the message that solution files make ALM portable,

150
00:08:43.840 --> 00:08:47.039
<v Speaker 1>but there's always a footnote. Portability depends on connectors being

151
00:08:47.039 --> 00:08:50.559
<v Speaker 1>properly mapped and rolls set up across environments. Testing is

152
00:08:50.559 --> 00:08:53.559
<v Speaker 1>the next source spot in a web app pipeline. Automated

153
00:08:53.559 --> 00:08:58.039
<v Speaker 1>tests might run unit tests or UI checks. For power Platform.

154
00:08:58.080 --> 00:09:01.519
<v Speaker 1>What counts as a test is for debate. Sometimes it's

155
00:09:01.559 --> 00:09:05.240
<v Speaker 1>solution validation. In other words, does the solution open and

156
00:09:05.360 --> 00:09:09.240
<v Speaker 1>do key dependencies resolve? Other times, it's running test flows

157
00:09:09.399 --> 00:09:13.279
<v Speaker 1>or checking that connectors respond in a test environment. A

158
00:09:13.279 --> 00:09:16.360
<v Speaker 1>lot of times testing is manual because validating business logic

159
00:09:16.399 --> 00:09:19.879
<v Speaker 1>inside a canvas app isn't wired into automated pipelines yet.

160
00:09:20.159 --> 00:09:24.399
<v Speaker 1>But you can automate checks to spot missing connectors, validate

161
00:09:24.399 --> 00:09:27.120
<v Speaker 1>critical flows, or even paying a test environment just to

162
00:09:27.120 --> 00:09:30.600
<v Speaker 1>prove credentials are working. Deployment drives the pain home. When

163
00:09:30.639 --> 00:09:32.919
<v Speaker 1>a standard app deploys, you might just push a web

164
00:09:33.000 --> 00:09:36.519
<v Speaker 1>artifact onto Azure. With power platform, you have to map connections,

165
00:09:36.559 --> 00:09:41.159
<v Speaker 1>assign permissions, update secrets, swap environment variables, and finally trigger

166
00:09:41.159 --> 00:09:44.279
<v Speaker 1>and import using a service principle, never a regular account.

167
00:09:44.559 --> 00:09:48.679
<v Speaker 1>Otherwise you're stuck with audits and permission denials. GitHub actions

168
00:09:48.679 --> 00:09:51.720
<v Speaker 1>can tie this process together, but only if each job

169
00:09:51.840 --> 00:09:54.840
<v Speaker 1>knows which environment to target and which secrets to use.

170
00:09:54.960 --> 00:09:57.159
<v Speaker 1>I've seen teams try to shortcut this by using a

171
00:09:57.200 --> 00:09:59.840
<v Speaker 1>single set of credentials across dev and PROD, which is

172
00:09:59.840 --> 00:10:03.000
<v Speaker 1>a recipe for chaos, data leaks, permission errors, and broken

173
00:10:03.039 --> 00:10:06.080
<v Speaker 1>features that only show up in one environment. Take a

174
00:10:06.120 --> 00:10:08.039
<v Speaker 1>real world team I worked with a few months back.

175
00:10:08.639 --> 00:10:12.080
<v Speaker 1>They did most things right standard Git repos, version solution, zips,

176
00:10:12.120 --> 00:10:15.480
<v Speaker 1>and clear branching, but their pipeline always broke at deployment.

177
00:10:15.639 --> 00:10:19.039
<v Speaker 1>Why they never bothered to swap environment variables or update

178
00:10:19.039 --> 00:10:22.600
<v Speaker 1>connector references before importing into PROD That left key flows

179
00:10:22.600 --> 00:10:25.120
<v Speaker 1>pointing to the wrong end points with data trickling into

180
00:10:25.120 --> 00:10:28.679
<v Speaker 1>the wrong systems. The fix scripted steps in their GitHub

181
00:10:28.720 --> 00:10:32.679
<v Speaker 1>pipeline that swapped variables and remapped every connector on import.

182
00:10:33.080 --> 00:10:36.799
<v Speaker 1>Microsoft's own guidance is blunt about this. Use solution files

183
00:10:36.799 --> 00:10:40.799
<v Speaker 1>for moving things between environments, but always handle connector references

184
00:10:40.840 --> 00:10:43.600
<v Speaker 1>and role mapping as part of your pipeline. They point

185
00:10:43.600 --> 00:10:45.960
<v Speaker 1>out that skipping these steps is the number one way

186
00:10:45.960 --> 00:10:48.960
<v Speaker 1>to break apps, especially as environments get more locked down.

187
00:10:49.120 --> 00:10:52.039
<v Speaker 1>Once you treat source, build, test, and deploy as connected

188
00:10:52.080 --> 00:10:54.799
<v Speaker 1>moving parts, not just isolated steps, it's easier to see

189
00:10:54.799 --> 00:10:58.080
<v Speaker 1>why so many ALM attempts fall over and how you

190
00:10:58.120 --> 00:11:02.159
<v Speaker 1>can actually troubleshoot issues instead of crossing your fingers. Next,

191
00:11:02.320 --> 00:11:06.679
<v Speaker 1>let's get into how GitHub Actions coordinates this dance triggers,

192
00:11:06.759 --> 00:11:10.399
<v Speaker 1>branching and job separation that keep your power platform automation

193
00:11:10.519 --> 00:11:14.279
<v Speaker 1>both flexible and secure. GitHub Actions connecting the dots with

194
00:11:14.320 --> 00:11:17.240
<v Speaker 1>triggers and jobs. If you've waited for a GitHub Actions

195
00:11:17.240 --> 00:11:20.159
<v Speaker 1>pipeline to finish after updating your power AUP. You already

196
00:11:20.200 --> 00:11:23.399
<v Speaker 1>know automation doesn't mean instant, and it definitely doesn't mean magic.

197
00:11:24.080 --> 00:11:26.799
<v Speaker 1>Most teams hit that wall right after the excitement of

198
00:11:26.840 --> 00:11:30.159
<v Speaker 1>seeing their first workflow run. You set up a script,

199
00:11:30.559 --> 00:11:34.000
<v Speaker 1>wire it into your repository, and expect every new commit

200
00:11:34.080 --> 00:11:37.840
<v Speaker 1>to roll out cleanly across all environments. Then reality checks in.

201
00:11:37.840 --> 00:11:40.639
<v Speaker 1>Instead of just kicking off a script, GitHub Actions uses

202
00:11:40.679 --> 00:11:45.519
<v Speaker 1>a logic chain built around triggers, jobs, and handoffs between environments.

203
00:11:45.679 --> 00:11:48.639
<v Speaker 1>That order and structure is what keeps deployments from becoming

204
00:11:48.679 --> 00:11:52.080
<v Speaker 1>a tangle of failed steps and strange errors. The starting

205
00:11:52.080 --> 00:11:55.679
<v Speaker 1>point in this system is the trigger. Most first timers

206
00:11:55.759 --> 00:12:00.080
<v Speaker 1>create a workflow that fires on every push or or

207
00:12:00.399 --> 00:12:03.519
<v Speaker 1>whenever a pool request lands in the main branch. On

208
00:12:03.559 --> 00:12:05.559
<v Speaker 1>the surface, that looks like best practice. Why not run

209
00:12:05.600 --> 00:12:08.559
<v Speaker 1>your pipeline every time work changes? Here's the catch. When

210
00:12:08.559 --> 00:12:11.159
<v Speaker 1>you only set a trigger on Maine, everything gets funneled

211
00:12:11.159 --> 00:12:13.559
<v Speaker 1>through a single track. What if changes need to hit

212
00:12:13.679 --> 00:12:16.080
<v Speaker 1>dev but not test or PROD. What if you're ready

213
00:12:16.120 --> 00:12:18.600
<v Speaker 1>to push to PRAD but test is still running Validation

214
00:12:19.200 --> 00:12:21.519
<v Speaker 1>Teams that stick to one size fits all triggers tend

215
00:12:21.600 --> 00:12:24.759
<v Speaker 1>to run into problems where features meant for development environments

216
00:12:24.799 --> 00:12:29.600
<v Speaker 1>sneak into production or test deployments suddenly overwrite PROD settings.

217
00:12:30.039 --> 00:12:33.440
<v Speaker 1>You can branch workflows for each environment, dev, test, and

218
00:12:33.519 --> 00:12:37.480
<v Speaker 1>PROD and set up very specific triggers for each. For example,

219
00:12:37.519 --> 00:12:40.440
<v Speaker 1>set up a workflow that only runs on pushes to

220
00:12:40.519 --> 00:12:43.919
<v Speaker 1>a dev branch, or fire a different workflow when someone

221
00:12:43.960 --> 00:12:46.879
<v Speaker 1>merges into release PROD. And This approach gives more control

222
00:12:46.919 --> 00:12:49.480
<v Speaker 1>and creates a clear fence between work in progress and

223
00:12:49.519 --> 00:12:51.799
<v Speaker 1>life changes. But a lot of teams never revisit their

224
00:12:51.840 --> 00:12:55.399
<v Speaker 1>triggers after creating them. That's how secrets from one environment

225
00:12:55.480 --> 00:12:59.360
<v Speaker 1>can slip into another and configument for dev ends up

226
00:12:59.399 --> 00:13:02.080
<v Speaker 1>in PROD by accident. One team I worked with tried

227
00:13:02.080 --> 00:13:04.919
<v Speaker 1>to run their entire ALM process from a single workflow.

228
00:13:05.399 --> 00:13:08.840
<v Speaker 1>For a while. It seemed fine until someone noticed that

229
00:13:09.080 --> 00:13:12.559
<v Speaker 1>a production database connection string showed up in the dev environment.

230
00:13:12.960 --> 00:13:15.879
<v Speaker 1>They didn't realize their secrets were being shared between jobs,

231
00:13:16.360 --> 00:13:19.799
<v Speaker 1>and one's code moved between environments, those secrets leaked with it.

232
00:13:19.799 --> 00:13:22.120
<v Speaker 1>It wasn't an obvious crash or error, it was silent.

233
00:13:22.600 --> 00:13:24.639
<v Speaker 1>This kind of data spill is more common than you'd think,

234
00:13:24.799 --> 00:13:27.759
<v Speaker 1>especially if you don't set up your workflows to separate

235
00:13:27.840 --> 00:13:31.480
<v Speaker 1>secrets and environment variables. Each job in a GitHub Actions

236
00:13:31.519 --> 00:13:34.960
<v Speaker 1>workflow handles a clear piece of the process. One job

237
00:13:35.039 --> 00:13:37.759
<v Speaker 1>might handle exporting the solution from a source environment that

238
00:13:37.840 --> 00:13:42.840
<v Speaker 1>Another job takes care of validation, unpacking, scanning through solution metadata,

239
00:13:43.000 --> 00:13:46.960
<v Speaker 1>checking all the dependencies, and making sure connector references exist.

240
00:13:47.279 --> 00:13:50.519
<v Speaker 1>Next comes the job that prepares the environment specific variables,

241
00:13:50.559 --> 00:13:53.799
<v Speaker 1>translating the solution so it fits its target environment. The

242
00:13:53.879 --> 00:13:57.440
<v Speaker 1>last job triggers the import process, using service principles to

243
00:13:57.519 --> 00:14:00.240
<v Speaker 1>write changes into the right environment. You might think of

244
00:14:00.360 --> 00:14:04.519
<v Speaker 1>environment variables and secrets as basic placeholders, but in practice

245
00:14:04.600 --> 00:14:09.039
<v Speaker 1>they're the glue holding everything together. Connection strings, API keys,

246
00:14:09.519 --> 00:14:12.759
<v Speaker 1>shared passwords. They all need to be swapped between jobs,

247
00:14:12.799 --> 00:14:16.279
<v Speaker 1>but they can never leak across boundaries. In power platform ALM,

248
00:14:16.360 --> 00:14:18.919
<v Speaker 1>you may have a different data verse connection for each environment,

249
00:14:19.440 --> 00:14:22.240
<v Speaker 1>or need to swap end points depending on which flow

250
00:14:22.360 --> 00:14:26.039
<v Speaker 1>or power app you're targeting. If you reuse variables or

251
00:14:26.039 --> 00:14:28.639
<v Speaker 1>hard code secrets, you end up with either a brittle

252
00:14:28.679 --> 00:14:33.120
<v Speaker 1>pipeline or worse, significant security risks. The import process depends

253
00:14:33.120 --> 00:14:36.320
<v Speaker 1>on pulling secrets only from the right vault, so production

254
00:14:36.480 --> 00:14:39.879
<v Speaker 1>isn't exposed by test or dev mishaps. A good mental

255
00:14:39.919 --> 00:14:42.840
<v Speaker 1>model for secrets in GitHub actions is to picture each

256
00:14:42.960 --> 00:14:46.159
<v Speaker 1>environment as having its own digital vault, a locked box

257
00:14:46.240 --> 00:14:49.919
<v Speaker 1>only the right jobs can see. GitHub gives you precise controls.

258
00:14:50.360 --> 00:14:53.519
<v Speaker 1>You can scope secrets to environments, so a job running

259
00:14:53.519 --> 00:14:57.559
<v Speaker 1>in dev can't access credentials and vice versa. Set up

260
00:14:57.559 --> 00:15:00.559
<v Speaker 1>these vaults, and even if someone tweaking the pipe tries

261
00:15:00.559 --> 00:15:04.600
<v Speaker 1>something risky, environment protection rules prevent a misstep from crossing over.

262
00:15:04.960 --> 00:15:08.480
<v Speaker 1>Microsoft's and GitHub's own documentation. Both hammer this point. They

263
00:15:08.519 --> 00:15:12.200
<v Speaker 1>recommend environment protection rules and strict secret scoping to stop

264
00:15:12.240 --> 00:15:16.039
<v Speaker 1>cross environment leaks before they even start. Without that kind

265
00:15:16.080 --> 00:15:19.480
<v Speaker 1>of protection, even the best designed ALM workflows fall apart.

266
00:15:19.960 --> 00:15:22.960
<v Speaker 1>Imagine a workflow deploying to PROD while still holding onto

267
00:15:22.960 --> 00:15:26.159
<v Speaker 1>a DEV connection string or a test environment suddenly with

268
00:15:26.200 --> 00:15:29.320
<v Speaker 1>access to PROD data. It doesn't always break things visibly.

269
00:15:29.759 --> 00:15:32.639
<v Speaker 1>Sometimes it just means compliance flags go off or logs

270
00:15:32.639 --> 00:15:35.799
<v Speaker 1>fill up with subtle errors that slowly pile into bigger problems.

271
00:15:35.879 --> 00:15:38.759
<v Speaker 1>This is why branching workflows and scoping secrets aren't just

272
00:15:38.799 --> 00:15:41.799
<v Speaker 1>advanced topics. They're the safety net that keeps your automation

273
00:15:41.960 --> 00:15:46.120
<v Speaker 1>from quietly unraveling. There's also value in splitting workflows not

274
00:15:46.200 --> 00:15:50.039
<v Speaker 1>just by environment, but by responsibility. Code that exports and

275
00:15:50.080 --> 00:15:54.320
<v Speaker 1>validates solutions shouldn't even know how to deploy or swap secrets.

276
00:15:54.679 --> 00:15:57.799
<v Speaker 1>If every job handles one piece of the puzzle, it

277
00:15:57.840 --> 00:16:01.080
<v Speaker 1>becomes much easier to spot where things break, roll back

278
00:16:01.159 --> 00:16:04.679
<v Speaker 1>and audit changes after the fact secrets stay in their vaults,

279
00:16:04.840 --> 00:16:09.159
<v Speaker 1>jobs follow clearly scoped permissions, and pipeline failures point straight

280
00:16:09.200 --> 00:16:12.440
<v Speaker 1>to the piece that needs fixing. Understanding how GitHub actions

281
00:16:12.519 --> 00:16:15.679
<v Speaker 1>hands off work from one job to another while keeping

282
00:16:15.720 --> 00:16:19.360
<v Speaker 1>secrets tightly scoped and triggers clearly defined is what takes

283
00:16:19.399 --> 00:16:22.440
<v Speaker 1>alm from a hopeful experiment to a reliable, secure, and

284
00:16:22.480 --> 00:16:28.200
<v Speaker 1>predictable practice. This workflow segmentation isn't just about matching best practices.

285
00:16:28.440 --> 00:16:32.559
<v Speaker 1>It's what blocks quiet security leaks and accidental overrides, and

286
00:16:32.639 --> 00:16:35.279
<v Speaker 1>it cuts off a whole class of invisible errors before

287
00:16:35.320 --> 00:16:38.480
<v Speaker 1>they start to haunt your environments. Now, with the pieces

288
00:16:38.559 --> 00:16:42.519
<v Speaker 1>working together through properly scoped automation, it's time we tackle

289
00:16:42.559 --> 00:16:46.759
<v Speaker 1>another friction point, connectors, service principles and the small but

290
00:16:46.879 --> 00:16:50.240
<v Speaker 1>critical pitfalls that can stall your deployments right as you

291
00:16:50.320 --> 00:16:54.759
<v Speaker 1>get confident, secret service principles and the trouble with connectors.

292
00:16:55.039 --> 00:16:57.440
<v Speaker 1>If you've ever tried moving a power app or flow

293
00:16:57.559 --> 00:17:00.639
<v Speaker 1>from dev to praud, you know the story. Things work

294
00:17:00.679 --> 00:17:03.919
<v Speaker 1>flawlessly in one environment, then as soon as you switch over,

295
00:17:04.000 --> 00:17:06.960
<v Speaker 1>everything grinds to a halt or gives you those mysterious

296
00:17:06.960 --> 00:17:10.720
<v Speaker 1>connection errors. It isn't unique to a specific team. Every

297
00:17:10.799 --> 00:17:14.839
<v Speaker 1>power Platform admin eventually runs into this wall. The root

298
00:17:14.960 --> 00:17:18.359
<v Speaker 1>of the problem lies in how connectors and secrets behave

299
00:17:18.480 --> 00:17:21.960
<v Speaker 1>behind the scenes. You can't just export a solution zip

300
00:17:22.039 --> 00:17:24.720
<v Speaker 1>from development and expect it to work somewhere else because

301
00:17:24.759 --> 00:17:28.200
<v Speaker 1>the wires it depends on change with every environment. Take

302
00:17:28.200 --> 00:17:31.839
<v Speaker 1>connector references for starters. In Power Platform, a connector is

303
00:17:32.000 --> 00:17:35.200
<v Speaker 1>never just a static bit of information bundled into your app.

304
00:17:35.400 --> 00:17:39.000
<v Speaker 1>It's dynamic, mutable, and often unique per environment. When you

305
00:17:39.039 --> 00:17:42.880
<v Speaker 1>export your solution, connector references act almost like bookmarks. They

306
00:17:42.920 --> 00:17:46.160
<v Speaker 1>point to connection objects that only exist in the environment

307
00:17:46.200 --> 00:17:48.640
<v Speaker 1>they were built in. So when you import into test

308
00:17:48.759 --> 00:17:52.559
<v Speaker 1>or PROD, your fancy HTTP endpoint or data verse link

309
00:17:52.640 --> 00:17:55.599
<v Speaker 1>doesn't necessarily get recreated the same way or at all.

310
00:17:55.720 --> 00:17:58.400
<v Speaker 1>This is where teams get caught out. If DEV is

311
00:17:58.519 --> 00:18:03.200
<v Speaker 1>using a connector to data and that exact configuration isn't

312
00:18:03.240 --> 00:18:07.519
<v Speaker 1>mirrored in PROD, your flow or app either fails silently

313
00:18:07.880 --> 00:18:11.480
<v Speaker 1>or hangs on the first attempt to connect. A lot

314
00:18:11.480 --> 00:18:13.960
<v Speaker 1>of folks try to get around this by sharing user

315
00:18:14.000 --> 00:18:17.400
<v Speaker 1>credentials across environments. They figure if you use the same

316
00:18:17.440 --> 00:18:20.960
<v Speaker 1>account or password that created the connection in DEV, maybe

317
00:18:21.000 --> 00:18:23.640
<v Speaker 1>it'll just work in PROD. The reality is this invites

318
00:18:23.640 --> 00:18:26.680
<v Speaker 1>a host of problems, everything from permission denials to compliance

319
00:18:26.720 --> 00:18:30.279
<v Speaker 1>audit triggers. Microsoft's own guidance is clear using individual user

320
00:18:30.279 --> 00:18:34.000
<v Speaker 1>credentials for automated deployments just isn't viable or secure. It

321
00:18:34.000 --> 00:18:36.920
<v Speaker 1>puts your automation at the mercy of password resets and

322
00:18:36.960 --> 00:18:39.400
<v Speaker 1>can leave a muddy trail in your audit logs. There's

323
00:18:39.440 --> 00:18:44.440
<v Speaker 1>no clear accountability, and eventually permissions block the pipeline when

324
00:18:44.480 --> 00:18:48.880
<v Speaker 1>the original user is flagged, removed, or loses access. Enter

325
00:18:48.960 --> 00:18:51.839
<v Speaker 1>service principles if you haven't worked with them. Picture a

326
00:18:51.880 --> 00:18:55.000
<v Speaker 1>service principle as a digital extra set of hands, purpose

327
00:18:55.000 --> 00:18:59.200
<v Speaker 1>built for automation. Unlike a regular user, a service principle

328
00:18:59.240 --> 00:19:02.039
<v Speaker 1>is tied to an app registration in as You're ad

329
00:19:02.240 --> 00:19:05.319
<v Speaker 1>not a real person. You give it the minimum permissions

330
00:19:05.319 --> 00:19:08.759
<v Speaker 1>needed to run your deployment tasks. That sounds simple, but

331
00:19:08.799 --> 00:19:11.240
<v Speaker 1>the payoff is big. Instead of relying on a user

332
00:19:11.240 --> 00:19:15.440
<v Speaker 1>who could leave the organization or change roles, deployments stay consistent, auditable,

333
00:19:15.720 --> 00:19:18.599
<v Speaker 1>and traceable. Every environment gets access only to the right

334
00:19:18.640 --> 00:19:22.440
<v Speaker 1>connections and resources, and any changes are logged under this

335
00:19:22.559 --> 00:19:25.480
<v Speaker 1>robot account. When something fails, you have a clean audit

336
00:19:25.519 --> 00:19:28.319
<v Speaker 1>trail and you don't end up with orphaned flows. Nobody

337
00:19:28.400 --> 00:19:32.279
<v Speaker 1>can fix on the problem of mapping connectors. Consider what

338
00:19:32.480 --> 00:19:36.720
<v Speaker 1>happens when environments drift apart. Maybe the dev team got

339
00:19:36.720 --> 00:19:39.400
<v Speaker 1>approval for a new custom connector. Let's say it hits

340
00:19:39.440 --> 00:19:42.400
<v Speaker 1>a sandbox API. When it comes time to move to PROD,

341
00:19:42.559 --> 00:19:45.000
<v Speaker 1>that connector isn't just missing, it may not even be

342
00:19:45.240 --> 00:19:49.119
<v Speaker 1>allowed by organizational data policies. If you forget to remap,

343
00:19:49.279 --> 00:19:53.000
<v Speaker 1>the app calls out to the wrong endpoint or breaks entirely.

344
00:19:53.640 --> 00:19:56.359
<v Speaker 1>I saw this landhard at a healthcare group recently. One

345
00:19:56.440 --> 00:19:59.160
<v Speaker 1>missed connector mapping triggered the use of test data in

346
00:19:59.200 --> 00:20:03.200
<v Speaker 1>production and near created a compliance incident. There. Automated pipeline

347
00:20:03.240 --> 00:20:06.960
<v Speaker 1>exported everything as planned, but the connector reference inside the

348
00:20:07.000 --> 00:20:10.279
<v Speaker 1>solution still pointed back to an old test database that

349
00:20:10.400 --> 00:20:13.440
<v Speaker 1>wasn't flagged by power platform until real data started flowing

350
00:20:13.440 --> 00:20:16.799
<v Speaker 1>through the wrong pipes. Environment variables step in to ease

351
00:20:16.880 --> 00:20:20.440
<v Speaker 1>some of this pain. Unlike hard coding endpoints or apikeys,

352
00:20:20.680 --> 00:20:24.559
<v Speaker 1>environment variables let you separate what changes across environments from

353
00:20:24.559 --> 00:20:27.839
<v Speaker 1>what stays the same. You can swap out endpoints, apikeys,

354
00:20:27.920 --> 00:20:31.640
<v Speaker 1>or other secrets with each deployment without rewriting your app

355
00:20:31.720 --> 00:20:34.000
<v Speaker 1>or flow. For example, a flow that works with a

356
00:20:34.039 --> 00:20:37.559
<v Speaker 1>dev data verse table can be reconfigured on import to

357
00:20:37.720 --> 00:20:41.039
<v Speaker 1>use the prod table simply by changing the environment variable

358
00:20:41.079 --> 00:20:45.279
<v Speaker 1>inside your deployment process. GitHub actions pipelines make this practical.

359
00:20:45.359 --> 00:20:47.839
<v Speaker 1>Each job can inject the right value at the right time,

360
00:20:48.519 --> 00:20:51.480
<v Speaker 1>but even here discipline is key. Forget to update a

361
00:20:51.559 --> 00:20:56.400
<v Speaker 1>variable or let secrets leak across environments and suddenly your

362
00:20:56.440 --> 00:21:00.599
<v Speaker 1>workflow is exposed. Microsoft emphasizes the need to scope secrets

363
00:21:00.599 --> 00:21:06.039
<v Speaker 1>carefully and map connector references intentionally. Their DLP data loss

364
00:21:06.039 --> 00:21:09.720
<v Speaker 1>prevention policies exist for a reason, to keep sensitive information

365
00:21:09.799 --> 00:21:12.880
<v Speaker 1>from wandering between environments or surfacing in the wrong place.

366
00:21:13.359 --> 00:21:17.160
<v Speaker 1>If you try to bypass these by sharing variables or connections.

367
00:21:17.720 --> 00:21:22.200
<v Speaker 1>You'll trip over corporate security or compliance controls. More importantly,

368
00:21:22.240 --> 00:21:25.119
<v Speaker 1>you lose predictability because there's no longer a line between

369
00:21:25.119 --> 00:21:28.799
<v Speaker 1>what's meant for DEV versus test or PROD. The benefit

370
00:21:28.839 --> 00:21:31.400
<v Speaker 1>when you get all of this right is hard to overstate.

371
00:21:31.640 --> 00:21:35.599
<v Speaker 1>Service principles combined with well managed environment, variables and properly

372
00:21:35.640 --> 00:21:39.839
<v Speaker 1>mapped connectors transform your pipeline. Your deployments become predictable. When

373
00:21:39.880 --> 00:21:42.400
<v Speaker 1>things break, you have a clear chain of custody and

374
00:21:42.519 --> 00:21:45.079
<v Speaker 1>know exactly where to look. Was it a connector, mapping

375
00:21:45.160 --> 00:21:49.039
<v Speaker 1>a variable or a missed permission. Auditors can follow changes,

376
00:21:49.039 --> 00:21:51.559
<v Speaker 1>and there's no suspense when someone leaves the organization or

377
00:21:51.640 --> 00:21:55.119
<v Speaker 1>changes passwords. It all comes down to handling secrets, connectors,

378
00:21:55.160 --> 00:21:58.319
<v Speaker 1>and service principles like they matter because in power platform

379
00:21:58.359 --> 00:22:02.240
<v Speaker 1>ALM they do. Misstep and hours of manual patching follow.

380
00:22:02.400 --> 00:22:05.079
<v Speaker 1>Get them right, and your pipeline finally works the way

381
00:22:05.079 --> 00:22:09.880
<v Speaker 1>it should, resilient, secure, and transparent. When things do go wrong,

382
00:22:10.039 --> 00:22:12.960
<v Speaker 1>the troubleshooting process doesn't start from square one. You already

383
00:22:12.960 --> 00:22:15.559
<v Speaker 1>have the evidence of what moved, who moved it, and how,

384
00:22:16.000 --> 00:22:17.640
<v Speaker 1>and that brings us to the last piece, what to

385
00:22:17.680 --> 00:22:19.839
<v Speaker 1>do when ALM still throws a wrench in the works

386
00:22:19.839 --> 00:22:23.000
<v Speaker 1>and how to unstick even the most tangled deployments. If

387
00:22:23.039 --> 00:22:26.000
<v Speaker 1>you've built power platform solutions for a while, you know

388
00:22:26.119 --> 00:22:28.960
<v Speaker 1>ALM isn't just about copying files and hoping for the best.

389
00:22:29.279 --> 00:22:33.599
<v Speaker 1>Each piece the solution, files, connectors, service principles, and environment

390
00:22:33.680 --> 00:22:37.319
<v Speaker 1>variables serves a real purpose, and understanding how they interact

391
00:22:37.400 --> 00:22:40.440
<v Speaker 1>is what lets you avoid costly surprises down the line

392
00:22:40.799 --> 00:22:44.839
<v Speaker 1>when Microsoft moves the goalposts or another connector changes. The

393
00:22:44.920 --> 00:22:48.480
<v Speaker 1>teams that adapt the fastest are the ones who actually

394
00:22:48.519 --> 00:22:51.279
<v Speaker 1>know why each step matters and don't just tick boxes.

395
00:22:51.759 --> 00:22:55.599
<v Speaker 1>Want to share something that broke spectacularly or quietly in

396
00:22:55.640 --> 00:22:58.599
<v Speaker 1>your deployment, Drop it below and we'll dig into it together.