01AUG2019: I reference and use a number of community tools in this post and in the video. The PowerApps team has been cranking out new tools to enable less dependency on community tools to accomplish these scenarios. See:
Hopefully it will be relatively clear where the tools above can replace some of the things I show in the video. This post is getting a little dated and the “updates” are getting harder to follow as PowerApps & Flow features and experiences to support this scenario improve. I have every intent to build a fresh set of videos when I can carve some time out to do so. For now, hopefully the updates help connect the dots.
11APR2019: Version 220.127.116.11 of the CoreTools now has basic support for Canvas apps & Flow. However, this feature is still in preview as of this update.
11MAR2019: Canvas PowerApps & Flow are have limited solution packaging capability in preview today. They don’t work with the solution packager tool as of this post update. These capabilities are targeted to be Generally Available in June of 2019. See this page for details on the features and this page for timing (subject to change…check back often).
26SEP2018: I have updated the title of this post to reflect the announcements here and here sharing that canvas PowerApps & Flow are now included in the same solution packaging I describe in this post. This post and video still only go through the process with the Common Data Service, model-driven PowerApps, and Dynamics 365 CE extensions. While I haven’t gotten around to updating the videos, and some of the maker experiences have changed, hopefully this post can still serve as a guide to help you understand the fundamentals of how to do this with canvas PowerApps & Flow. You might have to connect the dots a little, but until I can to more meaningful updates for this blog post and video, I wanted to make sure the “Oh, I can do this now with canvas PowerApps and Flow now too!” lightbulb goes off. HTH
Most people who build applications have used some sort of source control system. Source control has become the de-facto way to keep track of changes as an application evolves. I often find that people think they have to give up the well understood benefits of source control when adopting a no-code/low-code rapid application development platform. Well, if you are creating a model-driven app using PowerApps and the Common Data Service, you don’t. You can achieve the same granular level of visibility into changes in your application, over time, you get with traditional source code. In fact, I wrote a blog post and video walkthrough about this very topic well over 6 years ago:
Back then we were still calling it XRM. Heck, just a few weeks ago it was still called XRM by those who associate with the term. It will likely be called XRM, out of habit, for some time still. Nonetheless, moving forward, it’s PowerApps and specifically the model-driven type which require the Common Data Service today. If that hasn’t quite sunk in yet, head over to the announcement:
While just about everything in my video from 6+ years ago can be done today, there are community tools out there which make the process much more efficient, therefore making the individual executing the process more productive. Which, of course, makes the whole idea more approachable. The two community tools that I am most fond of for this are spkl and D365 Developer Extensions. However, I am finding that spkl and the D365 Developer Extensions aren’t as commonly known in the community as perhaps they should be. Based on some feedback I’ve recently received on the general topic, I decided to create a new video demonstrating how go from zero to full source control of a Common Data Service based app using spkl and the Visual Studio IDE. If there is enough interest, I can record a similar video for the D365 Developer Extensions. The general flow of the video would be the same, but the mechanics of using each extension within Visual Studio will be a bit different.