Over the years, this blog has been about many different things related to software development with Microsoft technologies. Since my current role focuses on PowerApps & Flow, that's what it's primarily about right now.
“It’s just a database as a service, right? Why wouldn’t I just put my data in SharePoint or MySQL or SQL Server or…”
This is a conversation I’ve had so many times in the XRM days. Some day, I will be able to stop explaining that model-driven PowerApps run on the Common Data Service for Apps (CDS) and it’s the evolution of what we used to call XRM. Name changes are hard. Coincidentally, I just had a great conversation with @rappen and @ddlabar about this very topic on the XrmToolCast:
Just in case you are interested in the conversation (shameless plug, I know). But I digress.
The video below is how I typically talk to people about CDS to try to help them better understand what CDS is and why they might want to consider using it to build business applications. The video assumes you already know Power Platform fundamentals. It assumes you know the differences between canvas apps, model-driven apps, Flow, and CDS, but haven’t quite had that “lightbulb moment” when it comes to answering the question “Why CDS?”. Hopefully this helps. YMMV.
Scenario: ”I am building a canvas PowerApp. The connector I am using doesn’t do exactly what I want it to do. However, I know the connector uses a REST API secured by Azure AD. Can I call the REST API directly?”
The answer, as of this post, is that you cannot call the REST API directly from a canvas PowerApp (as far as I know). However, two new features were recently introduced that enables some really powerful integration between PowerApps and Flow:
When you combine these two features, it opens a whole new world of repeatable logic execution from PowerApps. If you drop an HTTP with Azure AD connector in between, you now have full control over your REST API call. Here’s a quick walkthrough of all this in action:
One of the most common questions I have been asked over the years (and still am today) about extending model-driven PowerApps / Dynamics 365 CE with html and JavaScript is:
“What’s the most productive way to develop and debug Dynamics 365 (and now model-driven PowerApps) web resources?”
The answer to that question will certainly be different depending on who you ask. Any answer to this question is subjective. There are lots of code editors out there that allow you to edit the various file types supported by web resources (html and JavaScript being the most common). There are lots of helpful tools available that could be leveraged in different ways to answer this question (some from Microsoft, many created by members of the community). I’ve tried lots of approaches over the years. If you’ve come across any of my older blog posts or videos on the topic, then you’ve probably seen some of them. When I show people my current preferred approach, most generally agree that it is more productive than what they are currently doing. The video below is a comprehensive walkthrough of my my current approach. As you will see in the video, at the time of this post, my toolchain is Visual Studio 2017, a must have (in my opinion) Visual Studio extension from Jason Lattimer called D365 Developer Extensions, and Fiddler.
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: https://powerapps.microsoft.com/en-us/blog/automate-your-application-lifecycle-management-alm-with-powerapps-build-tools-preview/ 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 9.0.3.1 of the CoreTools now has basic support for Canvas apps & Flow. However, this feature is still in preview as 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. I’ve also changed the title to use “Azure DevOps” instead of VSTS per the name change announced here. This post and video still only go through the process with the Common Data Service, model-driven PowerApps, and Dynamics 365 CE extensions using the old VSTS. While I haven’t gotten around to updating the videos, and some of the 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 using Azure DevOps. 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
The second video won’t make as much sense if you don’t watch the first video. In this video, I build on the work I did to get a model-drivenPowerApp (the artist formerly known as XRM…as I like to say) into source control by showing how to enable deployment automation using Package Deployer, including setting up initial data using the Configuration Migration tool. Then, I show you how to use Visual Studio Team Services (VSTS) to build all the assets in source control into their deployable form. Finally, I show you how to then use VSTS to automate the deployment of those assets to one or many environments. One of the things I highlight in the video is the Dynamics 365 Build Tools on the Visual Studio Team Services Marketplace. These tasks greatly improve the productivity of using VSTS with Dynamics 365 & the Common Data Service.
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: https://powerapps.microsoft.com/en-us/blog/automate-your-application-lifecycle-management-alm-with-powerapps-build-tools-preview/ 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 9.0.3.1 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: https://blogs.msdn.microsoft.com/devkeydet/2012/09/19/crm-2011-visual-studio-and-source-control-of-non-code-customizations/
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: https://powerapps.microsoft.com/en-us/blog/powerapps-spring-announce/
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.
Scenario: ”I want to secure an Azure Function using Azure Active Directory (AAD) and call it from a PowerApp using a custom connector. There are a few different docs out there that can help me figure it out. However, I haven’t found anything that shows how to do it beginning to end.”
While the info in this documentation is the bulk of the work:
It is written to be more generic and broadly applicable. It doesn’t cover Azure Functions specifically. Nor does it show you how to establish the PowerApps custom connector. So I pieced together what I know about Azure Functions and how you can enable AAD authentication using:
If you read What’s new for developers in Dynamics 365 (online), version 9, you’ll come across a new WebHooks integration feature. When you combine this feature with Azure Functions you get a pretty powerful combination. Since I’m a big fan of watching videos vs reading docs, I decided to put together a quick walkthrough of what the docs explain plus add act of wiring up to an Azure Function. An activity the docs suggest, but leave to the reader to figure out how to do.
I’m familiar with TypeScript, but not quite sure how to apply my knowledge to start using it with Dynamics 365. How do I get started?
I’ve been asked this a few times. I didn’t find anything out there (or my search skills are failing me) that was an end to end walkthrough. I found a bunch of stuff that, once reviewed, one could figure it out, arguably with significant trial and error. So I decided to put together a little walkthrough of how I do it.
In the video, I use some extensions to Visual Studio and NuGet packages. Here are links to the ones I mention:
I’ve recently switched back to focusing on Dynamics 365 after some time focusing on Azure again. Back to the future. My team and I have been working on an effort to move all of our Dynamics 365 (and in some cases Azure) based demos, Proof of Concepts (POCs), samples, etc. into Visual Studio Team Services (VSTS), and “rub a little devops on them”. In the process, we’ve learned a lot (and continue to learn) how to best apply build automation and deployment (amongst other DevOps concepts) to Dynamics 365 applications. We’ve had a chance to use great community projects like https://github.com/WaelHamze/xrm-ci-framework which provide (amongst other things) Dynamics 365 VSTS tasks and https://github.com/scottdurow/SparkleXrm/wiki/spkl. In the process, we’ve had the opportunity to contribute back to both.
What became apparent, very quickly, is that we needed to share what we learn with the rest of the community. In an effort to do so, we started https://github.com/devkeydet/dyn365-ce-devops. I welcome you to review what we’ve put together so far. Even better provide us feedback. Try it out and file bugs. Suggest better ways to document what we’ve done. Tell us how to improve the base templates. Suggest additional templates / scenarios. Really, tell us anything you think that will make what we’ve started better for others. Please do so by submitting issues. We will triage the issues and prioritize accordingly.
We’re intentionally *not* trying to boil the ocean here or over engineer the idea. We’re building small and evolving as the community of people who are interested in the project grow and provide feedback. The project will head in the direction that the community takes it. Thanks!
Gold Coast 