When you’re building an app in the Common Data Service for Apps, how do you keep it secure?
I was digging around for answers to a customer question on the docs.com site when I ran across something that made me stop in my tracks. If you’re planning on making a model-driven PowerApp, you should pay attention.
Microsoft offers a minimum privilege security role that you can import to your environment and build upon for your app.
You might be wondering: Why should I leverage this when making an app?
PowerApps harness the world-class identity management and security provided through Azure & Office 365, while offering it though an easy to configure and deploy interface for your own app. If you’re an app maker, you don’t need to understand the mechanics of managing database security, tracking activity, and offering single-sign-on to users. The PowerApps platform, backed by the Common Data Service for Apps takes care of the heavy lifting for you.
The part you’re responsible for is to set up security definitions based on what you want your app to do. This is where the minimum privilege security role makes life easy. It’s a starting point with all of the basic level permissions that let a user log into an app, navigate, and use core actions and capabilities that are shared across apps.
From there, you add incremental privileges to a copy of that. For instance, a standard user may only be able to see and modify their own records, while a manager may be able to see and modify the records of everyone on the team.
Previous methods have existed to do this same thing, the most common two being:
The first one is the approach I’ve preferred in the past, but it takes extra work to make sure you remove every little dependency to the Sales app. Suppose you want to deploy to an environment where Sales isn’t deployed.
The second app is less and less viable as the Common Data Service and PowerApps platform stand more on their own, separate from the 1st party apps. Frankly, unless a user is going to leverage capabilities that are part of the 1st party apps it’s tough to assume users will be assigned one of the out of the box security roles. Are you willing to make that assumption?
I was having a discussion with a colleague about a community project we’re working on to build out some capabilities to extend the Health Accelerator. He was asking why we’d include security roles with our solution, since customers can tailor security for their deployment anyway.
The discussion we got into was on driving a quicker and easier deployment of the solution. Sure, an administrator (or partner) could analyze the specific needs for their deployment and tailor roles…in fact, they still can. But what about the customer that wants to install and get going right away?
By having these predefined security roles, customers can install and test the solution with minimal up-front work–without impacting their ability to tailor later. These predefined roles also serve as a template for basic user types (like those of the Dynamics 365 1st party apps like Sales, Service, etc.).
If you’ve read this far, it’s time to get hands-on.
My latest canvas PowerApps creation provides a streamlined interface for managing “technical close plan” records in Dynamics 365 (set of configured entities associated with Opportunities). I built this app for myself and my peers to spend less time navigating between screens when building out our close plans so that we could have timely and accurate close plans visible to the whole pursuit team.
I estimate a time savings of a few minutes per deal per week. Over time that really adds up. Also, there’s a great peace of mind that I get personally knowing that I’m on top of it.
The only trouble is, I typically work with records inside of Dynamics, and didn’t want to have to jump out to a new browser window (or grab my phone), open the PowerApp, search for the specific record, etc.. That would chew into the time savings too much for my liking.
Unfortunately, both of those assume you have System Customizer or Administrator access to the environment. That’d be a great way to go, but I’m just a regular old user this time—and I don’t have an “in” with the admin either.
I didn’t want to recreate the saved Opportunity lists (system and personal views)…because I’m not a fan of reinventing the wheel inside of my apps, especially when I’m using the Dynamics 365 or CDS connector.
So I built my PowerApp with the assumption that I would spoon-feed in a specific Opportunity record through some other means (with some TBD level of automation).
“What’s a bookmarklet?” You know what a bookmark is in your browser: click a link and go to a website. A bookmarklet looks like the same thing, except when you click, it runs a little script to do something.
In my case, the bookmarklet finds the record GUID based the page I have open, then opens my PowerApp in a new window and passes in that GUID as a parameter.
I couldn’t find something readymade, but I did borrow the script to get the GUID. Big thanks to Benjamin John, who published a couple of blogs with a bunch of Dynamics 365 bookmarklets.
When the PowerApp is launched, specifically when the first screen loads, I use a function to check for the parameter and store it as a global variable:
The second function (the If… after the “;”) checks to see if the parameter was there and the app navigates to the details screen. There are a bunch of ways to do this, so I picked one that’s overly complicated but fun to look at. Oh the joyous freedoms of being a Citizen Developer 😉
All in all, this was a couple of hours from initial research to final product and it’s already saved me a bunch of time in accessing the right record from my PowerApp. It also made me think back to a time before I had Admin privileges in most environments I touch. That’s a fun and creative part of the problem-solving brain that I was happy to say hello to again.
Your first question might be “what is docs.com?” and that’s fair. You may have heard of docs.microsoft.com, which is what it redirects to (or maybe you already figured that out by typing it in your own browser…).
Over the course of the last year (?) Microsoft has made a very notable push to consolidate their public-facing documentation all to the docs.microsoft.com site–and I love it! These are the top reasons I’m a big fan.
Part of good reference documentation is that it isn’t radically different from one product to the next–especially in the case of the Microsoft clouds of Azure, Business Applications, and Office 365 where the products are engineered to work with each other. Having consistency across these helps connect that experience. A few places this is evident includes:
It seems to me like there’s been a significant effort to make this site SEO-friendly (SEO-focused?). I get high-ranking hits of this documentation using the major search providers–which is great considering how fresh much of the content is.
Within the site, the outline (navigation) for each item includes search (if you’re trying to find something within this logical area, with the top-level search just a click away.
This same documentation used to be scattered around a bunch of product specific pages, TechNet articles, MSDN, product manuals, separate roadmap sites, “official” community sites (and probably more).
Now it doesn’t take heroic efforts to track this stuff down. Resources for end users, admins, IT pros, and developers are all here–which is especially great since so many people who would go looking for this don’t fall neatly into just one of those buckets. A huge amount of content is out there already, with some still pointing to old articles (that are being ported and retired).
Every page has the date stamp right at the top of the page, giving a quick heads up as to how fresh the content is or when it may have last been reviewed. In this same area it calls out the people who have contributed to writing the page as well, which for some reason just feels good to remember there are real human beings behind the updates 🙂
I also find it interesting that all of the documentation is written in Markdown and maintained on GitHub repositories. It’s very open to be able to see edit history, publishing over time, and all sorts of other stuff out there.
To anyone building model-driven PowerApps, Dynamics 365 for Customer Engagement, or the Common Data Service for Apps, XRM Toolbox needs to be your friend. In a recent Implement This podcast episode I discussed a couple of favorite tools in the toolbox.
Specifically we talk about:
View the full show notes (and the video I mention) at implementthis.org
Recently Britta and I recorded and released a podcast episode about “cascade rules” behavior. When building relationships between entities in the Common Data Service, these settings influence the behavior of visibility, assignment, and other system capabilities.
This capability can be leveraged when building model-driven PowerApps and extending Dynamics 365 Customer Engagement.
View the full episode show notes at implementthis.org
At a local Dynamics-team meeting, we had a healthy discussion about Microsoft Flow and its fit for business applications as a cross-platform workflow engine. I've been a long-time user of If This Then That (IFTTT) and I'm excited at the prospects of having this kind of service-connecting tool right here within the Microsoft toolset. It shows the embracing of Connecting the Data with 3rd party services(if you will indulge me), without having to rely on custom code 🙂
Coming out of that meeting, Britta and I wished that the discussion had been recorded. It wasn't. But we put our heads together to outline the topics that were covered and discussed them on this episode of our podcast Implement This. The content is still relevant
You can listen at the top of this post, or click through to the episode on our website.
The Dynamics 365 Workflow engine, which is the behind-the-scenes part of the process engine, is massively powerful. For host Britta Rekstad, who has presented on how to use Dynamics workflow at multiple conferences, this is an absolutely critical aspect of the platform for new admins to understand.
Co-host Matthew C. Anderson shares about how some of his early experiences in configuring Dynamics 365 involved workflow. This experience also included a spoken agreement to be careful as the workflow engine (used without care) can cause some pain for other users and admins alike.
We seem to have different perspectives on using the workflow engine, however, there’s no disagreement on how important and powerful this tool is when implementing Dynamics 365. A very flexible tool, this part of the process engine sits out-of-sight to most users but serves an important role.
Have a question you’d like answered on a future podcast? Submit one by visiting implementthis.org
Joel and I revisit our discussion about productivity tools. This time we discuss:
Have you ever had a situation where a little delay makes the difference between an “important request” and “never mind…”? Joel and I talk about walking that fine line on using procrastination as a tool to see whether some tasks may not be worth acting on ASAP.