WEBVTT

1
00:00:00.080 --> 00:00:03.120
<v Speaker 1>Ever wonder why your power platform projects spiral into chaos

2
00:00:03.120 --> 00:00:05.679
<v Speaker 1>as soon as more than one environment is involved. Today,

3
00:00:05.679 --> 00:00:08.359
<v Speaker 1>we'll unpack how the packcli could be the missing puzzle

4
00:00:08.359 --> 00:00:11.439
<v Speaker 1>piece for finally bringing order to your DevOps workflow. By

5
00:00:11.439 --> 00:00:15.000
<v Speaker 1>the end, you'll see why managing solutions, components and plugins

6
00:00:15.000 --> 00:00:18.920
<v Speaker 1>across environments isn't just possible, it's surprisingly smooth. Can a

7
00:00:18.960 --> 00:00:21.960
<v Speaker 1>single set of commands save you hours of rework and headaches?

8
00:00:22.079 --> 00:00:25.519
<v Speaker 1>Stick around and find out how the right pack cli

9
00:00:25.679 --> 00:00:31.000
<v Speaker 1>strategy flips the script on power platform sprawl. Why packcli

10
00:00:31.039 --> 00:00:34.359
<v Speaker 1>feels different and actually matters. If you've worked in power

11
00:00:34.399 --> 00:00:36.280
<v Speaker 1>apps for more than a day and try to get

12
00:00:36.359 --> 00:00:39.799
<v Speaker 1>your handiwork out of the maker portal and into another environment,

13
00:00:40.000 --> 00:00:43.520
<v Speaker 1>you know the feeling the portal is quick for prototyping,

14
00:00:43.600 --> 00:00:45.719
<v Speaker 1>drop a button here, connect the flow there, and it

15
00:00:45.759 --> 00:00:48.520
<v Speaker 1>all just works, Or at least that's the story, until

16
00:00:48.560 --> 00:00:50.840
<v Speaker 1>you try to move that app to a new environment.

17
00:00:51.439 --> 00:00:54.200
<v Speaker 1>Suddenly you're dealing with missing data sources. You wonder why

18
00:00:54.240 --> 00:00:56.759
<v Speaker 1>the same thing that worked in dev is breaking in QA.

19
00:00:57.359 --> 00:01:01.880
<v Speaker 1>Manual rework creeps in renaming components and hunting for dependencies,

20
00:01:02.240 --> 00:01:04.799
<v Speaker 1>patching settings that should have stayed in sync. It's like

21
00:01:04.840 --> 00:01:08.599
<v Speaker 1>sending a group email and realizing half your attachments never

22
00:01:08.640 --> 00:01:11.120
<v Speaker 1>made it. That initial sense of this is so easy

23
00:01:11.400 --> 00:01:13.719
<v Speaker 1>that you get from the point and click experience fades

24
00:01:13.760 --> 00:01:16.840
<v Speaker 1>fast the moment environments get involved. That's not just a

25
00:01:16.879 --> 00:01:20.560
<v Speaker 1>minor hiccup. It's the reality. Most teams hit citizen developers

26
00:01:20.560 --> 00:01:23.000
<v Speaker 1>and it pros start off in the power Apps portal

27
00:01:23.040 --> 00:01:25.799
<v Speaker 1>because it's built to be friendly, at least on the surface.

28
00:01:25.959 --> 00:01:29.560
<v Speaker 1>It walks you through building screens and automating workflows. But

29
00:01:29.640 --> 00:01:32.280
<v Speaker 1>let's be honest, the moment you need to maintain what

30
00:01:32.400 --> 00:01:36.239
<v Speaker 1>you build or god forbid scale, it cracks. Start showing

31
00:01:36.439 --> 00:01:39.120
<v Speaker 1>the power Platform world was designed to let people create

32
00:01:39.159 --> 00:01:42.200
<v Speaker 1>without code, which is fantastic until you realize that a

33
00:01:42.280 --> 00:01:44.439
<v Speaker 1>real business app has to live in more than one

34
00:01:44.480 --> 00:01:48.120
<v Speaker 1>place with consistent behavior. Every time. You can fudget by

35
00:01:48.200 --> 00:01:51.879
<v Speaker 1>manually redoing work. But long term, nobody wants to update

36
00:01:52.000 --> 00:01:55.280
<v Speaker 1>five versions of the same button across five environments. That's

37
00:01:55.280 --> 00:01:58.159
<v Speaker 1>wasted time. The big elephant in the room is change management.

38
00:01:58.400 --> 00:02:00.920
<v Speaker 1>But when you create components in the port it's easy

39
00:02:00.920 --> 00:02:04.239
<v Speaker 1>to feel like everything is self contained. But power Platform's

40
00:02:04.280 --> 00:02:07.719
<v Speaker 1>biggest strength, it's flexibility. Often creates headaches when you need

41
00:02:07.760 --> 00:02:11.280
<v Speaker 1>to move things between environments. Suddenly what you build isn't

42
00:02:11.319 --> 00:02:14.240
<v Speaker 1>as portable as you thought. Even small differences between test

43
00:02:14.280 --> 00:02:16.919
<v Speaker 1>and PROD can turn into hours of troubleshooting, not because

44
00:02:16.919 --> 00:02:19.479
<v Speaker 1>you've done something wrong, but because the portal simply isn't

45
00:02:19.479 --> 00:02:23.199
<v Speaker 1>built for true portability or component reuse. You can get

46
00:02:23.240 --> 00:02:25.439
<v Speaker 1>by for a while, but it's a fragile way to work,

47
00:02:25.800 --> 00:02:29.680
<v Speaker 1>more like building sand castles than real applications. So when

48
00:02:29.719 --> 00:02:33.000
<v Speaker 1>people see the packcli for the first time, the usual

49
00:02:33.360 --> 00:02:36.879
<v Speaker 1>reaction is hesitation. A command line interface by itself feels

50
00:02:36.919 --> 00:02:39.919
<v Speaker 1>like a throwback. You can almost feel the reluctance. Do

51
00:02:40.000 --> 00:02:42.039
<v Speaker 1>I really want to mess with scripting when the portal

52
00:02:42.080 --> 00:02:44.759
<v Speaker 1>covers most of what I need? But here's the weird thing.

53
00:02:45.039 --> 00:02:47.800
<v Speaker 1>The packcli isn't just a tool for pushing buttons through

54
00:02:47.840 --> 00:02:50.879
<v Speaker 1>a different UI. It forces a change in mindset. Instead

55
00:02:50.919 --> 00:02:54.080
<v Speaker 1>of thinking in terms of building once and dragging copies everywhere,

56
00:02:54.400 --> 00:02:57.319
<v Speaker 1>you start to assemble solutions like a software engineer would.

57
00:02:58.199 --> 00:03:02.080
<v Speaker 1>Components become assets with version dependencies and proper life cycles.

58
00:03:02.199 --> 00:03:04.719
<v Speaker 1>That's the leap most folks miss. There's a learning curve,

59
00:03:05.000 --> 00:03:07.599
<v Speaker 1>but it's nothing compared to the treadmill of repeated manual working.

60
00:03:07.639 --> 00:03:10.479
<v Speaker 1>It's almost funny. The CLI looks intimidating, but after a

61
00:03:10.520 --> 00:03:12.879
<v Speaker 1>few tries you start to see what it actually unlocks.

62
00:03:13.199 --> 00:03:16.039
<v Speaker 1>Scripting your bills and deployments means you're not stuck clicking

63
00:03:16.120 --> 00:03:18.479
<v Speaker 1>through the same screens over and over. You're not sitting

64
00:03:18.560 --> 00:03:21.919
<v Speaker 1>there with a checklist, chewing your fingernails and hoping you

65
00:03:22.000 --> 00:03:25.680
<v Speaker 1>didn't forget to attach that one key flow. Instead, you

66
00:03:25.759 --> 00:03:28.919
<v Speaker 1>script the process and you know exactly what's included every

67
00:03:28.919 --> 00:03:32.360
<v Speaker 1>single time. If a dependency is missing, the CLI tells

68
00:03:32.360 --> 00:03:34.919
<v Speaker 1>you if you switch tenants, you're not blind. No more

69
00:03:34.960 --> 00:03:38.039
<v Speaker 1>wild guessing which environment you're in, no more opening three

70
00:03:38.039 --> 00:03:40.960
<v Speaker 1>browser tabs just to double check your context. It's like

71
00:03:41.000 --> 00:03:44.560
<v Speaker 1>switching from handwriting every invoice by hand to generating them

72
00:03:44.560 --> 00:03:48.280
<v Speaker 1>through a billing system. Tedious becomes manageable. The sharpest difference

73
00:03:48.319 --> 00:03:52.080
<v Speaker 1>isn't about automation. For automation's sake. PACKCLI allows you to

74
00:03:52.080 --> 00:03:56.319
<v Speaker 1>manage components with practices borrowed from real software engineering. Versioning

75
00:03:56.360 --> 00:03:59.360
<v Speaker 1>so you know what's running where, reusability so you're not

76
00:03:59.400 --> 00:04:02.120
<v Speaker 1>reinventing the wheel, and maybe most important of all, it

77
00:04:02.199 --> 00:04:05.719
<v Speaker 1>lets you actually troubleshoot. When things break, you aren't left

78
00:04:05.759 --> 00:04:09.479
<v Speaker 1>with vague arrow pop ups. You get logs, details, actionable steps.

79
00:04:09.919 --> 00:04:12.800
<v Speaker 1>Teams who stick to point and click workflows often find

80
00:04:12.800 --> 00:04:15.879
<v Speaker 1>that small bugs get multiplied every time they update a

81
00:04:15.879 --> 00:04:19.600
<v Speaker 1>component by hand. Eventually the app becomes brittle, nobody wants

82
00:04:19.600 --> 00:04:22.839
<v Speaker 1>to fix it. Everyone dreads even minor changes. At that point,

83
00:04:22.879 --> 00:04:26.439
<v Speaker 1>business agility is just marketing speak. What's refreshing about the

84
00:04:26.480 --> 00:04:30.240
<v Speaker 1>CLI approach is how quickly even basic DevOps ideas start

85
00:04:30.279 --> 00:04:32.160
<v Speaker 1>making sense. You don't need to be a full stack

86
00:04:32.199 --> 00:04:34.879
<v Speaker 1>engineer to appreciate what happens when you can script moving

87
00:04:34.920 --> 00:04:37.639
<v Speaker 1>a solution from dev to test to PROD. Suddenly things

88
00:04:37.680 --> 00:04:41.040
<v Speaker 1>are predictable. You avoid those endless rounds of it works

89
00:04:41.040 --> 00:04:44.360
<v Speaker 1>on my machine, or wait, which version is this? Both

90
00:04:44.439 --> 00:04:47.199
<v Speaker 1>it pros and business users can benefit, especially the ones

91
00:04:47.240 --> 00:04:49.920
<v Speaker 1>who swore they'd never touch a terminal window. Once you

92
00:04:50.000 --> 00:04:53.800
<v Speaker 1>get why the CLI matters, you start seeing those repetitive

93
00:04:53.920 --> 00:04:56.560
<v Speaker 1>portal tasks for what they are busy work. Still, the

94
00:04:56.600 --> 00:04:58.920
<v Speaker 1>idea of scripts and setups can put some folks off it.

95
00:04:58.920 --> 00:05:01.279
<v Speaker 1>It feels like a risk if your environment is already

96
00:05:01.360 --> 00:05:04.800
<v Speaker 1>running fine, or worse, if you've already bricked something before,

97
00:05:05.160 --> 00:05:07.680
<v Speaker 1>just by trying the latest tool. But here's the thing.

98
00:05:07.759 --> 00:05:12.240
<v Speaker 1>Setting up packcli doesn't mean torching your existing workflow. If

99
00:05:12.240 --> 00:05:14.199
<v Speaker 1>you do it right, you can set up a parallel

100
00:05:14.240 --> 00:05:18.079
<v Speaker 1>process tinker and experiment without putting your current apps in danger.

101
00:05:18.759 --> 00:05:22.040
<v Speaker 1>And that first Cli powered export or deployment where the

102
00:05:22.040 --> 00:05:26.040
<v Speaker 1>whole solution just works across environments is oddly satisfying. Once

103
00:05:26.040 --> 00:05:27.879
<v Speaker 1>you see it, you'll wonder why you stayed in the

104
00:05:27.920 --> 00:05:30.439
<v Speaker 1>portal for so long, And that sets us up for

105
00:05:30.480 --> 00:05:33.959
<v Speaker 1>the next step. Getting packcli running without breaking what's already

106
00:05:33.959 --> 00:05:37.560
<v Speaker 1>in place. Turns out, avoiding the usual first timer mistakes

107
00:05:37.720 --> 00:05:39.399
<v Speaker 1>is easier than you'd think if you know what to

108
00:05:39.439 --> 00:05:43.519
<v Speaker 1>watch for setting up for success without breaking what works.

109
00:05:43.920 --> 00:05:46.720
<v Speaker 1>If you've ever watched a developer silently stare at their

110
00:05:46.759 --> 00:05:51.160
<v Speaker 1>screen after a rogue cli install wipe their environment, you

111
00:05:51.199 --> 00:05:54.560
<v Speaker 1>know why any new tool, especially one that runs outside

112
00:05:54.639 --> 00:05:58.839
<v Speaker 1>a safety net, can trigger flashbacks. There's something unnerving about

113
00:05:58.959 --> 00:06:02.839
<v Speaker 1>mixing business apps with command line utilities. You might want

114
00:06:02.879 --> 00:06:05.800
<v Speaker 1>to get fancy with packcli, but it's hard to ignore

115
00:06:05.839 --> 00:06:08.920
<v Speaker 1>what's already running smoothly in your workspace. Nobody wants to

116
00:06:08.959 --> 00:06:12.319
<v Speaker 1>be responsible for breaking critical flows or sideswiping a live

117
00:06:12.439 --> 00:06:15.879
<v Speaker 1>power app, especially if you're juggling work in shared sandboxes

118
00:06:16.000 --> 00:06:19.240
<v Speaker 1>or worse production. The reality is most teams have at

119
00:06:19.319 --> 00:06:22.240
<v Speaker 1>least one story where a well meaning deployment spiraled out

120
00:06:22.240 --> 00:06:25.120
<v Speaker 1>of control just because someone followed a generic tutorial that

121
00:06:25.240 --> 00:06:29.639
<v Speaker 1>left out boring details like authentication, dependency clashes, or how

122
00:06:29.680 --> 00:06:33.519
<v Speaker 1>persistent installs mess with global settings. The first hurdle with

123
00:06:33.600 --> 00:06:37.120
<v Speaker 1>power Platform CLI is the install itself. Microsoft makes the

124
00:06:37.160 --> 00:06:40.560
<v Speaker 1>documentation approachable, but it's easy to miss the part about

125
00:06:40.639 --> 00:06:44.639
<v Speaker 1>environment separation. If you launch straight into installing on your

126
00:06:45.000 --> 00:06:49.560
<v Speaker 1>daily driver without thinking through profiles or how that authentication

127
00:06:49.680 --> 00:06:51.959
<v Speaker 1>works in real life, you're opening the door to headaches,

128
00:06:52.480 --> 00:06:55.639
<v Speaker 1>those quiet moments where you catch yourself sweating over which

129
00:06:55.680 --> 00:06:59.120
<v Speaker 1>tenant you're targeting. Everyone runs into them eventually, usually after

130
00:06:59.160 --> 00:07:01.519
<v Speaker 1>a warning window that pops up halfway through your first

131
00:07:01.519 --> 00:07:04.839
<v Speaker 1>attempt at pack off create. The tension comes from tutorials

132
00:07:04.839 --> 00:07:07.600
<v Speaker 1>that gloss over the edge cases. Just install it globally

133
00:07:07.639 --> 00:07:11.120
<v Speaker 1>and you're good. Except for teams running multiple client tenants

134
00:07:11.199 --> 00:07:14.279
<v Speaker 1>or jumping between test and PROD, global installs can end

135
00:07:14.360 --> 00:07:16.720
<v Speaker 1>up stepping on each other's toes. It's more common then

136
00:07:16.759 --> 00:07:21.800
<v Speaker 1>you think settings and tokens lingering from previous sessions get reused,

137
00:07:21.839 --> 00:07:24.519
<v Speaker 1>and now you're in a totally different environment than you expected.

138
00:07:25.000 --> 00:07:27.680
<v Speaker 1>This is where profiles and smart installs come into play.

139
00:07:28.040 --> 00:07:32.079
<v Speaker 1>Features that most first timers overlook. Packcli doesn't require you

140
00:07:32.120 --> 00:07:37.000
<v Speaker 1>to bulldoze your existing workflow or make sweeping changes to

141
00:07:37.079 --> 00:07:39.759
<v Speaker 1>your working environment. Instead, you can spin up a clean,

142
00:07:39.839 --> 00:07:44.319
<v Speaker 1>contained setup using environment variables or lightweight sandbox vms to

143
00:07:44.439 --> 00:07:47.959
<v Speaker 1>isolate your CLI usage. This means you're running side by

144
00:07:48.000 --> 00:07:51.759
<v Speaker 1>side with the portal and other development tools, not replacing them.

145
00:07:51.879 --> 00:07:54.439
<v Speaker 1>For anyone who's ever been burned by an installer that

146
00:07:54.480 --> 00:07:56.839
<v Speaker 1>didn't give you an undue button, knowing you can play

147
00:07:56.879 --> 00:08:00.439
<v Speaker 1>in a sandbox makes the difference between cautious curer and

148
00:08:00.639 --> 00:08:03.759
<v Speaker 1>actual adoption. Let's walk through how this works in practice,

149
00:08:03.800 --> 00:08:06.879
<v Speaker 1>because this is where most teams get stuck. Imagine you've

150
00:08:06.920 --> 00:08:09.879
<v Speaker 1>just set up a new test environment. Instead of connecting

151
00:08:09.959 --> 00:08:13.600
<v Speaker 1>packcli directly to your company's production tenant, you start with

152
00:08:13.759 --> 00:08:17.040
<v Speaker 1>a sandbox. Once the CLI is up and running, the

153
00:08:17.040 --> 00:08:20.360
<v Speaker 1>first thing you do isn't build anything at all, it's authentication.

154
00:08:20.600 --> 00:08:23.759
<v Speaker 1>You use pack off list to see which environments are

155
00:08:23.800 --> 00:08:26.519
<v Speaker 1>already in the mix and pack off create to link

156
00:08:26.600 --> 00:08:29.879
<v Speaker 1>up with your sandbox. With this, you can explicitly control

157
00:08:29.920 --> 00:08:33.360
<v Speaker 1>where your solutions and plugins get deployed. If something goes wrong,

158
00:08:33.480 --> 00:08:36.399
<v Speaker 1>worst case, you break your isolated test tenant, your production

159
00:08:36.519 --> 00:08:38.759
<v Speaker 1>data is safe and untouched. But here's the trick that

160
00:08:38.799 --> 00:08:43.120
<v Speaker 1>most folks gloss over. Environment profiles aren't just a nice

161
00:08:43.159 --> 00:08:46.879
<v Speaker 1>to have, they're your insurance policy against those accidental did

162
00:08:46.919 --> 00:08:51.240
<v Speaker 1>I just overwrite production moments. Each authentication profile is tied

163
00:08:51.279 --> 00:08:54.000
<v Speaker 1>to its own context, so you can jump between tenants

164
00:08:54.080 --> 00:08:56.559
<v Speaker 1>like you'd switch tabs in a browser. You're not limited

165
00:08:56.600 --> 00:09:00.720
<v Speaker 1>to a single set of credentials or stuck wondering which

166
00:09:00.799 --> 00:09:04.039
<v Speaker 1>environment you're targeting. Every command you run is scoped. No

167
00:09:04.120 --> 00:09:06.879
<v Speaker 1>more leaning over your desk, double checking portal URLs while

168
00:09:06.919 --> 00:09:09.840
<v Speaker 1>silently panicking that you're about to mess up something critical.

169
00:09:10.240 --> 00:09:13.240
<v Speaker 1>There's a certain calm that comes from verifying your pipeline

170
00:09:13.240 --> 00:09:17.200
<v Speaker 1>before you do anything irreversible. Once you've linked packcli to

171
00:09:17.240 --> 00:09:20.840
<v Speaker 1>the right test environment, run a dry command query the environment,

172
00:09:21.000 --> 00:09:25.000
<v Speaker 1>list solutions, or test a fake deployment. Most teams forget

173
00:09:25.000 --> 00:09:28.240
<v Speaker 1>to do this, jumping straight from installed to workspace changes.

174
00:09:28.799 --> 00:09:31.639
<v Speaker 1>But those extra thirty seconds confirm that you're not making

175
00:09:31.639 --> 00:09:34.200
<v Speaker 1>any changes outside your controlled space, and it's not just

176
00:09:34.240 --> 00:09:37.480
<v Speaker 1>about safety. Knowing precisely where each action lands means you

177
00:09:37.519 --> 00:09:41.159
<v Speaker 1>can trace every step later if something unexpected pops up.

178
00:09:41.399 --> 00:09:43.360
<v Speaker 1>The beauty of this approach is how it lets you

179
00:09:43.399 --> 00:09:46.840
<v Speaker 1>experiment with CLI driven development without risking the stability of

180
00:09:46.879 --> 00:09:49.960
<v Speaker 1>your production builds. You're free to build, break, and rebuild

181
00:09:50.039 --> 00:09:52.759
<v Speaker 1>with zero fear that a misst flag or stray script

182
00:09:52.960 --> 00:09:56.559
<v Speaker 1>will nuke your company's workflows. And once you're comfortable, that's

183
00:09:56.559 --> 00:09:59.200
<v Speaker 1>when the CLI starts to shine. You don't just replicate

184
00:09:59.279 --> 00:10:02.879
<v Speaker 1>what's possible in the portal, You unlock a toolkit for

185
00:10:03.000 --> 00:10:07.519
<v Speaker 1>automating packaging, managing dependencies, and tracking changes, a whole new

186
00:10:07.639 --> 00:10:10.679
<v Speaker 1>level of control over your power platform assets. Once you're

187
00:10:10.720 --> 00:10:13.159
<v Speaker 1>running in a safe, contained sandbox, you start to see

188
00:10:13.159 --> 00:10:16.559
<v Speaker 1>where the command line does things the portal can't. Managing environments,

189
00:10:16.600 --> 00:10:21.240
<v Speaker 1>specific authentication, packaging entire solutions programmatically, and testing deployments without

190
00:10:21.320 --> 00:10:26.080
<v Speaker 1>risking live data all suddenly become routine. The CLI anxiety

191
00:10:26.399 --> 00:10:31.159
<v Speaker 1>melts away, replaced by the efficiency of scripting out every dull,

192
00:10:31.440 --> 00:10:34.080
<v Speaker 1>error prone process you used to do by hand. And

193
00:10:34.120 --> 00:10:36.399
<v Speaker 1>the best part you still have your portal experience for

194
00:10:36.440 --> 00:10:40.200
<v Speaker 1>ad hoc changes and visualization. PACKCLI just becomes the safety

195
00:10:40.200 --> 00:10:42.919
<v Speaker 1>net underneath, But none of that matters unless you can

196
00:10:43.039 --> 00:10:46.960
<v Speaker 1>reliably move your work between environments. Now that the CLI

197
00:10:47.120 --> 00:10:49.759
<v Speaker 1>is set up without carnage, it's time to see what

198
00:10:49.919 --> 00:10:54.120
<v Speaker 1>actually happens when you package your components into real portable solutions,

199
00:10:54.360 --> 00:10:57.840
<v Speaker 1>and why proper packaging flips the entire workflow on its head.

200
00:10:58.679 --> 00:11:02.360
<v Speaker 1>Solution packaging from component chaos to real portability. If you've

201
00:11:02.399 --> 00:11:04.799
<v Speaker 1>ever tried to promote a power app or a custom

202
00:11:04.879 --> 00:11:08.200
<v Speaker 1>component from dev to production, you'll know the pain of

203
00:11:08.240 --> 00:11:12.080
<v Speaker 1>watching pieces fall apart mid flight. Connections break, some controls

204
00:11:12.080 --> 00:11:15.120
<v Speaker 1>don't show up, Custom logic that quietly worked in the

205
00:11:15.159 --> 00:11:19.120
<v Speaker 1>sandbox suddenly fails in production, and you're left digging through

206
00:11:19.200 --> 00:11:22.240
<v Speaker 1>mismatched solutions trying to figure out what got lost in

207
00:11:22.279 --> 00:11:25.120
<v Speaker 1>the shuffle. This is the scene that plays out again

208
00:11:25.159 --> 00:11:28.559
<v Speaker 1>and again on teams that treat component management as an afterthought.

209
00:11:28.720 --> 00:11:30.840
<v Speaker 1>It's easy to think you can just copy a solution,

210
00:11:31.000 --> 00:11:33.000
<v Speaker 1>push it through the portal, and move on, but that

211
00:11:33.080 --> 00:11:36.840
<v Speaker 1>approach is exactly where environment sprawl sneaks in dozens of

212
00:11:36.879 --> 00:11:41.120
<v Speaker 1>slightly different versions floating around manual patch jobs, and a

213
00:11:41.159 --> 00:11:44.679
<v Speaker 1>release process that relies more on muscle memory than anything predictable.

214
00:11:45.000 --> 00:11:47.879
<v Speaker 1>Let's talk about the way most teams approach this. They

215
00:11:47.879 --> 00:11:50.840
<v Speaker 1>build something in dev, test, half of it, ship what

216
00:11:51.000 --> 00:11:53.679
<v Speaker 1>seems stable to a higher environment, and hope for the best.

217
00:11:54.120 --> 00:11:57.600
<v Speaker 1>Troubleshooting is a constant. One person's fix in QA becomes

218
00:11:57.600 --> 00:12:01.159
<v Speaker 1>a brand new bug in PROD. Instead of treating solutions

219
00:12:01.200 --> 00:12:05.639
<v Speaker 1>as products to be packaged and maintained, they become side projects.

220
00:12:05.840 --> 00:12:08.679
<v Speaker 1>You might see folders full of app exports and patch scripts.

221
00:12:08.720 --> 00:12:11.639
<v Speaker 1>Nobody really trusts. It's not just inefficient, it's exhausting, and

222
00:12:11.720 --> 00:12:14.759
<v Speaker 1>for anyone who ends up owning those apps, every update

223
00:12:14.799 --> 00:12:18.159
<v Speaker 1>feels riskier than the last. This is where Pacciali steps up.

224
00:12:18.279 --> 00:12:20.879
<v Speaker 1>At first glance, those dry sounding commands and pack solution

225
00:12:20.960 --> 00:12:23.480
<v Speaker 1>in IT, pack solution AD reference, pack solution pack don't

226
00:12:23.480 --> 00:12:26.519
<v Speaker 1>scream excitement, but under the hood they transform how you

227
00:12:26.559 --> 00:12:30.679
<v Speaker 1>manage business logic across environments. Instead of pushing random files

228
00:12:30.679 --> 00:12:34.399
<v Speaker 1>and hoping nothing gets missed, you're building actual portable software assets.

229
00:12:34.679 --> 00:12:37.200
<v Speaker 1>When you use pack solution in it, you create a

230
00:12:37.240 --> 00:12:41.000
<v Speaker 1>defined structure, a blueprint. With pack solution AD reference, you

231
00:12:41.039 --> 00:12:44.360
<v Speaker 1>tell the solution about every dependency, plug in or custom

232
00:12:44.399 --> 00:12:47.159
<v Speaker 1>connector it needs, and when you use pack solution pack

233
00:12:47.480 --> 00:12:52.879
<v Speaker 1>the real power shows up. Everything gets bundled, including metadata, dependencies,

234
00:12:52.879 --> 00:12:55.120
<v Speaker 1>and version info. I think of this like packing for

235
00:12:55.200 --> 00:12:58.440
<v Speaker 1>a business trip. You're not just stuffing clothes into a duffel.

236
00:12:58.919 --> 00:13:02.639
<v Speaker 1>You're systematically roll socks, making sure your chargers' presentations and

237
00:13:02.679 --> 00:13:05.519
<v Speaker 1>even your travel adapter are accounted for. Every item has

238
00:13:05.519 --> 00:13:08.039
<v Speaker 1>a place. You know what's in your bag, and maybe

239
00:13:08.080 --> 00:13:10.320
<v Speaker 1>more important, you know what's missing before you walk out

240
00:13:10.320 --> 00:13:12.799
<v Speaker 1>the door. That's what a managed solution does. No more

241
00:13:12.879 --> 00:13:16.480
<v Speaker 1>hunting around for missing dependency files after the upgrade is

242
00:13:16.519 --> 00:13:19.960
<v Speaker 1>already halfway done. This approach takes the surprise out of migration.

243
00:13:20.480 --> 00:13:23.440
<v Speaker 1>You can unpack your entire solution in a new environment,

244
00:13:23.639 --> 00:13:27.799
<v Speaker 1>hit deploy, and watch everything, including connections and required data,

245
00:13:27.960 --> 00:13:31.240
<v Speaker 1>just appear as designed. The difference isn't Academic teams that

246
00:13:31.279 --> 00:13:34.600
<v Speaker 1>move to this style of packaging notice something else less rework.

247
00:13:34.679 --> 00:13:38.159
<v Speaker 1>Instead of constantly babysitting deployments, they spend more time actually

248
00:13:38.240 --> 00:13:41.879
<v Speaker 1>building features. When everything lives in a single version solution,

249
00:13:42.559 --> 00:13:45.919
<v Speaker 1>rolling back a bad deployment becomes straightforward. If a key

250
00:13:45.919 --> 00:13:49.799
<v Speaker 1>dependency is missing, the packing process tells you before you

251
00:13:49.919 --> 00:13:53.559
<v Speaker 1>create a mess in production. This predictability is worth its

252
00:13:53.600 --> 00:13:55.759
<v Speaker 1>weight in gold the first time you push a solution

253
00:13:55.879 --> 00:13:59.080
<v Speaker 1>to UAT and everything simply works, and it goes deeper.

254
00:13:59.240 --> 00:14:02.960
<v Speaker 1>The life cycle here starts with initialization. Scaffolding out your

255
00:14:03.000 --> 00:14:05.559
<v Speaker 1>solution with pack solution in it so it's ready to grow.

256
00:14:05.679 --> 00:14:08.120
<v Speaker 1>You can add references to plugins, flows, or even web

257
00:14:08.120 --> 00:14:11.320
<v Speaker 1>resources as you go using pack solution ad reference. This

258
00:14:11.519 --> 00:14:14.559
<v Speaker 1>isn't just a technical step, it's a way to build

259
00:14:14.559 --> 00:14:18.000
<v Speaker 1>a checklist into your process when it comes time to migrate.

260
00:14:18.080 --> 00:14:21.360
<v Speaker 1>Pack solution. Pack wraps everything together, listing what's in the

261
00:14:21.360 --> 00:14:24.639
<v Speaker 1>box and letting you spot holes quickly. You can version

262
00:14:24.759 --> 00:14:28.399
<v Speaker 1>each package, track what changes, and even parallel test new

263
00:14:28.480 --> 00:14:31.759
<v Speaker 1>features before merging them. This is the kind of operational

264
00:14:31.759 --> 00:14:35.200
<v Speaker 1>discipline that until now often felt out of reach for

265
00:14:35.480 --> 00:14:38.799
<v Speaker 1>power platform teams. One overlook benefit is that you start

266
00:14:38.840 --> 00:14:41.960
<v Speaker 1>treating every piece, every app, plugin and connector as a

267
00:14:41.960 --> 00:14:44.799
<v Speaker 1>component with a real life cycle. No more rewriting logic

268
00:14:44.879 --> 00:14:47.559
<v Speaker 1>for every environment. If you need to apply a patch,

269
00:14:47.759 --> 00:14:50.399
<v Speaker 1>you update the solution, increment the version, and push it

270
00:14:50.799 --> 00:14:54.759
<v Speaker 1>nomenal copy pasta. This prevents drift where dev and prod

271
00:14:54.799 --> 00:14:58.080
<v Speaker 1>slowly become two different things, each with its own undocumented tweaks.

272
00:14:58.559 --> 00:15:02.320
<v Speaker 1>Over time, your platform becomes a set of reusable modules,

273
00:15:02.360 --> 00:15:05.759
<v Speaker 1>not a pile of half connected scripts. There's data to

274
00:15:05.799 --> 00:15:08.639
<v Speaker 1>back this up. Research and surveys point out that teams

275
00:15:08.639 --> 00:15:13.879
<v Speaker 1>who adopt formal solution packaging spend significantly less time troubleshooting deployments.

276
00:15:14.360 --> 00:15:17.039
<v Speaker 1>They move faster when building that new features because they

277
00:15:17.039 --> 00:15:20.519
<v Speaker 1>aren't cleaning up last week's migration mess. And that's where

278
00:15:20.559 --> 00:15:24.039
<v Speaker 1>you start to see the payoff, shipping more often, with

279
00:15:24.159 --> 00:15:27.919
<v Speaker 1>less stress and fewer late nights spent debugging invisible issues.

280
00:15:28.279 --> 00:15:30.759
<v Speaker 1>Once you hit that groove, it's hard to go back

281
00:15:30.759 --> 00:15:34.240
<v Speaker 1>to the portal's export import routine. You realize how much

282
00:15:34.320 --> 00:15:39.200
<v Speaker 1>time you wasted on manual deployment steps, copying, reviewing, double checking,

283
00:15:39.279 --> 00:15:43.200
<v Speaker 1>and hoping nothing fell through the cracks. The CLI turns

284
00:15:43.440 --> 00:15:47.240
<v Speaker 1>solution packaging into a routine, testable part of your workflow.

285
00:15:47.720 --> 00:15:50.559
<v Speaker 1>Your only regret might be not setting it up sooner,

286
00:15:50.759 --> 00:15:54.720
<v Speaker 1>especially as you see how reusable managed assets reduce those

287
00:15:54.759 --> 00:15:59.039
<v Speaker 1>it worked yesterday mysteries. So with solution packaging now squared away,

288
00:15:59.200 --> 00:16:03.759
<v Speaker 1>the real fun begins. Handling plugins and smooth automated deployments.

289
00:16:03.879 --> 00:16:07.759
<v Speaker 1>This is where packcli goes beyond merely moving assets. It

290
00:16:07.919 --> 00:16:12.320
<v Speaker 1>unlocks automation and true CIICD that brings power Platform in

291
00:16:12.360 --> 00:16:17.159
<v Speaker 1>line with serious DevOps practices. Automation and plug in deployment

292
00:16:17.240 --> 00:16:21.039
<v Speaker 1>the missing link in DevOps. You've packaged your solution, everything

293
00:16:21.080 --> 00:16:23.720
<v Speaker 1>looks tidy, and you're ready to ship that need bundle

294
00:16:23.759 --> 00:16:26.440
<v Speaker 1>to a new environment. But if you've worked with power

295
00:16:26.480 --> 00:16:28.679
<v Speaker 1>Platform for any amount of time, you know the easy

296
00:16:28.720 --> 00:16:32.240
<v Speaker 1>part is over. The roadblock comes when plugins are involved,

297
00:16:32.519 --> 00:16:36.279
<v Speaker 1>custom server side logic that quietly powers your most important

298
00:16:36.279 --> 00:16:39.159
<v Speaker 1>business rules. A lot of folks still depend on the

299
00:16:39.200 --> 00:16:43.440
<v Speaker 1>maker Portals UI to register these plugins. It seems manageable

300
00:16:43.480 --> 00:16:46.279
<v Speaker 1>while your project is small. You open the web page,

301
00:16:46.399 --> 00:16:48.919
<v Speaker 1>upload the DLL, fill in some basic details, and hope

302
00:16:48.960 --> 00:16:52.679
<v Speaker 1>nothing gets lost in translation. But that security quickly evaporates

303
00:16:52.720 --> 00:16:56.519
<v Speaker 1>as soon as you need to update, troubleshoot, or even worse,

304
00:16:56.679 --> 00:16:59.519
<v Speaker 1>roll back a change. After something goes sideways in production.

305
00:17:00.120 --> 00:17:04.240
<v Speaker 1>Suddenly that comfortable point and click workflow falls apart. You

306
00:17:04.319 --> 00:17:07.079
<v Speaker 1>end up crossing your fingers repeating steps with no guarantee

307
00:17:07.079 --> 00:17:09.839
<v Speaker 1>that the plugin in production matches what's actually running in

308
00:17:09.920 --> 00:17:12.839
<v Speaker 1>dev or that anyone can even figure out which version

309
00:17:12.920 --> 00:17:17.039
<v Speaker 1>is live. Here's where packcli quietly rewrites the whole deployment story.

310
00:17:17.160 --> 00:17:19.720
<v Speaker 1>The command line isn't just a convenience, it's an equalizer.

311
00:17:20.119 --> 00:17:23.119
<v Speaker 1>With packsili, you're no longer tied to one off manual uploads.

312
00:17:23.559 --> 00:17:26.319
<v Speaker 1>You can script plugin registration end to end so that

313
00:17:26.359 --> 00:17:30.079
<v Speaker 1>the same build steps run every single time. Picture deploying

314
00:17:30.079 --> 00:17:33.400
<v Speaker 1>a custom plugin for lead assignment logic across dev, test

315
00:17:33.480 --> 00:17:37.119
<v Speaker 1>and PROD without redoing every field by hand. With peccli,

316
00:17:37.319 --> 00:17:40.960
<v Speaker 1>you use straightforward commands to register, update and even uninstalled

317
00:17:41.000 --> 00:17:44.359
<v Speaker 1>plug ins as part of your deployment pipeline. That shift

318
00:17:44.599 --> 00:17:47.920
<v Speaker 1>turns plug in deployment from a risky chore into a repeatable,

319
00:17:48.000 --> 00:17:51.119
<v Speaker 1>traceable process. The real trick is that you're able to

320
00:17:51.200 --> 00:17:55.160
<v Speaker 1>roll changes out, validate them in lower environments, and if

321
00:17:55.200 --> 00:17:58.000
<v Speaker 1>something isn't right, run the same script to revert or patch.

322
00:17:58.200 --> 00:18:00.519
<v Speaker 1>It's not glamorous work, but it's how you up worrying

323
00:18:00.559 --> 00:18:03.799
<v Speaker 1>about hidden mismatches and start building confidence with every release.

324
00:18:04.000 --> 00:18:07.319
<v Speaker 1>Let's walk through a scenario most teams have faced. Imagine

325
00:18:07.319 --> 00:18:10.200
<v Speaker 1>you've finished a new plug in, say something that autoscience

326
00:18:10.279 --> 00:18:12.799
<v Speaker 1>cases based on scores. If you link it into your

327
00:18:12.839 --> 00:18:16.079
<v Speaker 1>managed solution, then use packcli to pack up the solution

328
00:18:16.160 --> 00:18:19.480
<v Speaker 1>and register the DLL. Now you deploy to your sandbox environment.

329
00:18:19.640 --> 00:18:22.599
<v Speaker 1>If an error comes up during the registration, you actually

330
00:18:22.599 --> 00:18:26.640
<v Speaker 1>get meaningful logs. Instead of a generic registration failed toast

331
00:18:26.680 --> 00:18:30.279
<v Speaker 1>that the portal sometimes dishes out, packcli gives you a

332
00:18:30.279 --> 00:18:32.599
<v Speaker 1>full stack trace. Maybe you missed an interface or the

333
00:18:32.640 --> 00:18:35.880
<v Speaker 1>constructor isn't what's expected. The logs are detailed and easy

334
00:18:35.880 --> 00:18:38.720
<v Speaker 1>to parse, making root cause analysis a matter of minutes,

335
00:18:38.759 --> 00:18:42.440
<v Speaker 1>not hours. That's a shift instead of guessing what went wrong,

336
00:18:42.480 --> 00:18:45.119
<v Speaker 1>you own the deployment. The same commands that drive plug

337
00:18:45.119 --> 00:18:48.480
<v Speaker 1>in deployment locally can be plugged right into asure, DevOps

338
00:18:48.599 --> 00:18:52.240
<v Speaker 1>or GitHub actions. You build a pipeline where packcli does

339
00:18:52.279 --> 00:18:55.720
<v Speaker 1>the heavy lifting. It picks up your latest plugins, pushes

340
00:18:55.759 --> 00:18:59.279
<v Speaker 1>them to the right environment, and reports back when each

341
00:18:59.279 --> 00:19:02.920
<v Speaker 1>step finished. It's a pattern that saves teams real time,

342
00:19:03.200 --> 00:19:05.920
<v Speaker 1>not just in deployment, but in chasing down the inevitable

343
00:19:05.960 --> 00:19:09.839
<v Speaker 1>oops moment when a plugin breaks during a release. By

344
00:19:09.880 --> 00:19:12.680
<v Speaker 1>automating these steps, you lower the risk that someone will

345
00:19:12.720 --> 00:19:15.799
<v Speaker 1>miss a detail at two am or forget which dll

346
00:19:15.839 --> 00:19:18.519
<v Speaker 1>made it to In practice, you see fewer last minute

347
00:19:18.559 --> 00:19:22.240
<v Speaker 1>rescue missions and more uneventful releases where the tech just works.

348
00:19:22.400 --> 00:19:26.240
<v Speaker 1>There's another layer here that most portal heavy workflows don't

349
00:19:26.279 --> 00:19:30.480
<v Speaker 1>offer real systems thinking. Once you're using packcli as more

350
00:19:30.559 --> 00:19:32.799
<v Speaker 1>than just a point tool. When it becomes part of

351
00:19:32.839 --> 00:19:36.200
<v Speaker 1>your release pipeline, you stop treating every deployment as a

352
00:19:36.279 --> 00:19:40.160
<v Speaker 1>unique snowflake. Instead, you create a pipeline that runs the

353
00:19:40.160 --> 00:19:43.920
<v Speaker 1>same way for every environment and every release. You test

354
00:19:44.000 --> 00:19:48.200
<v Speaker 1>changes in isolation, move them through quality gates, and automate validation.

355
00:19:48.400 --> 00:19:50.319
<v Speaker 1>This kind of discipline is where you start to see

356
00:19:50.359 --> 00:19:53.880
<v Speaker 1>power platform function like a true software ecosystem instead of

357
00:19:53.920 --> 00:19:56.880
<v Speaker 1>a collection of one off hacks that only you and

358
00:19:56.920 --> 00:20:01.160
<v Speaker 1>your immediate teammates understand. The traceability that comes from automation

359
00:20:01.279 --> 00:20:05.160
<v Speaker 1>is a big win too. Packcli logs every action, what

360
00:20:05.400 --> 00:20:08.720
<v Speaker 1>was registered, when, and under which credentials. If you need

361
00:20:08.759 --> 00:20:11.440
<v Speaker 1>to audit a deployment, you have a record. If something

362
00:20:11.480 --> 00:20:14.680
<v Speaker 1>goes wrong, you follow the breadcrumbs instead of living with uncertainty.

363
00:20:15.000 --> 00:20:17.880
<v Speaker 1>Compare that to portal based moves, where the paper trail

364
00:20:17.960 --> 00:20:20.599
<v Speaker 1>is thin and you're never quite sure whether that last

365
00:20:20.640 --> 00:20:24.440
<v Speaker 1>safe timestamp tells the real story. For teams responsible for

366
00:20:24.480 --> 00:20:28.279
<v Speaker 1>regulated environments or large portfolios. Those logs aren't nice to have,

367
00:20:28.839 --> 00:20:34.039
<v Speaker 1>they're non negotiable. Compliance rollback and troubleshooting finally feel manageable

368
00:20:34.079 --> 00:20:38.119
<v Speaker 1>instead of intimidating. But it's not only about big enterprises

369
00:20:38.119 --> 00:20:42.559
<v Speaker 1>with sprawling teams. Packcli doesn't care if you're flying solo. Automation,

370
00:20:42.880 --> 00:20:46.480
<v Speaker 1>scripting and reusable pipelines level the playing field whether you're

371
00:20:46.720 --> 00:20:50.400
<v Speaker 1>the lone power apps champion, juggling multiple projects, or supporting

372
00:20:50.400 --> 00:20:54.960
<v Speaker 1>a global team. Even single developer shops get predictable deployments

373
00:20:55.119 --> 00:21:02.359
<v Speaker 1>and fewer fire drills, all without investing in heavyweight infrastructure. Basics, Repeatability, traceability,

374
00:21:02.400 --> 00:21:06.599
<v Speaker 1>and error proof packaging bring value no matter your scale.

375
00:21:07.240 --> 00:21:10.640
<v Speaker 1>Since packcli bakes these practices into day to day workflows,

376
00:21:10.680 --> 00:21:16.720
<v Speaker 1>it quietly elevates everything you do across the power platform stack. Applications, components, plugins,

377
00:21:16.799 --> 00:21:20.640
<v Speaker 1>each one becomes portable, auditible, and most importantly, not a

378
00:21:20.680 --> 00:21:23.400
<v Speaker 1>pain to update. With automation in place, you can focus

379
00:21:23.400 --> 00:21:26.839
<v Speaker 1>on building, confident that your releases aren't an experiment every time.

380
00:21:26.880 --> 00:21:29.240
<v Speaker 1>So once your automation game is up and running, the

381
00:21:29.319 --> 00:21:32.559
<v Speaker 1>final step is putting it all together, creating a power

382
00:21:32.559 --> 00:21:36.359
<v Speaker 1>platform environment that isn't just less chaotic, but is actually

383
00:21:36.400 --> 00:21:39.519
<v Speaker 1>built to grow with your needs and scale when new

384
00:21:39.599 --> 00:21:42.920
<v Speaker 1>projects land on your desk. If you look at every

385
00:21:42.960 --> 00:21:47.279
<v Speaker 1>power platform success story, speed is rarely the long term advantage.

386
00:21:47.480 --> 00:21:51.079
<v Speaker 1>It's about making sure every part of your ecosystem survives change,

387
00:21:51.279 --> 00:21:54.400
<v Speaker 1>whether you're responding to new business asks or patching a

388
00:21:54.400 --> 00:21:57.319
<v Speaker 1>bug that just popped up. Packcli is quietly the difference

389
00:21:57.319 --> 00:22:00.920
<v Speaker 1>between building quick prototypes and architecting something that lasts. You're

390
00:22:00.960 --> 00:22:03.519
<v Speaker 1>not just saving time, You're stacking the deck in your

391
00:22:03.519 --> 00:22:06.519
<v Speaker 1>favor so your work doesn't fall apart during the next

392
00:22:06.559 --> 00:22:09.640
<v Speaker 1>migration or audit. If you actually want more control and

393
00:22:09.720 --> 00:22:13.319
<v Speaker 1>less firefighting, paccli is where you plant that flag. Try

394
00:22:13.319 --> 00:22:14.119
<v Speaker 1>scripting and see