Jukka Niiranen

Tag: security

  • Share links with access to records in Model-driven Power Apps

    Share links with access to records in Model-driven Power Apps

    Microsoft has been working towards a unified sharing experience across their cloud products. The dialogs that many are using today in Microsoft 365 services like SharePoint and OneDrive for sharing access to files is also finding its way to Power Platform.

    The visible UI in a sharing dialog is only one part of the experience. Knowing what the traditional sharing experience for Dataverse records has been in Dynamics 365 and what the underlying security model consists of, the new direction can present a few surprises for app makers and admins.

    For example: did you know that a user without any visible security role may be able to read the data of certain Dataverse records? Wow! That goes against everything we’ve learned about security modelling in the good ol’ XRM era. Sounds like something worth investigating a bit deeper then.

    Enabling the sharing links

    Since the new sharing functionality can have a big impact on the security model of your business apps, this capability needs to be consciously enabled by the administrator. I haven’t yet come across the official Docs materials for the feature. Presumably this page is where the details will eventually be published. For now, this blog post is based on my experiments of what you need to have in place (by minimum).

    First, you need to enable the collaboration feature in the environment settings via Power Platform Admin Center (PPAC):

    Next, you should go to the Privacy + Security page of the same environment and switch “enable sharing” to on:

    As the message says, this should “allow users to share read-only links to records with other users from this environment.” I managed to get this working in a couple of different environments in our tenants, yet another demo tenant in the same European geo refused to co-operate. So, don’t be surprised if you see different results in your environments at this point.

    The link sharing experience

    Now that the features are turned on via PPAC, you should be able to go to a record like an account in a model-driven Power App and discover the new sharing menu in the top right corner of the form. Selecting “copy link” will give you a standard link that is the exact same URL as you’d get from the browser’s address bar. That’s because it’s meant for “people with existing access”.

    Once you click on the chevron and explore the link settings, there should be more options available (assuming the environment settings applied earlier have taken effect). Let’s select the “people in your organization with the link” option this time:

    Now we get a URL that is appended with parameters “shareLink” and “sig”. These are the magic keys to authorize someone who does NOT have existing access to the record in Dataverse.

    To validate how the feature actually works, I used our sandbox tenant’s user account FF App User as the guinea pig. First, as an administrator I went and removed any existing security roles for this user from the environment. Then I ran the diagnostics test from the user list in PPAC. A warning was displayed, saying “this user doesn’t have any security roles assigned directly to them”. Looks perfect for our testing purposes.

    (I actually also removed the license, yet that didn’t get flagged in the diagnostics test. Oh well, we all know how mysterious the license assignment and validation in Power Platform can be, so let’s ignore it this time.)

    Opening the naked URL of the Power Platform environment with this user account resulted in a screen saying “we can’t find any apps for your role”. Under normal circumstances, this would be the end of the road for a user.

    This user has a special trick up his sleeve, though: the sharing link with the secret access code parameters. Using it allows us to open the account form outside any Model-driven app module. Yes, it’s read-only as the feature’s description text suggested, but from a viewing perspective this record form seems fully functional.

    How far do the sharing rights go?

    If we’d go back to our admin user’s profile and re-run the user diagnostics in PPAC, we’d see that there still aren’t any security roles assigned for the FF App User. Let’s visit the sharing dialog of the single record instead and go to “manage access”.

    This screen shows us that we have one sharing link generated for the account in question, with read permissions. Also, since FF App User has accessed the record via the link, the user account is listed under “shared with”.

    Time to go deeper still, so let’s open XrmToolBox. Using the Access Checker plugin, we can run a test for the specific account record and the specific user account. We do indeed see that when called via the API, the user has both read and share privileges for this record:

    Could we find out even more about how the privileges are applied? Sure! Another plugin in XrmToolBox, “Your User Security – Magnified”, gives us a very interesting output for the FF App User account:

    As many of you know, there are plenty of system metadata tables (entities) that the user must be able to read for the application to function properly. Things like “attribute” or “user” are therefore understandably opened up for the FF App User account upon sharing the record.

    There are plenty of real business tables listed in that output, too. Contact and activity, for example. While the privileges are granted only in the user’s scope (meaning only records that the user is an owner of), this made me go back and think: what else did we see on the account form when we opened that one record?

    Activities related to the account show up on the timeline. In addition, we’re able to navigate to their forms. We do also see the primary field values of anything that’s in a lookup, such as the regarding opportunity name.

    Clicking on lookups, such as the contacts that are activity parties, will show an error message on missing read access rights. So, the security model is still enforced as expected, meaning we couldn’t just navigate via links to other records. It’s not just the lack of a surrounding app and its navigation that is missing from this user, there’s access checks also on the server side of course.

    It’s good to keep in mind that the modern collaboration features are currently enabled only for certain tables: account, contact, opportunity, case. There may be more configuration options ahead for how the sharing links work once the feature reaches general availability.

    Sharing within Microsoft Teams

    The primary scenario that these internal sharing links have surely been designed for is collaboration within Teams. Already back in July 2021 it was announced by Satya Nadella that “Teams customers will receive access to Dynamics 365 data within Teams at no extra cost.” We’ve been waiting for that possibility to arrive ever since.

    Given how the concept of sharing access to data has been radically different between a document world like SharePoint and a business record world like Dynamics 365, there has understandably been a lot of work needed to be done on the platform side. Now that the share links infrastructure appears to be in place, are we ready for the collaborative apps story to come to life?

    Although the sharing capabilities are a Power Apps feature, there doesn’t yet appear to be the needed pieces in place on the Teams side for any low-code apps to take advantage of record sharing. However, if we test the sharing links in a Dynamics 365 enabled environment and with the Dynamics 365 Teams app deployed for the user, things start to light up:

    Pasting the link into a Teams chat will now unfurl the contents and show an information card preview of the record. We also get the option to view the full record in the context of Teams, via the “view details” button. These are small yet important steps in allowing people to get work done within the platform that is Microsoft Teams, without needing to look for the details in another browser window.

    We’re still missing some of the elements showed by Microsoft as part of their collaborative apps story, like Context IQ for at-mentioning a Dataverse record or Loop components to embed live data into messages in Teams or Outlook. While we wait for a delivery timeline on those elements, at least this easy record sharing feature in Power Apps model-driven apps has a target GA date for September 2022.

  • Did Power Apps really leak your customer data?

    Did Power Apps really leak your customer data?

    Recently Power Apps made the headlines in a way that Microsoft would have liked to avoid at all cost:

    The news headlines today aren’t exactly the most neutral source of information, but luckily we also have access to the full report from the security research team at UpGuard. Here’s what happened according to them:

    The UpGuard Research team can now disclose multiple data leaks resulting from Microsoft Power Apps portals configured to allow public access – a new vector of data exposure. The types of data varied between portals, including personal information used for COVID-19 contact tracing, COVID-19 vaccination appointments, social security numbers for job applicants, employee IDs, and millions of names and email addresses.

    UpGuard

    Sounds serious, and it certainly shouldn’t be sweapt under the rug by anyone working with Microsoft Power Platform. We have a lot to learn from an incident like this and the concerns it may bring up along with it. As these low-code technologies become more widely used across different industries, not all publicity will be positive.

    There have of course been some concerns raised by IT practitioners already before this Portals incident on what’s the general impact that low-code platforms will have on business solutions development. How to secure customer data and to build proper governance practices around these tools is a topic that is often covered when talking about Power Platform with customers.

    I personally already used the above headline as an example in a governance workshop with a customer on the very next day after the report was published. The discussion was quite neutral and it served well in acknowledging both the important role that Power Platform tools can have in business processes, as well as the need for practices that allow them to be safely used in developing new solutions.

    The other alternative where such a topic would not be proactively addressed in a transparent manner could instead lead to more controversial reactions down the road. Some people may have negative experiences in their past that might lead to seeing these new events as an enforcement of their existing beliefs.

    It’s hard to prevent people from drawing the wrong conclusions based on incomplete information if we don’t bring all the relevant pieces into light. To help in such examination of the evidence, in this blog post I’ll present some fictitious statements that could potentially be made based on reading the news headlines. Then I’ll offer my own perspective on whether they would be justified or not.

    “Bugs in Microsoft’s software caused the data leak!”

    This wasn’t an actual bug, rather an unfortunate feature. As the report title from UpGuard hints, it was “by design” when examined from a technical perspective. Also, that was the initial response from Microsoft’s side, as shown in the report:

    The above response is in my opinion the biggest mistake from Microsoft in this whole incident. Being tone deaf when presented with something that had already proven to be a pattern leading to unintended disclosure of confidential customer data via numerous Power Apps Portals out there is… Well, it’s what happens in large corporations, unfortunately.

    What was this “by design” feature then? In the state that the Portals configuration experience was at the time of the investigation, there wasn’t any strong push from the product side to make the data tables used in the portal as private. It was a neutral platform built specifically to take records from your organization’s internal Dataverse tables into a public website, then giving you the choice to either show all the contents to anyone, or limit the visibility through a very granular security model to only a small subset of records.

    As an example: you could show all the available locations where COVID-19 vaccinations were being offered (public table). Then you’d give the logged in user the ability to create an appointment record (private table with access control). Both are an integral part of the business process managed via a portal, yet the rules for showing them to the website visitors are directly opposite. The technical platform has to cater to both these requirements.

    As it happened, there was a way through which the portal developer could forget to enable the table permissions that the private data should have in all areas where it was used. Now, the reason why this mistake wasn’t immediately obvious was that the Power Apps Portal product included a feature that allowed publishing this data as OData feeds. These would not be visible in the website pages necessarily, but they were technically available as long as you knew the right path from where to search for them.

    In our example, a public OData feed of locations could have been useful for integration purposes. For reservations made by private individuals, an unauthenticated feed would never be a good idea. Yet the platform didn’t know what the developer wanted.

    After this incident was reported by UpGuard, Microsoft changed the defaults and made it require more conscious effort to publish the feeds for unauthenticated consumption.

    “Poor default settings in the Portal product were dangerous!”

    There’s no denying that discovering more than a thousand Power Apps Portals misconfigured to expose confidential data to unauthenticated users is a big number. Yet the total number of Portals out there is… well, let’s just say it’s certainly multiple times that.

    As part of their research, UpGuard enumerated through the various available powerappsportals.com and microsoftcrmportals.com subdomains to programmatically scan the sites with potential unintended OData feeds published. Many were found through this method, but still this problem affected only a small subset of all Portals websites out there.

    The majority of Portals developers will have been aware of the setting that must be enabled for any data that you don’t want to be publicly available on your website. Nick Doelman explains the “Enable Table Permissions” setting very clearly in his excellent blog post. It’s not really fair to claim that this would have been impossible to notice while building your Portal app:

    If it has been news to you and you have built websites with Power Platform tools, then I seriously recommend you to take advantage of this generous offer by Nick and enroll for his Power Apps portals Security Deep Dive course:

    Update 2021-08-31: you should also check this video from George Doubinski about the Portals behaviour before & after the default setting change:

    “Microsoft should prevent such things from happening on their cloud service!”

    Power Platform is a suite of low-code tools that allows you to build your own apps. Whatever business logic the published app contains is ultimately the responsibility of the app creator. Same goes for the data you manage with that app. Technology providers can’t easily stop people from building unfit solutions with their products.

    There’s a great analogy in George Doubinski’s blog post “How to secure Power Apps portal from making the news” that I’ll repeat here. If you’re a company selling nail guns and a few unfortunate customers of yours shoot themselves in the foot – what should you do about it? Sure, your product probably came with all kinds of instruction manuals and warning signs that try to explain the importance of learning how to use such power tools. Similar to how Microsoft now shows a banner saying “table permissions should be enabled for this record or anyone on the internet can view the data”, to try and warn people not to hurt themselves.

    Let’s look at an example from another area of Power Platform that I cover frequently in my blog: licensing. Any customer could easily use this platform to build an automation that is a clear violation of the multiplexing rules of the very same platform’s licensing terms. Just create a Power Automate cloud flow that automatically pushes all new opportunities from your Dynamics 365 Enterprise Sales app into a SharePoint list accessible to your whole organization with no Dynamics licenses assigned to them. Congratulations, you’ve again used the powerful tool to hurt yourself in a way that the vendor couldn’t have stopped.

    “I knew citizen developers couldn’t be trusted to build real business applications. So much for low-code!”

    Did you look at the types of customers that suffered from this data leak? If not, I’ll list some of them from the UpGuard report here, to give perspective:

    • American Airlines
    • Ford
    • State of Indiana
    • New York City Municipal Transportation Authority
    • Microsoft

    These don’t sound exactly like the kind of organizations where a lone citizen developer who discovered a neat tool in his Office 365 app launcher just went ahead and built a portal on top of millions of rows of contact records and other sensitive data. If I had to guess, I’d assume there has been a proper development team working on many such customer facing services – not just citizens.

    The above picture is an example from the report’s contents that was captured via the unsecured OData feeds. It is from the Global Payroll Services Portal for Microsoft employees, built (presumably) by professionals working with software. Despite of all the resources and knowledge behind these, the misconfiguration of a Power Apps Portal still went into production sites.

    Although not directly related to this incident, on the very same week there was also another unfortunate data leak reported concerning the Microsoft cloud. Only this time it was around CosmosDB and the database primary keys that got leaked, exposing private data from thousands of Azure customer organizations. The misconfiguration seems to have been carried out by Microsoft software developers while they were integrating Jupyter Notebooks with CosmosDB to provide a new platform feature to customers.

    Regardless of whether you are clicking through low-code configuration pages or writing your own lines of custom code, mistakes can happen.

    “Suites like Power Platform are becoming way too complex for anyone to keep track of all these features & settings that can cause harm!”

    This is certainly true in the sense that a single person will not have an A-to-Z understanding of Power Apps in Canvas/Model-driven/Portals flavor, Power Automate in the cloud and on the desktop, Power Virtual Agent, Dataverse, AI Builder, Power BI and its data platform back-end… It’s way too much for anyone to consume as documentation, let alone master in practice.

    We should be asking where the assumption actually comes from that an app maker or developer should have end-to-end knowledge of the whole Microsoft low-code stack? Whether you’re a customer or a partner, it’s very important for you to not be blinded by all the flashy product demos and testimonials on “how company X digitally transformed themselves, using software suite ABC”. It doesn’t all happen thanks to this one mythical app hero who can take on any challenge – rather it’s the result of the right person finding the right tool to solve one specific problem at a time. Repeatedly, at scale.

    Low-code is a team sport and you will increasingly see the fusion development approach be promoted by Microsoft. This emphasizes the fact that an optimal mix of business domain expertise and technical software development skills is a better approach to achieving long term business value with low-code than relying on lone superheroes to do it all. In the end, just because you’re not writing as much code as earlier doesn’t mean the resulting systems would be simple:

    Low-code tools may be easy to approach, but the solutions you create with them can be as complex to manage as custom software.

    The data leak was the result of a feature built into the platform that the persons developing the customer specific solution were not aware of. They didn’t purposefully create the OData feeds, rather the software product generated them based on the underlying logic of how it was meant to streamline certain app development tasks. The best chances for having awareness of all these moving parts in the end solution is to ensure people have a realistic opportunity to focus on their primary tools and continuously sharpen their skills.

    “This incident proves you need product X / service Y from partner Z to be safe with Power Platform!”

    Events like these are bound to inspire companies working in the Microsoft ecosystem to try and gain exposure of their own by riding on the news wave. It never hurts to sprinkle a little FUD tactics on top of your marketing message, right?

    Now, I have to be transparent and admit right away that we are in the business where the questions and concerns coming from Microsoft customers are addressed via our advisory services. Even though we educate organizations on governance best practices and have delivered a few Power Apps Portals solutions to them, I would not make any statements like “buy from us and you’ll never have these kind of problems”. There’s two reasons for this:

    1. Our aim is to help customers take ownership of their digital tools, not to be the ones who build everything for them & maintain it. New app makers will make mistakes as they learn & grow, they just need a safe space for this (read: not a public website).
    2. I know how hard it would be to build a technical solution to audit every little detail that could go wrong in the various use cases where Power Platform is be used.

    Let’s examine the details of this particular data leak. First of all, to have any technical level protection, you would need a service that can tap into Power Apps Portals specifically. Running something that monitors only Canvas Apps or Model-driven Apps won’t help you here. Even the Power Platform Center of Excellence (CoE) Starter Kit from Microsoft only has the Portals data inventory as a backlog item as of now. If no public APIs are available to tap into a Microsoft cloud service, then you’re unlikely to find any software to do the required tricks for you.

    Even if we’d have the same level of telemetry data access as Canvas Apps do, what’s the likelihood of the specific setting in question (Enable Table Permissions) to be exposed and monitored? Well, it is data stored inside Dataverse tables and could be queried via Advanced Find as showed by Nick, so in retrospect we could technically have audit tools built for it. But why would someone built such a third-party product when Microsoft already offers Portal Checker to all customers?

    So, there’s unlikely to be an easy & all encompassing solution out there that would address all your Power Platform security and governance concerns. I could even bet that some of the Portals websites that suffered from the OData leak will have been reviewed by security professionals from outside the Microsoft ecosystem and still the issue was not discovered. Probably because they didn’t know where to look.

    Because it’s an ever evolving cloud platform, it was possible for Microsoft to quickly react to the incident via a change in their original design, as well as by notifying the customers potentially affected by it. Today the risk of unintentional data exposure is technically lower and the public awareness of such possible misconfiguration among the Power Platform app maker community is much higher.

    Yet we have no way to guarantee what will happen tomorrow. Something similar may be discovered in a different part of the platform that will again require attention and action. I think all we can really do is to keep our eyes open and be ready to learn from the new discoveries shared by the network around us.

  • CDS FAQ for the Power Apps Makers

    CDS FAQ for the Power Apps Makers

    Microsoft is commited to making Common Data Service the flagship data source for Power Apps scenarios, as well as delivering advanced enterprise application lifecycle management (ALM) features via CDS. What can make the role of CDS somewhat difficult to approach for app makers is the fact that it hasn’t originally been built for Power Apps, like CDS “v1.0” was. The current CDS “v2.0” is based on XRM, the business appliciation platform that was born alongside the Microsoft Dynamics CRM product.

    I’ve been working with this plaform technology for close to 15 years now, whereas the world of Power Apps Canvas apps (and Power Automate) is a much more recent acquaintance of mine. To put my experience into good use and to also learn to see things from outside the XRM walls, I decided to share answers to a few questions that I’ve heard from #PowerAddicts that are exploring the CDS world.

    Q1: Why should I use CDS as my data source instead of SharePoint or SQL Server?

    Because it is not just a data source. Yes, in Power Apps Canvas apps you do connect to it just like any other data source in the app Studio, but this is misleading. CDS is the complete platform that can orchestrate how your app works when it comes to business logic, security model, integration, administration, governance and many more areas. Compared to raw SQL Azure, the SQL relational data is actually just one of the storage types that CDS leverages behind the scenes. Ultimately it’s a bundle of the latest Microsoft cloud technology for compute, storage and eventing/extensibility – offered as a single service that you don’t have to configure nor manage. You consume it either via built-in integrations to Power Platform, Dynamics 365 and Office 365, or alternatively via an API that is automatically generated to match your customized schema.

    The topic of “why CDS” would easily warrant a whole series of extensive blog posts on its own, which I may well do later on, but not inside an FAQ like this. For now, I recommend that you watch this Ignite 2019 session from Ryan Jones to understand the big picture of Common Data Service:

    Q2: What’s the difference between the 2 connectors for Common Data Service?

    The current environment connector is a native connection. This is the misleading part. It’s not a real Connector at all, rather every Power App knows how to talk with the environment that hosts it, which essentially is the current CDS environment. This leads to numerous benefits in performance and available features, as the technical implementation behind the scenes is quite different. I haven’t come across a Power Apps specific comparison yet, but MVP Sara Lagerquist has done a thorough analysis of the two CDS Connectors in the Power Automate context.

    Q3: Is there any reason to use the non-current environment CDS connector then?

    Yes, if you want to connect to a CDS environment that’s not the one which is hosting your app configuration. Meaning, if there is busness data out there in another CDS database and you need to reference it in addition to the “native” data in your app’s environment, the old CDS Connector might well do the trick. However, this is an area to keep a close eye on for the detailed functionality over time, as MS is very much wanting everyone to “go current” and some issues might arise from remaining on the old Connector.

    Q4: Why should I use solutions for building my app functionality in CDS?

    Even if you’re working in just a single environment, building a simple app directly in production (which is what a citizen developer often might do), solutions offer you the logical grouping of elements that are part of your project. In fact, at some point MS experimented with changing the Maker UI to read “projects” instead of “solutions”, but luckily that change was reverted back. It can stil be a helpful concept to illustrate the purpose of solutions for those who aren’t familiar with CDS. The act of building an app needs to manifest itself somehow within the environment, so always start by creating at least one solution for your project. (Real life projects may well have more than one solution, thouh.)

    What solutions really are designed for is shipping the elements of applications into other environments, in a process that is easy to manage and possible to automate. Microsoft is aiming to make solutions the packaging story across all of Power Platform, which means it’s not an optional concept. It’s how things are built within this business application platform.

    Q5: I’ve read about this thing called “managed solutions”. When should I use them?

    There’s the saying “if you have to ask how much it costs, you can’t afford it”. In my opinion, this fits perfectly with managed solutions, too. Unless you are really, really well educated with how the solution system in CDS works (meaning you’ll probably have an XRM developer background), don’t touch managed solutions – yet.

    When delivering complex enterprise CRM systems with multiple full time developers writing custom code and leveraging Azure DevOps for automated CI/CD pipelines, managed solutions are the way to go. Similarly if you’re building an ISV app for many different customer organizations and hope to publish it on AppSource, you simply have to go managed. We’ll most likely see Microsoft making the managed solution concept more approachable for other audiences in the future, too, so please do educate yourself on their possibilities and get ready for building more complex apps at scale.

    Q6: Couldn’t I use managed solutions to lock down my app components from other makers?

    Yes, but not in the environment you’re probably working in right now. When building apps, you’re always working in unmanaged mode. It’s only when you export your solution from the current environment that you get a choice to make the solution package either managed or unmanaged. Shipping configurations from dev to test & prod is what this mechanism is for. If you only have a single environment for the app makers where the small departmental or personal productivity apps are built by citizen developers, none of this stuff applies to you.

    No. Don’t ever re-import the managed solution back to the environment where it came from. That’s locking yourself in and throwing away the key. It’s not what you want.

    Q7: Is there any other way to restrict specific entities to be only customizable by certain app makers if we’re working in a shared CDS environment?

    No. The metadata of CDS doesn’t have such security mechanism that would allow you to say that “Group A owns the account and contact entities, Group B is responsible for the project, task and resource allocation custom entities”. Within a single environment, there can be only one god, and that is the System Administrator. System Customizer also comes close, as both have the rights to create and delete new entities on a whim.

    Records stored within an entity always have an owner. An account is owned by User X, which can be used for determining what other users can do with it. The actual account entity i.e. the table that holds the records doesn’t have this type of ownership construct, as it applies only to data and not metadata. If you need more granluar control over metadata, then the answer is to set up different environments for the different groups.

    Q8: How can I see what privleges a particular user has been given in CDS?

    Security roles are a central construct in CDS, as everything you attempt to do in the database is verified against two key parameters before execution:

    1. Do you have rights for the specific action against the entity where the data is stored?
    2. Who is the owner of specific the record that you are trying to perform the action on and what’s the relationship to the calling user?

    The UI for security roles dates back to MS CRM v.X days and is scary both due to the legacy experience as well as the variety of options found in even a blank CDS org. Nevertheless, it is logical and will tell you what you need if you know what you’re searching for. Let’s compare 3 standard roles of Common Data Service User, Environment Maker and System Customizer and their privileges on the Customization tab:

    The CDS User has mostly just read access to the metdata, like Entity, Field, Option Set and so on. An Environment Maker is allowed to create new items like Canvas Apps & Model-driven Apps – like a Maker should. To actually create new Entities and Fields, you’ll need to be a System Customizer or Administrator.

    This is where the platform aspect of CDS (and its predecessor XRM) comes into play, though. You can create your own security roles, preferably via copying an existing system role that’s close enough. So, you could create a new “Environment Super Maker” that would have the right to create new fields, but not new entities, nor delete any fields. So, security roles are not only the gatekeeper to business data but also metadata.

    Q9: Looks like these security roles are environment specific. Do the IT admins really to go and manage the security settings via this MS CRM Power Apps UI?

    Not anymore! Last year Microsoft finally brought Azure AD integration into the system administration features of Dynamics 365 and thus CDS. You can now leverage the Group Teams to assign CDS security roles to an Azure Active Directory group (security or Office group) and the users will inherit the privileges of that role when added to the group.

    While Azure AD groups definitely streamline the administration process, please keep in mind that there’s more to CDS security model than just the security role assignment. Business Unit structures, Field Level Security, Hierarchical Security are some aspects that may require admin actions directly within the environment to get them set up properly.

    Q10: Why do all these user accounts from across the organization appear in the CDS environment meant for department X only? Can they all access it?

    You probably didn’t assign a security group to the CDS environment right at the start when it was created. Therefore every licensed user account in your tenant was copied over to the environment. If you assigned a security group to the environment after its creation, then those user accounts will be automatically disabled. They will forever remain in the database tables as inactive users, though, since user record deletion is not something XRM nor CDS has ever supported.

    Just because a user exists inside the CDS environment’t systemuser table doesn’t mean they can do anything in that environment. Not even if they haven’t yet been disabled. Everyone needs a security role to have a chance to read both the metadata and the business data from CDS, so the user record is just a prerequisite to opening the door to the environment but it doesn’t provide the key to the lock.

  • Highlights from TechDays Finland 2020

    Highlights from TechDays Finland 2020

    March 5-6 marked the annual conference for Microsoft geeks in Finland to gather in Messukeskus Convention Center and enjoy two days full of expert sessions on the latest MS technologies and real life stories on how all this tech is making an impact out there. In this blog post I’ll reflect on the sessions that I attended at TechDays this year and share some thoughts on what I think are topics worth exploring more. You’ll also find links to slides and a few social media posts from the event.

    Let’s get one thing straight first: Power Platform is everywhere these days. Even a Microsoft IT & Dev conference like TechDays 2020 was opened with a keynote presentation that stared with the 4 pillars we’ve come to know from the Digital Feedback Loop, familiar to all Dynamics 365 professionals by now. Engage customers. Empower employees. Transform products. Optimize operations. The goal of digitally transforming organizations has become the overarching theme of Microsoft’s product offering, supported by global cloud infrastructure, enabled by Azure services, integrated with Office 365 productivity tools and ultimately unlocked by the apps created on top of Power Platform.

    For many of the attendees, the journey of how exactly we’ve reached this tipping point of low-code applications isn’t necessarily familiar yet. For us at Forward Forever, a new technology agency focused 100% on Power Platform, being able to participate in discussions with MS tech professionals around this theme was of course of highest importance. Our whole team was present for the 2 days of the event, to ensure we’ve got a thorough understanding of the state of the ecosystem. Thanks to everyone we had a chance to meet at TechDays! Lots of great dialogue and awesome feedback to encourage us to push forward with the vision that we have for our new company.

    Our very own Power Platform guru Timo Pertilä had two sessions at this year’s event. The first one was aimed at the broader audience of non-PP professionals, to help them get started on creating Power Apps Canvas apps. Timo gave us the kind of tips he wished he had been given back in 2016 when starting to explore these tools. When it comes to Canvas apps, the most important step is to A) decide on an app that you would actually want to use yourself and then B) just creating it! Following along the lines of a simple IT asset management app built on top of a SharePoint list, Timo’s session went through all the common areas that an app maker should be aware of. I encourage everyone to pick a training lab from one of the many Power Apps learning resources and just follow through a scenario, to understand how these new tools can really democratize the creation of simple business apps on top of existing data sources.

    [Slides]

    The second session by Timo was about exploring the capabilities of the new UI Flows in Power Automate. RPA, Robotic Process Automation, is a smoking hot topic and the addition of such capabilities into Microsoft Power Platform has gotten even cool-headed Finns like Timo excited about the new opportunities. Yes, while integrating software properly via API based automation remains the core of what Power Automate excels at, the option to connect to systems that for one reason or another can’t be accessed via APIs can close the final gaps and turning manual processes fully digital. In the TechDays session we saw a demo story of an employee onboarding process for HR deparments. Using UI Flows to create user accounts in a non-API enabled legacy system such as Microsoft Access is now possible with these graphical tools that record the steps in the UI and then execute them by using variables like employee name as inputs from other parts of the Power Automate flow.

    [Slides]

    Although the use of a “proper” relational data management system like CDS would be preferable in building apps for enterprise wide use, the fact is that SharePoint remains both a commonly used as well as easily accessible data store for many citizen developers. The session by Mikko Koskinen showed us how you can leverage tools from the Power Platform to improve the user experience and also auditability of actions that users take on SP list and document data. Custom forms built as Canvas apps and process automation implemented as Flows can do wonders to your SharePoint based business apps, and of course they also open up the connectivity to many other Microsoft services to further extend the feature set as the demands of enterprise customers evolve beyond Office. Having a common set of low-code customization tools across the whole MS stack is where the real Power of the Platform lies.

    Microsoft Teams is becoming ubiquitous in the business world as pretty much all organizations on Office 365 are moving away from Skype for Business. The end result of this mass exodus towards Teams may not always be the automatic improvement of teamwork and employee productivity, if all you do is enable the licenses and activate the new services. The Teams MVP duo Vesa Nopanen and Karoliina Kettukari delivered an entertaining story of the rogue cowboys (end users) vs. the central command center (IT department) and how their perspectives on how Microsoft Teams should be implemented and managed can differ wildly. There are plenty of smart settings that the IT guys could automate behind the scenes for a more productive workday experience, but at the end of the day, a lot of the everyday usage of Teams relies on the real life teams to agree on common practices and expectations on how everyone will use the software tools. Educating and encouraging both parties to do their part is therefore essential for achieving success with MS Teams adoption.

    [Slides]

    Teams is not just a communication tool, though. It is quickly becoming a platform, which from my perspective is the most exciting aspect in its rise to popularity, since this paves way for a wealth of scenarios to better leverage Power Platform tools for a broad information worker audience. MVP Christina Wheeler presented us to path on how to get started with developing Apps for Microsoft Teams. It’s worth exploring the wealth of Teams App Templates that MS has published on GitHub, as these will give you many ideas on how to link various Azure services into the UI that your people are spending a growing part of their days working in. From a low-code development perspective, though, the options for bringing in Power Apps into the Teams navigation experience is the low-hanging fruit that you’ll also want to explore.

    Another super hot MS technology alongside the low-code Power Platform and ubiquitous Teams is Azure Synapse Analytics. In the TechDays 2020 keynote, Data Platform MVP Vesa Tikkanen and Anne Komscha from Stora Enso presented what opportunities this brand new cloud analytics offering from Microsoft opens up for organizations to rethink their data architecture. Vesa demonstrated the unique capabilities that Synapse brings to the table by connecting to and from a SQL Server 2000 virtual machine to the modern data cloud. It’s therefore not a “rip & replace all the things!!1!” type of a scenario where Microsoft is aiming at here, rather they are playing on the compatibility card here and ensuring that your complete data estate can connect with Synapse. Thinking about the Customer Data Platform scenarios where this same underlying technology will be leveraged to identify customer profiles from various sources, it’s easy to understand why MS is so bullish on their position in the emerging CDP market.

    As your data and your apps are all either moving to or at least being connected with Azure, it’s no wonder that questions on how should we secure all of this are bound to surface more and more. Azure MVP Karl Ots explained the role of security in the cloud adoption journey to a packed room full of MS tech professionals that probably have all done hands-on experimentation with many Azure services yet not necessarily paid attention to how to limit access instead of enabling it for their own super admin accounts. Role-based Access Control (RBAC) gives you a comprehensive toolkit to configure the permissions in alignment with the identified parties who need to access resources in your subscription, but it may still come as a surprise how much rights can be inherited from the top down to the individual resources if your model isn’t well planned out.

    [Slides]

    Rob Kuehfus from Microsoft presented a possible solution for approaching the wider journey to the cloud: Cloud Adoption Framework for Azure. This represents MS efforts to consolidate their earlier fragmented whitepapers and information sources (up to 40 earlier, based on what Rob told) into a single source of guidance and best practices on what to do on each step towards the cloud. From planning the organizational roles needed on the journey to building focused “landing zones” where the first customer workloads can be dropped on, this framework should become the go-to resource for establishing common understanding between customers and partners on what’s actually needed when adopting Azure at scale inside an enterprise organization.

    [Docs: Microsoft Cloud Adoption Framework for Azure]

    As an example of one customer organization that has taken the steps recently, the Azure adoption story of Terveystalo was presented by Development Director Ilari Richardt and Polar Squad’s Azure Lead Masi Malmi. Terveystalo is one of the two private healthcare giants in Finland and their history is full of consolidation projects, which makes it all the more impressive how throughout history they have aimed at having a single patient information system in place. The decision to choose Dynamics 365 as their CRM and ERP systems actually ended up driving also the custom software development investments towards Azure and now building modern DevOps practices in the MS cloud are a key focus area. Bridging the cloud and on-prem wolds in healthcare naturally involved building a lot of APIs and Masi’s exploration of the capabilities of Azure API Management has produced some interesting findings on what the challenges are on this front.

    Last and probably least… OK, definitely not the least. Mr. Järjestelmänvalvoja a.k.a. firsname.lastname, also referred to as Sami Laiho, wrapped up TechDays 2020 with his packed session on the main arena. Even though I myself have very little to do with managing endpoint security on a professional level, it’s always interesting to hear what the world of securing the Windows laptops and the Azure resources accessed via the credentials used on those laptops actually looks like out there in the enterprise space. It doesn’t make much sense to aim for 100% security, but you just need to be better secured than your neighbor. Considering that just by enabling multi-factor authentication you’re already more secure than 99.9% of the compromised accounts out there, this isn’t always rocket science but rather behavioral science. Sami’s examples of the extent to which people (employees and CIOs alike) go to in their effort to remove inconveniences that could actually put them into near 100% safety is a welcome reminder to all of us that any new innovations we come up with in the information technology space will need to pass the “but what would humans do with it” test before achieving real, tangible results.

    [Slides]

  • Activity Feeds and user rights: who can see what?

    Activity Feeds are a channel that’s much like Twitter: creating posts that are visible for other users who are following you. On the surface they share many of the same concepts (mentions, following, replies/comments), but there are some notable differences that may come as a surprise to a user who’s accustomed to the open communication taking place on the external social networks. This is especially apparent in a CRM organization that has a hierarchical structure of business units and is limiting the visibility of core records such as accounts across the BU’s.

    Let’s assume that we have a CRM deployment with multiple BU’s that form a hierarchy of a single parent (the top level BU) and multiple child business units. In our example the child level is represented by two country specific BU’s: Finland and France. There’s a user called Jukka in Finland and another user by the name of Teppo in France (OK, not exactly a typical French name, but we’re actually dealing with a Finnish expat here in this case). They are both using CRM to manage accounts and opportunities in their own business units but do not have visibility to any other BU’s data. Nevertheless, we’d like to leverage the Dynamics CRM Activity Feeds as a channel for sharing insights and connecting across BU borders, to make the most of the human capital and knowledge available within our global organization.

    If Teppo from France is looking for new users to follow, he will need to fire up Advanced Find and perform a search of the user records available in the CRM organization (this is the first thing you need to provide clear instructions on, as it’s not quite as intuitive as on Twitter). Unless the default security roles have been adjusted in terms of the User entity, he will be able to see a list of users from all business units. Also the follow buttons on the ribbon of the results view will be active, so Teppo selects a few users from outside his own business unit, as he’s eager to learn about what information they might be sharing on the common CRM platform. However, if he’s paying close attention to the dialog that CRM presents to him he’ll actually notice that he wasn’t able to follow Jukka from Finland.

    “You might have tried to follow some recently deleted records. Newly following: 0” Hmm, what does that mean exactly? It means that the user wasn’t able to follow any users, even though he was not greeted with the familiar big, red X. The reason for this error message was most likely that the user didn’t have sufficient rights to append the Follow records to the selected User records. Assuming that we want to enable such cross-BU following of users, what we need to do is to modify one of the user’s security roles to grant a global right to the Append To function on the User entity.

    After we’ve granted the new rights, Teppo from France is able to follow Jukka from Finland. When Jukka posts a message on his personal wall, Teppo is able to see the post and jump in on the conversation. Social Business in action!

    OK, now how about if Jukka from Finland is writing a post on the wall of an account owned by a user from the Finland business unit? If Teppo is following Jukka’s posts, he will probably see this update from him as well? No, actually he won’t see anything on his wall. If we look at the same post from Jukka’s own Activity Feed wall we can spot the difference to the previous post:

    Here we see the importance of the regarding object of an Activity Feed post. Teppo will not see any of these posts written by a user he is following, because they are set as regarding an account record he himself is not following. These are not just independent posts on the Personal Wall of the user, rather they are updates that are posted on the wall of a specific account (Nokia). In our case, since Teppo does not have visibility to the accounts from another business unit, he has no way to access the conversation going on there or to go and follow the account record.

    (more…)