Power Apps Viking

Guides and help for getting the most out of the Microsoft Power Platform and Model-Driven Apps

Recent Posts

  • Deep-Dive in Power Platform Security Roles – User based privileges

    UPDATED April 3rd.

    Morten Zohnesen (LinkedIn Link) Provided some great feedback to my post.

    Quick summary of changes My post is focused solely on personal ownership of records. If you are using team ownership of the records, the “user” ownership applies to the entire team then instead. It’s possible to also set user privileges to entire tables to “Organization” and furthermore you can set user privileges in security roles so that only Team privileges apply. I will probably have to make an entire post about this. So, this post is only focused on working with tables and security roles where user ownership is in use.

    Furthermore, Morten noted that I should update the wording on the cascading aspects of ownership in table relationships. Previously I used the word “Sharing” to indicate that records were shared, but in fact the ownership is changed to the owner of the parent record, similar to the “Assign” operation.

    Original post:

    In this post I want to talk about some of the many aspects of security roles and how they work. It’s something I often get asked about and worth spending some time on.

    Put shortly, when working with security roles, you want to either limit, expand, or simply understand the basic question:

    Who can do What

    In Microsoft terminology we use the following terms to describe this:

    Defining Who is done via the Access Level
    And
    Defining What is done via the Privilege Type

    I’m going to split this post up into different two different sections from the picture below, the first is the different Access Levels that are selected from the dropdown – User, Organization, etc. – and second is the different Privilege Types as seen in the columns – Create, Read, Write, etc. – but first we also need to go through some basics of how security roles function in the realm of the Power Platform.

    Basics of Security Roles

    Owning user When working with security roles and managing access based on the tables, the most important field to be aware of is the “owner” field. As this will affects everything discussed here. Records need to be owned by a user, and either the user, or the relationship(relationship as in, being part of the same business unit, organization, etc.) a user has to the owning user is key to how we want to set up our security roles.

    Relationships Furthermore, when creating relationships between tables, you can select how the relationship affects records from the parent to the child table. If you select “Parental” as the relationship type, then all records on the child table will get the same type of ownership as the parent record (cascading), when the two records are linked. If you want to avoid this, you can also select “Custom” relationship and define the cascading nature of each element as seen in the image below.

    Access levels

    User

    This access level restricts the access to the table records to only the include records that have the user assigned as owner (or those that are shared with the user). For example, when selecting the “User” Access level under the “Read” Privilege type, the user is only able to read records from the table that the user either Owns or that have been shared with the user.

    Business Unit

    All users in the business unit of the owner have access to the record. The same is true of records shared with the business unit directly (the business unit can be selected in the same way as a user or a team). The Business unit can also be the owner of the records given that the business unit has the correct permissions for this.

    Parent: Child Business Unit

    Users can access any record in their own business unit and also the records of all child business units. Seeing as business units can be set up hierarchically this means that all business units below the user’s business units are considered “child” business units.

    Organization

    All users within the organization, irregardless of business units, have access to the record to perform the given privilege in question.

    Privilege types

    Create

    The ability to create records on any table. The significance of this being either “User”, “Business Unit” or “Organization” only has any meaning when working with a combination of Tables that use either the User or Team setting. When working with “Organization” ownership. We no longer use the User or Business unit settings as they do not apply the same way.

    Read

    This setting is valid for any type of table. The ability to read records based on the permissions you have for the table. For User you can only see records that are assigned directly to you or have been shared with you using the “Assign” function.

    If you only have the “User” permission for a table, any records in a table that is not assigned or shared with you will not show up in any view and be inaccessible even with a direct link to the record.

    Write

    Same as with read, this controls the ability to make changes to any field on the record itself.

    For example:

    A user could have read permissions on the “Organization” level for a table, but only be able to write to some of them because the user was only given *User access to the Write Privilege

    Delete

    This defines the ability of a user to delete record within the table. Keep in mind that if a user has the ability to Delete records with organization as the Access Level, but only has Business Unit as the Access level for the Read Privilege. The user will not be able to delete record outside of their business unit via the Power App. However, it makes sense to keep the access levels at a similar level to avoid confusion. Generally providing the Delete Access Level is something that should be kept to as few users as possible and deactivating records will in most cases be adequate.

    Append

    This allows the user to append or associate a record with another record. An example of this could be that I have a table of all the boat trips I go on. For each boat trip I maintain a log of the cities I have visited along the trip. I want to store the information about each city visited on each trip in a separate table. I therefore create a second table called City. In order to append the record of each city visited for each trip. I need to have Append rights to the City table.

    Append To

    This allows the user to append or associate records from other tables to the table in question.

    Continuing from my previous examples. The user needs to be provided with Append To access to the Boat Trip table in order to complete the Append and Append to operation between the Boat Trip table and the City table.

    Assign

    This gives the user the ability to assign records from the table to other users, provided that the other user also has read rights to the table in question.

    Share

    This gives the user the ability to share the record in question with another user. It also requires that the user is able to Read records on the table in question.

    Unlike the Assign Privilege Type, simply sharing a record does not change the ownership of the record. It merely adds the user. When sharing it’s possible to restrict the users Access Levels directly. The sharing cannot override the users own access levels, and can only provide access up to the limits posed in their own security role.

    For example:

    Aser A has “User” access to the read, Write, Delete and Share privileges to records on the Boat Trip table. User B has “User” access to the Read and Write privileges. But not Delete If user A shares a record with User B. Then it will not be possible to assign the Delete access level to the user, even if user A specifically selects this option while sharing.

    I hope you found this overview helpful. Let me know if you have any questions or comments or things that I missed.

  • “+Add existing records” in a subgrid on a main form – What does it do and can I get rid of it?

    “+Add existing records” in a subgrid on a main form – What does it do and can I get rid of it?

    Do you want to get rid of this button? Without using RibbonWorkbench or scripting?

    You can do it very easily, in many cases at least.

    What button are we talking about?

    The “+Add Existing record” button looks like this and is shown just above the subgrid, in the top right menu.

    +Add existing record

    So first of all, what does it actually do?

    When working with Model Driven Apps and parent-child records, most citizen developers will at, some point, have experienced situations where you use a subgrid on a main form. You can of course then use the subgrid to quickly add new records (using the quick-create form to avoid navigating away from your main record), but theres another option to ‘+add existing records".

    This shows two different use-cases.

    1. One where we have to create each new row in the child table that is unique to the parent table and the relationship is created as part of this operation (by using the quick-create form.
    2. Two second where a list of records already exist in the child table and they have not been assigned to a record in the parent table yet.

    If you want the guide and screenshots of how this is enabled/disabled then scroll down a little bit.

    For those that want to understand the table relationships and how it works you can read on here.

    Example of the parent-child relationships

    For example. I have a parent record which was the list of all my recent boat trips. In one child table I decide to maintain a list of all errors that I encounter while on each trip. Using a new table called “Error” which has a many-to-one relationship to the “Boat Trip” table. These records would be unique to the relationship between the Error table and the Boat Trip table where the lookup from Error to Boat Trip is filled out by creating them using the quick-create. In another example I could also have a list of people currently joining me on the trip. This Crew Members table also has a many-to-one relationship to the Boat Trip table. However, each Crew Member is only there temporarily and can only be on one single boat trip at a time. So instead of using the quick create. I assign them using the “+Add existing record” and can search for the people that are in the Crew Member table. This allows me to add people that are not assigned to any other Boat trip at the moment.

    So. The ability to use “+ Add existing records” exists for a reason. But only makes sense in the second scenario described above. So, if you are only using the first scenario, you can change the setting of the relationship and remove the button from the interface completely. That’s pretty neat!

    Working with the records

    Now. So how do we do this. So lets say we have a parent record where we have added two tabs which each have a subgrid referencing two different child tables.

    The parent record

    The parent record of course needs to be created first in order to create the child records where the relationship is added.

    Optional child record

    So how do the two subgrids work exactly and what does it look like. Let’s dive into it.

    First, we look at the subgrid for the table where the relationship is optional and therefore has both options (one for adding new records and one for adding existing records) Optional child record

    The relationship is set the following way (I can see this by finding the lookup field under the relationships on my child table): Optional lookup

    From the example above this corresponds to the Boat trip table and the Crew Member table, where the crew members do not need to be part of the Boat Trip table and therefore I can add any record from the Crew Member table as the lookup could currently be empty.

    Business required child record

    Then we have the subgrid for the table where the relationship is business required, which only has the “Add a new record” option and not the “+Add existing records”

    Business required child record

    The relationship is set the following way (I can see this by finding the lookup field under the relationships on my child table): Business required lookup

    From the example previously this corresponds to the Error log on my Boat Trip table where I can’t create an error log that does not exist as part of a Boat Trip, and a specific Error should be moved to another Boat Trip. If the error occurs on multiple trips I would create multiple entries in the Error table.

    Removing the Button

    This means that you can remove the button by simply changing the relationship to be “Business Required”. However, for child records where you dont want the field to be mandatory (such as my example with the crew members), this is not a viable solution. In those cases you would need to use the RibbonWorkbench or scripting. There is also another case that should be considered. Say you want to use the Error table across multiple parent records. If I also wanted to track errors on my house building projects (in a new table called “House Project”) as well as Boat Trips. Furthermore, be aware that when a child record has been assigned to one child record, you can by default select it in the lookup, you should change the filter in the view used in the lookup to only include records where the lookup field does not contain data, to avoid finding records that are not available (for example, Crew Members that are already part of another Boat Trip).

  • Working with security roles in the modern interface

    Working with security roles in the modern interface

    The Modern Interface version of working with security roles is so good that I wanted to make a post to it. It is in fact so good that when I show this to people that have worked with Dynamics for years, they often have a hard time believing how good it is. It is so good that it, alright, you get it. I really like the new security role interface. But first, a couple of things that needs to be addressed.

    Direct user Access & Team Privileges Worth mentioning is that I will not be exploring team only security in this post. I will save that for a later post as this deserves its own separate post to fully explain.

    Preview feature alert Another thing that needs to be said is that the current interface is shown as a preview. This does not mean that you won’t be able to work with security using the modern interface in the future, but some buttons might change position or name. Everything we will work with in this post can be done in the classic interface as well. Unless the Power Apps team is planning a major transformation of security roles then everything covered in this post will be valid for a long time. And seeing as this is used as the basis for security for many enterprise companies, I don’t foresee any significant changes to the security setup any time soon.

    So, with all that our of the way, let’s get started with the post.

    Creating a new security role

    You are of course using the new maker interface and not using classic mode.

    So here it two different ways of accessing the security roles to make sure you get the new and improved interface:

    Through the admin center

    To access the modern interface for security roles, you can either create a new one from your solution, or go through the admin center which you can do here:

    Go to the settings for you environment

    Then under Users + Permissions you select “Security roles”

    Here you can create a new role

    Through the solution in the maker portal

    The alternative, and the one I prefer, is to go through the solution.

    Let’s say that you need to create a completely new security role from scratch. This will be done through the maker interface by navigating first to your given solution and then creating a new role. By selecting “New > Security > Security Role”

    From here you want to give the security role a name and select which business unit the security role belongs to. The reason for selecting a business unit is that you can divide different roles into different units. I see this done in very few actual cases as security is usually synchronized with Entra ID groups, instead of a company managing the organization in dynamics as well, but the use case still stands. Also, be aware that you cannot include a security rule belonging to a child business unit in your solution. This is because the business units are unique for each environment. The Security role therefore needs to be created on the parent business unit level. You will still be able to enact security on the business unit level, but you will need to manage the business units on the individual environments.

    Security Role interface

    Now. This is where things get really interesting. Let’s start with comparing it to the old interface. In the classic interface you would have to navigate a series of different tabs, divided into categories that are pretty foreign for most people working with just Power Apps as a citizen developer.

    Instead, we start with a focus on arguably the most important aspects of security, which is tables in 99.9% of the cases I know of.

    There are three main tabs. Tables Miscellaneous privileges, and Privacy-related privileges

    When looking at the tables you haven’t lost the ability to discern tables in the same way as before, they will still be categorized by the categories you know from before, such as Core Records, Business Process Flows, etc

    Interacting with tables in a new way

    Let’s focus first on the table permissions and how we interact with them

    There is a menu below “tables” which is by default set to “Show only assigned tables” where you select between All tables, assigned tables and unassigned tables. If you have created a new app with completely new custom tables, you will find them under the “Unassigned tables” view.

    However, unlike the classic interface, you don’t need to start either scrolling or using ctrl + f to find you table of choice. You can simply use the search in the top left corner to find the exact table you need and clear all others from the interface.

    So, let’s say you wanted to work with a table you created to manage your inventory of boats. So you would go to either all tables or the unassigned table overview and search for “boat” in the top left corner and it would provide all tables with that name, including potential business process flows if you had any with the same name as well.

    Now we are ready to work with the different access levels. You can actively filter which coloumns (privilege types) you want to view, as some might be completely irrelevant to you.

    In this example I removed Record Ownership, Permission level as well as Assign and Share. When you have selected the relevant columns, we find the, in my opinion, best feature of the new interface. The ability to select privilege in a logical and straightforward way:

    Gone are the days of clicking the exactly right number of times to hit the “Organization” or “User” level only to miss it and having to cycle through the process another time.

    You are now able to just select the levels in a dropdown and see them explained directly for each column (privilege type), for each table. This is perhaps a source of 90% of the issues people had with security before, where the previous interface simply lacked the transparency of being able to adequately see what type of privilege was given for the table you actually wanted to change.

    Honestly this is, for me at least, a major upgrade and also just really the only logical way to work with this. Clearly seeing and understanding the types of privilege added for a specific table in a security role, should not have been handled through legends previously used, but stated clearly for all users to understand intuitively.

    I’ve mentioned some of it in a YouTube video shortly previously. And if you want to know more about the privilege types and access levels then I have another post coming in a few days about just that.

    In that post I will cover the topics mentioned above as well as some day-to-day scenarios for when you would want to use the different roles.

  • Do I really need a Power Platform Center of Excellence? And will the CoE toolkit fix all my problems?

    Do I really need a Power Platform Center of Excellence? And will the CoE toolkit fix all my problems?

    UPDATE: This post became popular so it’s probably going to turn into a series of CoE posts. Stay tuned for more.

    Do you have a long-term Power Platform strategy? or even a short-term one?

    If you are like most companies, then the answer is probably no.

    Is this a bad thing? It depends. But if you are serious about Power Platform adoption then you should be considering some sort of strategy. In this post I want to help paint a clearer picture of what exactly the Center of Excellence(CoE) could do (and what it can’t do) for you.

    If you are like most companies I have seen working with the Power Platform, you are either doing in-house development, hiring external vendors, or a bit of both. What typically happens next is that each time a new environment – or a series of environments – needs to be created, the manager for the team, or the person responsible for the project, gets in touch with IT and they create the environment(s). Then the magical sentence “now you are in charge/responsible for this” is said, and usually no one thinks about it again. Essentially, the person in charge is trusted with knowing how to manage the Power Platform Environment and will do so accordingly.

    Spoiler: They usually don’t.

    This is one of the main issues that you want to solve with the Power Platform Center of Excellence. Lack of transparency and lack of ownership.

    Now, the process described above is a lot like requesting many other IT resources, like an SQL database or other Azure resources. But there is a significant difference between the two. First of all, most IT departments have a quite clear Azure strategy, maybe even an Azure Center of Excellence. Second, because the Azure CoE team has done their homework, those resources are more easily tracked and managed in Azure.

    The last part is especially important. Because even in the lack of a process and a clear person in charge – Sometimes people change to other positions or leave the company – tracking/managing the resource still works if there is a system for it.

    This is where the Power Platform Center of Excellence* enters the picture. Built by the amazing Power CAT team, the CoE offers a large range of tools supporting the entire lifecycle of Power Apps Development, from requesting environments, access to Power Automate Connectors, to restricting access as well as gaining an overview of the current Power Platform landscape (with metrics such as number of environments, apps, flows, etc.). All this can be either complete overkill for a smaller company or department using only a few apps and flows, or a full-time job for a company that has several hundred or even thousands of citizen developers.

    *If you want to just get the CoE kit then here is a link to the official site for the Center of Excellence Starter Kit

    Creating a Power Platform strategy

    Your focus before considering whether or not you actually need to work with the Power Platform CoE, should be what your Power Platform strategy is in the first place.

    A primary question you can start with is: What do you want to achieve with the Power Platform in the company?

    • Do you want to just enable access to an application built by a third-party vendor?
    • Do you want a specialized team to be able to create apps or flows (perhaps RPA)? Or
    • Do you want to open the possibility for citizen developers in multiple departments to utilize the benefits of a low-code platform to leapfrog productivity and avoid unnecessary development costs at the same time.

    Perhaps you want to start with the first and gradually move towards the last or sit somewhere in-between. No matter what, the power platform strategy should inform your decision to utilize the Power Platform CoE.

    I can boil down my own advice and experience to the following: I would advise companies to make use of the benefits of the low-code Power Platform as much as possible, and I would do this by allowing as much access to the platform as possible for citizen developers. Furthermore, this should be done knowing full well that at some point, some citizen developers are going to create environments, apps, flows, etc. that might not comply with your current ideas of best practices. This is not necessarily a bad thing, if you catch it early enough. If users generally feel like they have the freedom to create awesome apps and flows, they will do that – in most cases – and you only need to focus on the ones that could be problematic.

    Can I actually do that?

    The answer for this is one of the great use-cases of the Power Platform Center of Excellence. The ability to find apps/flows/etc. that can cause issues and engage in a dialogue with the citizen developer early on about this. This does not require a set-up with 24/7 surveillance. Most admins (depending on the size of the company/number of citizen developers) can do this with a simple 5-10 minute check every 2-14 days.

    So how do I get started?

    It takes a few hours to set up your Center of Excellence, but the set-up itself does not require that much. The most important things to focus on is the following:

    Center of Excellence getting started check-list:

    • Define what you want to achieve with the Center of Excellence
    • Identify who will support this
    • Assess which level of freedom you want to provide for citizen developers
    • Identify which processes needs to be in place to find the perfect fit between keeping IT happy and keeping Citizen Devs happy
    • Define what your mid- and long-term goals are for the Power Platform and how can the Center of Excellence support this goal

    With the checklist complete, even if somewhat vague for things such as the last one, you are ready to get started with you CoE adventure. And remember, the only thing worse than starting out with a draft version of the 5-year plan for your CoE, is not doing anything at all and finding that all your SharePoint data is being shared to X directly through a Power Automate flow that’s been running for six months. Which is a real thing that could happen with no CoE – and no DLP Policy – in place.

    So, to answer the question in the title, you might need A Power Platform Center of Excellence, or you might not, I can’t really answer that for you. What I can say is, you need to do some groundwork before you can actually reap any benefits from it. To add to that, after installing the Center of Excellence, your problems are not magically fixed without continued use and support in the organization. A good way to perceive your Power Platform governance journey is to compare it to running a marathon. Setting up the CoE is similar to running the first 500meters, once you have finished the initial installation, the real fun begins.

    That being said, have fun with setting up your CoE and feel free to reach out for any questions! There will be more CoE content coming in the future, where I will cover what to do once you installed the CoE Starter Kit and need to work with all the other elements of Power Platform governance – the remaining ~42 kms of the marathon.


  • 5 step guide to enabling, and using Copilot for your data, in your model-driven apps

    5 step guide to enabling, and using Copilot for your data, in your model-driven apps

    PLEASE NOTE: This feature is in preview on the Power Platform (but in general availability on Dynamics 365 products) and currently only available in environments that are in the US region. Addition: I have been seeing this enabled in some European installations, despite the official message from Microsoft that this only works in the US. So it might be available for other regions as well. But do not count on it before it is official.

    You all knew this was coming. Copilot is still the hottest topic in the Microsoft world, and we want it enabled in everything, so if you are like most people in this space, this is the post you have been waiting for.

    Copilot is being introduced to all areas of Microsoft’s product suite and Power Apps are no exception. Most of the attention has been on the impressive capabilities of the Copilot features in Power Automate and Canvas apps, with the effect that the model-driven app capabilities have been somewhat overlooked. I want to change that.

    Why do I want copilot in my model-driven app?

    First and foremost, and even though it might not sound logical, Copilot gives you the ability to access your data in a more “human” way. Instead of trying to set up all sorts of filters and sorting mechanisms, you can instead use natural language and ask your database questions. This way you avoid trying to deduce it from datasets where multiple filters might be needed.

    The second reason is that it also helps with providing a litmus test for how your data is structured. If users are having a hard time finding the correct data, either through normal use or through copilot, then this can be a good opportunity to consider what data is stored and how.

    So how do I enable Copilot for model-driven apps? And how do I actually use copilot to work on my data? The documentation for it can be a bit puzzling for some, and it only answers the first part of enabling the feature. I also want to cover how to start working with the data as well.

    If you want to read the official documentation, you can find it here

    The rest is my 5-step guide:

    Step 1 – Navigate to the environment settings

    First step is to add the feature itself. This is done by going to the admin center (admin.powerplatform.com) and navigating to the environment that should have the feature enabled.

    Step 2 – Go to features

    Next you need to navigate to the settings and under “product” find the “Features” option

    Step 3 – Enable AI for users

    Under Features is where you can allow users to interact with data in your model-driven apps. You enable this by setting the “Allow users to analyze data using AI-powered chat experience” option to “Yes”. The other Copilot settings are related to using co-pilot for creating apps.

    Step 4 – Create an app or use an existing Business Application

    When this has been enabled you can create a new model-driven app or use your existing application. Go to the application that contains data in a table, or even multiple tables.

    Types of prompts:

    Now the first thing you would typically ask is probably very filter/list oriented. But the real magic lies in the ability of Copilot to further drill-down or assess the results in a conversation. An example could be asking Copilot to tell you what the type of data a query would bring you. Then a follow-up question could be to provide a list with certain columns included such as this example:

    This also provides you with an overview of which records contain the necessary data to adequately filter and sort. This provides an insight into the quality of your data as well.

    Step 5 – Interacting with data in all tables

    Getting data from a single table resembles the typical scenario that users have been used to when interacting with model-driven apps. But let’s expect more! Copilot allows you much more flexibility in terms of the types of questions you can ask. For me, one of best use-cases for Copilot is the ability to ask questions about any data in your applications, no matter which table you are looking at.

    In my first example I was looking at a Project table and was asking questions about data in that specific table. However, we can easily imagine a user looking at one set of data, but then getting reminded of another area. You might be looking at your projects and remember that there is a risk record which required attention. In this case you would normally have to either navigate to the risk overview or navigate to the risk through a related record. Instead, you can ask Copilot directly about any data. In my example I am still looking at my project table and even continued directly from the conversation about projects by simply asking about data in a different table.

    Clicking on the result takes me directly to a record in a different table, without having to switch to new areas in the navigation and having to set up filters systematically.

    My examples are only a few of the use-cases for Copilot in model-driven app. If you have any examples of what you have seen or done that could be useful then let me know or add a comment to my LinkedIn post about this.

    There are also some helpful guides within the Copilot about types of questions you can ask. You can click on “View Prompts” and see more examples of this.

    I hope you enjoy using Copilot for your data in model-driven apps as much as me and I look forward to this feature being available for all regions by default!

  • Deep dive: Managed & Unmanaged solutions

    Deep dive: Managed & Unmanaged solutions

    What are solutions?

    If you are reading this post in hoping to get an answer to the question “What is a solution?” Then I suggest you start with another blog post I made. I covered the basics working with solutions in my Getting Started with Model-Driven Apps series. You can read that post here.

    The purpose of this post is to provide some guidance for citizen developers and Power Platform Developers when things have become a little more advanced. You might be dealing with things such as multiple solution layers, and you need to be able to dig a little deeper. Understanding the overall concept of solution layers is generally important in order to avoid costly mistakes and to ensure that your application actually works the way you intend.

    In this post I will cover the following:

    1. Managed and unmanaged layers, in depth
    2. Managed solution layering
    3. Avoiding unmanaged layers
    4. Issues with managed solutions

    Managed and unmanaged layers, in depth

    First off, we need to start by revisiting my graphic from the previous post, showing the basics of how solution layers work on a Power Platform Environment:

    Avoiding unmanaged layers

    It should always be the case that you actively avoid making unmanaged layers on your test and production environments. Previously, developers working with solutions in Dynamics would use unmanaged layers throughout the different environments. This would be for a variety of reasons, but most of them involve either overcoming limitations that have now been solved, or are, in my opinion, largely irrelevant for 99% of citizen developers. Therefore, avoiding unmanaged layers should be the way of working going forward.

    Managed solution layering

    When importing your own managed solution, it will always be layered in the order that the solution was first added. Let’s set up a scenario for this case.
    We create two solutions, Solution A and Solution B. Both solutions contain a reference to the same column in the systemuser table. In Solution A the “Full Name” column has been renamed to “Legal name”. In Solution B the “Full Name” Column has been renamed to “Actual Name”.

    Now, use the above graphics as a reference, we do the following thought experiment:

    Week 1: You import the first version (version 1.0.0.1) of Solution A (as a managed solution) to your test environment. Changing the column name to “Legal Name”
    Week 2: You add the first version (version 1.0.0.1) of Solution B (as a managed solution). Changing the Column name to “Actual Name”
    Week 3: You add an update (version 1.0.0.2) to Solution A to the environment. What happens in this update? Is the name changed back to “Legal name”?

    The answer is that nothing happens in week 3. Solution B is the current top layer and is king and therefore the column is still called “Actual name”. Any changes made to your lower solution layers have no effect if there is also a change to the objects on any layer above it. This is really important to understand when looking at the graphics above.

    Avoiding unmanaged layers

    Citizen developers should always avoid using unmanaged layers in Power Platform deployment because it can lead to governance and security risks.

    Unmanaged layers can be created by developers who do not have the necessary permissions to modify the solution, which can lead to unauthorized changes being made to the solution. This can result in a lack of control over the solution, which can lead to issues such as data loss, security breaches, and other problems.

    To minimize these risks, citizen developers should use managed solutions instead of unmanaged solutions. Managed solutions provide better control over the solution, which can help to prevent unauthorized changes from being made to the solution. Additionally, using managed solutions is recommended best practice for deploying solutions to different environments, which can help to ensure that the solution is consistent across all environments. This way, citizen developers can trust that their solutions are function the same way across environments and that they meet the needs of their organization.

    Issues with managed solutions

    Lets go through a couple of different scenarios where managed solutions and solution layering can cause unintended issues, and how to mitigate them.

    Connection references

    When working with Power Automate Flows or anything else that could require a connection reference, you will experience that these need to be changed from time to time. This process will always be an unmanaged change on the environment you are working on, no matter what. This is not an issue in itself, however it can cause problems with keeping track of which objects are actually managed or unmanaged. Which is why I would recommend having an unmanaged solution to keep track of any unmanaged changes happening on your environment. This provides transparency over which objects have been changed in the unmanaged layer on your environment.

    Choice fields

    Simply put, if you use a choice field from any managed solution on your dev environment. You will not be able to remove any existing values without changing the original solution containing those choice values

    Let’s look at an example:

    You already imported Solution A and Solution B from before. In Solution B there is a choice field which looks like this:

    On top of this you create your own customization solution (Unmanaged Solution C in the graphics)

    Now, let’s say we change it by removing one of the choices. Let’s remove the one with three stars, and add our own choice which we now call “option 4”.

    So we save this, publish all and export it as a managed solution and it works. Easy-peasy right?

    Wrong. 

    First, we need to establish that the target environment needs to have all relevant solutions installed as there are solution dependencies. So the target environment will also contain solution A and B as managed solutions. Now if you import Solution C as a managed solution to your test or dev environment. (containing Solution B as a managed solution) then as a result of solution layering you will have the following choice field:

    There are now 5 fields, the 4 original fields, including your own.

    So what do to?

    If you have a choice field with ANY RISK at all of needing to remove choices in the future, create your own custom choice fields that you can change completely unmanaged on your own dev. I can’t stress this enough. 

    This is the same issue that we see with security roles. There are just some things which managed solutions, through layering, will still force through, no matter what you do in your own solutions afterwards.

    The same challenges apply to other solution objects such as:
    Calculated Fields, and Security roles.

    For Calculated fields, once a solution is imported with a calculated field, it is not possible to change the calculation through updates in the managed solution afterwards, this will have to happen in the unmanaged layer (If this has changed recently please let me know and I will correct this)

    For Security Roles, even changes in the deeper solution layers will affect how the security role will work. Therefore, if you want to ensure that your top-layer solution provides the correct security role setup I recommend copying the security role and assigning the new role to users instead of the old one.

    There is much more that could be said about solution layering and solution types, and I will make a separate post about patches at some point. If anyone has any information about changes to these topics please let me know.

  • Human created – Considerations for creating your first Power App: Canvas vs. Model-Driven Apps

    Human created – Considerations for creating your first Power App: Canvas vs. Model-Driven Apps

    I made this post as two parts, the first was created by ChatGPT, the second written by me. The posts both cover the exact same topic, but I wanted to prove the point that there is a lack of available resources for allowing citizen developers make the right choices about which apps they should create. Especially when it comes to building model-driven apps. This post

    While browsing the Power Apps Community boards, and talking to citizen developers, the first thing that strikes me about working with Power Apps is that there is usually very little consideration put in to which type of app should be created in the first place. Before you disagree, I want to make a few points clear first. I understand that not all makers are able to access premium features, and therefore model-driven apps are out of the question for those developers, that is understandable. And not all makers should make model-driven apps, as there are no doubt many use-cases where a canvas app is the correct fit.

    However, I generally find a trend in most citizen developers approach that I wanted to address. A very large percentage of the guides found online, including the Microsoft guides and documentation, are specifically tailored for helping citizen developers with Canvas Apps. Furthermore, when looking for help with power apps, the first hits most people will find, present a canvas app as the representative of what “power apps” mean.

    The post contains the following elements, the last part is especially helpful for new citizen developers that are looking for help with getting started with ANY kind of application.

    -My impression of current community/support landscape
    -Advantages and disadvantages of Canvas Apps and Model-driven Apps
    -Actual resources that will get you up and running quickly with your first app

    Current community/support landscape

    Where do citizens developers find help?
    Finding help for your first business applications can be a challenge as far as I see it. Especially if you want to – or need to – create a mode-driven app. I implore you, try for yourself and give me feedback on whether you found an example of a model-driven app by using any of the normal search terms such as “get started with power apps”, “create your first power app”, “how to create a power app”, or any other term using either Bing or Google.
    (warning, risk of advertisement) Incidentally, if you DO need a guide for creating your first model-driven app. You can find a 5-step guide on my blog. I will also upload a series of videos following the same steps.

    But back to the point of this post.

    I understand the idea of wanting to create an application with a personal look and feel, and the Canvas App provides just that. The concept of incredible freedom to create any type of app for any type of device is intuitively appealing to most people. However I would argue that several cases of applications I see, tend to solve the same very basic needs.

    These needs are for the most part centered around either replacing or updating current business processes. Processes that again are centered around using SharePoint lists, Excel sheets, or other ways of gathering information that can be used in a business context and usually forms the basis of some sort of reporting afterwards.

    Why do we advocate for Power Apps in the first place?

    Often times the main selling points for Business Applications are that they can, roughly speaking, evolve your typical employees from the job of being excel/sharepoint input slaves to become citizen developers that leverage the power of a modern low-code platform to grow your business and focus on the actual work that needs to be done. But in order to achieve this we need to actually empower citizen developers to make the right choices when opening up make.powerapps.com for the first time.

    In this post I want to dive further into the pros and cons of each type of application and leave your with a better ability to decide which application should be used for solving your business need when creating your next Business Application on the Power Platform.

    The basics of Canvas Apps and Model-Driven Apps

    Canvas Apps are pixel-perfect applications that provide an almost unlimited way of designing the look and feel of your application. The interface makes it easy to design your app for either phones, tables, or PCs.

    There is a large amount of freedom offered to the developers in choice of data source, including Dataverse, SharePoint, Excel sheets, and many more. In most cases, this will allow developer to use an existing data as the foundation of the application. The advantage of this is that the developer does not need to start from scratch and build a new data model just to create a simple app. The logic for each column or object added can be expanded with great detail using PowerFX. PowerFX in this context is two things, its extremely powerful and for the most part it is very intuitive, I am personally a big fan of having it as the basis when working with Power Apps. However, the ability to create logic using PowerFX also presents what I believe is one of the biggest drawbacks of canvas apps. The user is forced to custom-code almost every command, even when they just need to add a simple field or create some very basic business logic.

    Model-Driven Apps are locked in a very specific format for how your columns are presented when viewing and inputting data. Furthermore, there is an, almost completely, locked framework in place for how you access a record and how this is saved, deleted, etc. This provides several limitations in the looks and feel of your application. Your main options are adding tables, tabs, sections and filling them with the available Dataverse columns (Note: “fields” are called columns, but the term columns is also used to indicate how many columns(think in terms of a word column) of columns (fields) there are in a tab or section, confused? me too) . There are some other customizations allowed for certain fields, and through the use of PCF components this is further expanded. However, through all the restrictions, the user can focus on actually making the app with what is needed. The experience is usually that adding new columns and placing them is something that can be done as soon as a user identified a needed data input. This can be done within minutes, independent of the type of column being added.

    Pros and Cons of the two types of Power Apps

    So let’s do a quick break-down of the difference pros and cons of the two different types of apps. Instead of listing first listing them for one and then the other, I will make a comparative list of the pros and cons to give a better understanding of what they really bring to the table. I will also include some common misconceptions to clear up any misunderstandings and hopefully encourage more creative app development in the future.

    Canvas app pros:
    -Incredible design freedom
    -Data source availability
    -Start with your existing data
    -Device-specific design
    -Easy access to use device capabilities (camera, microphone, GPS)
    -Full use of all PowerFX features
    -Responsive (if you design them correctly)

    Model-driven app pros
    -Easy to get use interface
    -Large number of customizations available through PCF component framework
    -Responsive interface(notice how this sounds similar to the point for canvas apps)
    -Offline functionality
    -Accessibility support (Model-driven apps follow accessibility standards and guidelines by default)
    -Native use of Dataverse business rules and logic

    Now notice how there is an overlap in some features. Both types of apps allow the users to make use of Dataverse logic and functionality. This is a point that my ChatGPT created post was not able to capture. If you create a canvas app using Dataverse as a source, it can use exactly the same business rules and processes available to the model-driven app. In other words; You should not feel limited to creating a model-driven app if you want to leverage Dataverse functionality. Furthermore, canvas apps can be made responsive through design. The issue is not that it can’t be done, the issue is that it requires pro-code knowledge or help to get to that point. Although there are many resources available to help you get there quickly.

    Lets jump into the disadvantages for each type of business application

    Canvas app cons
    -High complexity in designing your application / steep learning curve
    -Lack of standards/accessibility
    -Limited functionality for low-code developers
    -Not responsive by design (specifically built for each device)

    Model-driven app cons
    -Staring from scratch when designing your data source
    -Limited design options
    -Limited access to PowerFX
    -Limitations in business logic, and some options only available in the classic/legacy interface
    -Data source limitations – Dataverse is the only data source available
    -Limited access to device capabilities

    Especially noteworthy is the aspects of whether the application is responsive or not. I would also like to add a personal downside of canvas apps, they are seldom made for PCs, and generally do not work as well on PCs. The first impression of creating an “app” is that you design it for phone or tablet use. But honestly, are most of the apps we are trying to replace actually used on phones/tablets in the first place? Workplaces are still filled with laptops or desktop PCs. Most of business users even have a mouse and keyboard connected, enabling much faster input in to your application, as opposed to limiting your connectivity between the app and user to just a touchscreen.

    I want to leave you with some resources for finding help. They cover several areas, such as overcoming specific application challenges, and information about working with the Power Platform in general. Let me know if you have suggestions for additions to the list.

    Important Resources for Citizen Developers

    –Shane Young (Canvas apps mainly)
    –Sara Lagerquist (model-driven apps)
    –Scott Durow (canvas apps and model-driven apps, technical)
    –Kristine Kolodziejski (canvas apps, responsive design and UI/UX)
    –Matthew Devaney (Model-driven apps)
    –LowCodeLewis (Power Platform)
    –Alex Shlega (Power Platform)
    –April Dunnam (Power Platform)
    –Jukka Niiranen (Power Platform)

  • Chatgpt generated – Considerations for creating your first Power App: Canvas vs. Model-Driven Apps

    Chatgpt generated – Considerations for creating your first Power App: Canvas vs. Model-Driven Apps

    Chatgpt generated – Considerations for creating your first Power App: Canvas vs. Model-Driven Apps

    Short introduction
    I made this post as two parts, the first was created by ChatGPT, the second written by me. The posts both cover the exact same topic, but I wanted to prove the point that there is a lack of available resources for allowing citizen developers make the right choices about which apps they should create. Especially when it comes to building model-driven apps. This post is written by ChatGPT and will showcase what you can learn about the difference between the two types of business applications by going online. Even when asking it to have a heavy focus on model-driven apps.

    Power Apps is a low-code platform that lets you build custom business applications without writing code. You can use Power Apps to create apps for web, mobile, and desktop devices that connect to various data sources and services.

    But before you start building your app, you need to decide which type of app you want to create: canvas or model-driven. These two types of apps have different design approaches, capabilities, and limitations. In this blog post, we will explain the difference between canvas and model-driven apps, and help you choose the best option for your app scenario.

    What are canvas apps?

    Canvas apps are apps that you design from scratch by dragging and dropping components (such as buttons, labels, galleries, forms, etc.) onto a blank canvas. You have full control over the layout and appearance of your app, and you can customize it to suit your needs and preferences.

    Canvas apps are ideal for creating simple or specific apps that focus on user experience and interaction. For example, you can create a canvas app to collect feedback from customers, track expenses, scan barcodes, or play a game.

    Canvas apps can connect to over 200 data sources, such as SharePoint, Excel, SQL Server, Dynamics 365, Twitter, etc. You can also use custom connectors to access data from other services or APIs. To manipulate data and logic in your app, you use Excel-like formulas that are easy to learn and use.

    Some of the benefits of canvas apps are:

    • They are easy to create and modify with no coding required.
    • They offer a high degree of flexibility and creativity in designing your app.
    • They support various device types and orientations.
    • They can leverage device capabilities such as camera, microphone, GPS, etc.

    Some of the limitations of canvas apps are:

    • They are not responsive by design. You have to manually adjust the size and position of each component to make your app adapt to different screen sizes.
    • They have limited support for complex business logic and validation rules. You have to write formulas for each scenario and handle errors manually.
    • They have limited support for offline functionality. You have to enable offline mode and configure data synchronization for each data source in your app.
    • They have limited support for accessibility features. You have to add labels, tooltips, keyboard navigation, etc. for each component in your app.

    What are model-driven apps?

    Model-driven apps are apps that are based on the data model and business processes that you define in the Common Data Service (CDS). CDS is a cloud-based database that stores and manages your business data in a secure and scalable way.

    Model-driven apps are ideal for creating complex or enterprise-level apps that focus on business logic and data management. For example, you can create a model-driven app to manage sales leads, track inventory, handle customer service cases, or run workflows.

    Model-driven apps use predefined components (such as forms, views, charts, dashboards, etc.) that are automatically generated based on the data model and business rules that you configure in CDS. You have less control over the layout and appearance of your app, but you can customize it to some extent using themes, site maps, icons, etc.

    Model-driven apps can only connect to data sources that are available in CDS. You can import data from other sources into CDS using dataflows or connectors. To manipulate data and logic in your app, you use Power Automate flows that are triggered by events or actions in your app.

    Some of the benefits of model-driven apps are:

    • They are responsive by design. They automatically adapt to different screen sizes and devices.
    • They support complex business logic and validation rules. You can define business rules and workflows in CDS that apply to your app.
    • They support offline functionality by default. They automatically sync data between your device and CDS when you go online.
    • They support accessibility features by default. They follow accessibility standards and guidelines for each component in your app.

    Some of the limitations of model-driven apps are:

    • They are harder to create and modify with some coding required.
    • They offer a lower degree of flexibility and creativity in designing your app.
    • They support fewer device types and orientations.
    • They cannot leverage device capabilities such as camera, microphone, GPS, etc.

    How to choose between canvas and model-driven apps?

    The choice between canvas and model-driven apps depends on several factors, such as:

    • The purpose and scope of your app
    • The type and complexity of your data
    • The level of customization and control you need
    • The skills and resources you have

    Here are some general guidelines to help you decide:

    • Choose canvas apps if you want to create simple or specific apps that focus on user experience and interaction, and that can connect to various data sources and services.
    • Choose model-driven apps if you want to create complex or enterprise-level apps that focus on business logic and data management, and that can only connect to data sources available in CDS.

    Of course, these are not hard and fast rules. You can also combine canvas and model-driven apps to create hybrid apps that leverage the best of both worlds. For example, you can embed a canvas app into a model-driven app to provide a custom user interface or functionality that is not available in model-driven apps.

    Conclusion

    Power Apps is a powerful platform that lets you create custom business applications without writing code. You can choose between canvas and model-driven apps depending on your app scenario and requirements. Canvas apps offer more flexibility and creativity, while model-driven apps offer more structure and functionality. You can also use both types of apps together to create hybrid apps that meet your needs.

    We hope this blog post has helped you understand the difference between canvas and model-driven apps, and how to choose the best option for your app. If you need more help or guidance, feel free to contact us. We are experts in Power Apps and the Power Platform, and we can help you create amazing apps for your business.

  • Getting started with model-driven apps – Working with the App Designer

    Getting started with model-driven apps – Working with the App Designer


    This post is a part of a series of 5 post exploring the key things you need to know about, when getting started with building model-driven apps on the Power Platform. The series contains these 5 guides:
    1. Working with solutions
    2. Working with tables
    3. Working with forms
    4. Working with views
    5. Working with the App Designer (this post)

    UPDATE: If you prefer to follow along in a youtube video instead you can find it here:
    This is the first of 5 posts in my new series exploring the key things you need to know, as a citizen developer, when getting started with building model-driven apps, on the Power Platform.
    1. Working with solutions (this post)
    2. Working with tables
    3. Working with forms
    4. Working with views
    5. Working with the App Designer

    UPDATE: If you prefer to follow along in a youtube video instead you can find it here:
    Getting Start With Model-Driven Apps – Working with the App Designer


    If you haven’t read the previous posts, I recommend starting from the first post and working your way through them.
    In my previous blog post, I covered the topic of working with views on model-driven apps on the Power Platform and their role in your business applications. Now that some of the basic components have been covered, we are ready to zoom out and apply them all in the App Designer. 
    The new version of the App Designer is a comprehensive tool that allows developers and app administrators to create, customize, and manage model-driven apps. It offers an improved user interface and enhanced capabilities for app design, making it easier and more efficient to build powerful solutions on the Power Platform. The new App Designer empowers users with a modern and streamlined experience, driving productivity and enabling faster app development.

    In this post I will cover 4 areas that I think are important when getting started with the App Designer
    1. The App Designer interface
    2. Advantages of using the new App Designer over the legacy version
    3. Best Practice
    4. Do’s and Don’ts

    1. App Designer Interface

    The App Designer consists of various menu items that facilitate app customization and configuration. The main menu items (on the left side) include:

    Pages
    The Pages menu item enables users to define the app’s navigation structure and layout. It allows for the creation of custom areas, groups, subareas, and tiles, providing a seamless user experience and easy access to different app components. It also provides quick access to pages that are included in the app but not in the sitemap, in order to help pinpoint which items might be missing from the navigation menu.
    Furthermore, it is possible to acces the now “edit command bar” functionality from this menu.

    Data
    The Data menu item provides a centralized view of all the objects that are either included in the app and which objects are still available in the environment. The app’s objects can be things such as tables, forms, views, charts, dashboards, and more. It allows users quick access to easily manage and customize these components. Be aware that when selecting “edit table” or “edit” under any of the menu items, it could lead the user directly to the table itself and not the solution you are working in, thus running the risk of making changes that are not included in your solution, or, if you are adding new items, being created by the solution publisher.

    Automation
    The Automation menu item enables the creation and management of Business Process Flows, which are guided workflows that help users navigate through predefined steps to accomplish specific tasks. It provides a visual representation of the process and offers control over the flow and stages.

    App Settings
    The App Settings menu item allows for configuring general settings for your business application and preferences for the app. This includes defining things such as the App name, description, and icon. It also allows you to enable the availability of certain features in the app. Furthermore you can enable/disable standard navigation items, and toggle whether to test upcoming and preview features.

    2. Advantages of using the new App Designer over the legacy version

    The new App Designer brings several advantages over the legacy version, including:

    Enhanced User Interface
    The new App Designer offers a modern and intuitive user interface, making it easier for users to navigate, design, and customize their model-driven apps.

    Streamlined App Development
    With improved functionality and usability, the new App Designer streamlines app development processes, reducing the time and effort required to build and maintain model-driven apps.

    Advanced Customization Capabilities
    The new App Designer provides enhanced customization options, empowering users to tailor the app’s components, navigation, and user experience according to specific business requirements.

    Improved Collaboration
    The new App Designer promotes collaboration among developers and app administrators by providing a unified environment for designing and managing model-driven apps. This fosters teamwork and ensures consistent app customization across the organization.

    3. Best Practice

    Best Practices When Working with the App Designer: To make the most out of the App Designer, consider the following best practices:

    Plan App Structure
    Before starting app customization, carefully plan the app’s structure, navigation, and component hierarchy. Having a clear vision of the desired app layout ensures a smooth development process.

    Leverage Reusable Components
    Take advantage of reusable components such as tables, forms, and views. Standardize their design and usage across different areas of the app to maintain consistency and simplify future updates.

    Test and Validate
    Regularly test the app’s functionality and usability throughout the development process. Validate the app’s behavior with different user roles and scenarios to ensure a seamless user experience.

    Document Customizations
    Maintain proper documentation of your app customizations, including changes made in the App Designer. This documentation helps in troubleshooting, knowledge sharing, and future app enhancements.

    4. Do’s and Don’ts When Working with the App Designer

    Do’s:

    • Do regularly save your app and publish all in your solution files, and when working within a team make sure to coordinate when this is done.
    • Do leverage the new App Designer’s capabilities for customization and configuration to create user-centric and efficient model-driven apps.
    • Do collaborate with other team members and stakeholders to gather feedback and validate app design decisions.

    Don’ts

    • Don’t make hasty changes without considering the impact on existing app functionalities or user experience.
    • Don’t save and publish changes without coordinating with team members that might also be working on the same objects.
    • Don’t make complicated menu structures or changes to the ribbon that could be solved with security roles or better UI/UX

    Wrapping up
    The new version of the App Designer provides a robust and intuitive platform for designing and customizing model-driven apps on the Power Platform. By understanding its menu items, leveraging its advantages, following best practices, and adhering to the do’s and don’ts outlined in this blog post, you can create highly tailored and efficient business applications that meet your organization’s unique needs and drive user satisfaction.

    You have worked your way through the five guides for working with model-driven apps on the power platform and are well on your way to become a fully-fledged citizen developer. If you find I missed an important part or find yourself struggling with a specific area of building model-driven apps, then let me know via LinkedIn or a comment below and I will do my best to either update the guides or maybe even add a completely new post. Have fun making great apps!

  • Getting started with model-driven apps -Working with views

    Getting started with model-driven apps -Working with views

    This post is a part of a series of 5 post exploring the key things you need to know about, when getting started with building model-driven apps on the Power Platform. The series contains these 5 guides:
    1. Working with solutions
    2. Working with tables
    3. Working with forms
    4. Working with views (this post)
    5. Working with the App Designer

    UPDATE: If you prefer to follow along in a youtube video instead you can find it here:
    This is the first of 5 posts in my new series exploring the key things you need to know, as a citizen developer, when getting started with building model-driven apps, on the Power Platform.
    1. Working with solutions (this post)
    2. Working with tables
    3. Working with forms
    4. Working with views
    5. Working with the App Designer

    UPDATE: If you prefer to follow along in a youtube video instead you can find it here:
    Getting Start With Model-Driven Apps – Working with Views


    I recommend starting from the first post and working your way through them.
    In my previous post, I explored the essentials of working with forms in model-driven apps. Building on that knowledge, this post will focus on views, another fundamental component of model-driven apps.

    Views play a pivotal role in model-driven apps by providing users with tailored perspectives on data. They offer a flexible way to filter and sort records, define column layouts, and display relevant information. Views empower users to focus on specific data subsets and facilitate quick decision-making. Understanding the basics of views is vital for creating impactful user interfaces and enhancing productivity.

    The post is divided in to the 4 following parts:
    1. How do views work?
    2. Types of views
    3. Best practice when working with views
    4. Do’s and Don’ts

    1. How do views work?

    Understanding How Views Work: a. Filtering and Sorting: Views allow users to filter and sort data based on specific criteria. In addition to user-defined views, model-driven apps also include system views and personal views.

    2. Types of views

    System Views
    System views are pre-configured views provided by the Power Platform. They offer commonly used data perspectives and serve as a starting point for users. System views are designed to cater to different user roles and provide essential data insights. While system views cannot be modified, they can serve as a reference for creating custom views.

    Personal Views
    Personal views enable individual users to personalize their data display within model-driven apps. Users can create their own views by selecting the desired filter criteria, column layouts, sorting preferences, and other display settings. Personal views allow users to tailor the app interface to their specific needs and enhance their productivity.

    3. Best Practices When Working with Views

    Plan View Structure
    Consider both system views and personal views when planning the overall view structure. Identify common data perspectives required by different user roles and create system views accordingly. Encourage users to personalize views based on their specific needs while maintaining a balance between customization and standardization.

    Use Meaningful View Names
    Assign descriptive names to both system and personal views to facilitate easy identification. Clear and intuitive names help users locate and select the appropriate view quickly, enhancing user experience and productivity.

    Leverage Filter Criteria
    Define filter criteria in views carefully to ensure relevant data is displayed. Strike a balance between providing flexibility and avoiding overly complex filters that may impact performance. Consider the unique requirements of different user roles and align filter criteria accordingly.

    Optimize Column Layouts
    Ensure that both system and personal views have optimized column layouts. Select the most important and frequently accessed fields for display to avoid overwhelming the user interface. Prioritize key information to facilitate quick data analysis and decision-making.

    4. Do’s and Don’ts When Working with Views:

    Do’s:

    • Do encourage users to personalize their views to meet their specific needs and workflows.
    • Do educate users about the availability and benefits of system views and guide them to select appropriate ones.
    • Do regularly review and update both system and personal views to align with evolving business requirements.
    • Do consider performance implications when applying complex sorting or filtering to views.

    Don’ts

    • Don’t solely rely on default system views; customize views to align with user requirements.
    • Don’t create an excessive number of personal views, as it may lead to clutter and confusion for users.
    • Don’t use redundant or overlapping views; ensure each view serves a unique purpose and adds value.

    Wrapping up
    Views, including system views and personal views, are essential for data presentation and analysis in model-driven apps. By understanding their functionality, following best practices, and considering the do’s and don’ts outlined in this blog post, you can effectively leverage views to provide users with personalized and meaningful data perspectives, improving their productivity and decision-making within the Power Platform.

  • Getting started with model-driven apps – Working with forms

    Getting started with model-driven apps – Working with forms

    This post is a part of a series of 5 post exploring the key things you need to know about, when getting started with building model-driven apps on the Power Platform.
    1. Working with solutions
    2. Working with tables
    3. Working with forms (this post)
    4. Working with views
    5. Working with the App Designer

    UPDATE: If you prefer to follow along in a youtube video instead you can find it here:
    This is the first of 5 posts in my new series exploring the key things you need to know, as a citizen developer, when getting started with building model-driven apps, on the Power Platform.
    1. Working with solutions (this post)
    2. Working with tables
    3. Working with forms
    4. Working with views
    5. Working with the App Designer

    UPDATE: If you prefer to follow along in a youtube video instead you can find it here:
    Getting Start With Model-Driven Apps – Working with Forms


    If you haven’t read the previous posts, I recommend starting from the first post and working your way through them.
    In my previous blog post, I covered the topic of working with Dataverse tables on the Power Platform and their role in your business applications. Building upon that knowledge, we now dive into the world of forms. Forms are essential components of any business application, enabling users to view, edit, and interact with data. In this post, we will delve into the art of working with forms on the Power Platform, leveraging the knowledge gained from solutions, and discuss best practices for designing intuitive and efficient user experiences.

    Solutions, as discussed in my previous post, serve as containers for managing customizations, including forms. By utilizing solutions, you can package and distribute form customizations across environments. This ensures consistency and simplifies the deployment process, enabling you to roll out updated forms with ease.

    This post is divided in to the following sections:
    1. What are forms and what can you do with them?
    2. Best Practice when working with forms
    3. Combining forms with workflows, business rules & Power Automate

    1. What are forms and what is possible with a form?

    Forms represent the user interface elements that allow users to interact with data stored in the underlying data model. Whether you are working with canvas apps or model-driven apps, forms provide a visual representation of data entities, presenting fields, sections, tabs, and controls for data entry, validation, and display. By customizing forms, you can tailor the user experience, streamline business processes, and ensure data integrity.

    2. Best Practice when working with Forms

    Understand User Needs
    Begin by analyzing user requirements and design forms that align with their needs. Consider the flow of data, user roles, and access levels to create a seamless and personalized experience.
    Layout and Organization
    Group related fields into sections and tabs to improve clarity and navigation. Optimize the form layout to minimize scrolling and cognitive load, prioritizing the most important fields and information.
    Responsive Design
    Ensure your forms are responsive, adapting to different screen sizes and devices. Test the form layout on various devices to ensure a consistent user experience.
    Field Validation and Formatting
    Apply validation rules and formatting options to enforce data integrity and provide a user-friendly experience. Leverage formula-based validations, data type restrictions, and tooltips to guide users during data entry.
    Conditional Visibility
    Use visibility rules to show or hide fields based on specific conditions. This enhances form usability by presenting users with relevant information at the right time.
    Performance Considerations
    Be mindful of the number of fields and controls on a form, as excessive customization can impact form load times. Optimize form performance by minimizing unnecessary calculations and using appropriate control types.
    Collaboration and Feedback
    Engage with end-users, gather feedback, and iterate on form designs to ensure continuous improvement. Regularly review and refine forms based on user input and evolving business needs.

    3. Combining forms with workflows, business rules & Power Automate

    Integrating Forms with Workflows and Business Processes: Forms play a vital role in capturing and updating data as part of larger workflows and business processes. Leverage the Power Platform’s capabilities to automate processes, trigger actions based on form interactions, and integrate with other systems or services. By combining forms with workflows, business rules, and Power Automate flows, you can create sophisticated solutions that streamline and optimize business operations.

    Continual Monitoring and Optimization: Forms should be treated as living entities, requiring continuous monitoring and optimization. Regularly review form usage analytics, user feedback, and business requirements to identify areas for improvement. Monitor performance metrics, such as form load times, and make necessary adjustments to enhance user experience and productivity.

    Wrapping up
    Working with forms on the Power Platform allows you to create intuitive and powerful user experiences while capturing and managing critical business data. By leveraging the knowledge gained from solutions, incorporating best practices for form design and customization, and integrating forms with workflows and business processes, you can unlock the full potential of the Power Platform, enabling efficient data

  • Getting started with model-driven apps – Working with tables

    Getting started with model-driven apps – Working with tables

    This post is a part of a series of 5 post exploring the key things you need to know about, when getting started with building model-driven apps on the Power Platform.
    1. Working with solutions
    2. Working with tables (this post)
    3. Working with forms
    4. Working with views
    5. Working with the App Designer

    UPDATE: If you prefer to follow along in a youtube video instead you can find it here:
    This is the first of 5 posts in my new series exploring the key things you need to know, as a citizen developer, when getting started with building model-driven apps, on the Power Platform.
    1. Working with solutions (this post)
    2. Working with tables
    3. Working with forms
    4. Working with views
    5. Working with the App Designer

    UPDATE: If you prefer to follow along in a youtube video instead you can find it here:
    Getting Start With Model-Driven Apps – Working with Tables


    I recommend starting from the first post and working your way through them.
    In my previous blog post, I explored the essentials of working with solutions on the Power Platform. Building on that knowledge, this post will focus on tables, a fundamental component of model-driven apps.


    Tables are the foundation of data management in Dataverse (formerly CDS), providing a structured way to store and organize information. Understanding how they work and the objects they contain, is key to building great business applications.

    The post is divided in to 4 areas:
    1: Different types of tables
    2: Basic objects that tables contain
    3: Best practice when working with tables
    4: Do’s and don’ts

    1: Different types of tables

    Tables in model-driven apps can be categorized into three main types:
    1. Microsoft standard tables,
    2. Custom tables, and
    3. Virtual tables.

    Microsoft standard tables come pre-built and are always available in Dataverse as part of any Power Platform environment. It is recommended that you use these as much as possible, if they make sense for the application you are building.

    Custom tables are created to cater to specific business requirements. When designing custom tables, there are several things to keep in mind. Most importantly make sure that you use the correct publisher when creating tables, as well as the table elements, and also to create the elements within a solution. This will ensure you can track which objects are created by you or other citizen developers and which objects are standard Dataverse objects, present on the Power Platform.

    Virtual tables, on the other hand, are tables that are not stored in the database but are generated dynamically based on defined criteria. This could be a SharePoint list, an SQL server or any other type of database you would want to use in your application.

    2: Objects within tables

    Tables contain various objects that help users with interacting with their data in a way that makes most sense for the purpose of the application. Citizen developers can apply a variety of different table objects to different areas of the application to make the experience as easy and efficient as possible. Some key objects to know are:

    Columns
    Columns define the attributes or fields that make up the table. Each column represents a specific data type, such as text, number, date/time, or lookup, and allows for data entry, validation, and calculations.

    Forms
    Forms provide the user interface for interacting with table records. They define the layout and presentation of data, including fields, sections, tabs, and subgrids. Forms allow users to view, create, update, and delete records. It is possible to create several different forms that can be used based on user roles/departments/or other groupings. Access to forms can be limited by security roles to ensure data quality and streamline the data input process for different user roles.

    Views
    Views determine how data from each table can be displayed in an easy overview. They define the columns, sorting, filtering, and other criteria for data retrieval. Views provide users with different perspectives on the data, helping them access and analyze information efficiently. It is possible to create multiple views for users depending on different roles or needs in the organization, and users can also create and save their own personal views.

    Business Rules
    Business rules are logical expressions that define automated behaviors within tables. They can change field visibility, set field values, do calculations, as well as other business logic. By applying business rules, you can ensure data integrity and streamline data entry processes.

    3: Best Practice when working with tables

    When working with tables, it’s important to follow best practices to maintain consistency, scalability, and performance. Here are some key considerations:

    – Utilize Microsoft Standard Tables: Whenever possible, leverage Microsoft standard tables for core entities like contacts, accounts, and opportunities. These tables are designed following industry best practices and receive regular updates and enhancements.

    – Create Custom Tables Sparingly: While custom tables provide flexibility, their creation should be limited to specific business requirements that cannot be met with existing standard tables. Overuse of custom tables can lead to complexity and maintenance challenges.

    – Plan and Define Table Structures: Before creating tables, carefully analyze and plan the structure, relationships, and attributes required to store and manage data effectively. A well-defined table structure ensures data consistency and enables future scalability.

    – Establish Naming Conventions: Consistent and meaningful naming conventions for tables, columns, and other objects enhance clarity and maintainability. Consider using prefixes or abbreviations to indicate the table’s purpose or module.

    4: Do’s and Don’ts when working with tables

    To maximize the efficiency and maintainability of your model-driven apps, keep the following do’s and don’ts in mind:

    Do’s:

    • Do define proper relationships between tables to ensure data integrity.
    • Do use security roles and privileges to control access to tables and data.
    • Do document your table structure, including relationships and customizations.
    • Do use a structured and logical approach to creating columns, forms and views across your applications/solutions so avoid confusion.

    Don’ts:

    • Don’t modify or delete standard tables or columns provided by Microsoft.
    • Don’t create unnecessary custom tables when existing standard tables can meet your requirements.
    • Don’t overcomplicate table structures with excessive relationships or dependencies.
    • Don’t overlook security considerations when granting table access to users.

    There are some exceptions to the points of the do/don’t list. Modifying standard tables can be necessary in some cases. What is recommended there is considering if you want your application to use a variation of a standard form/view or to create a customized copy and work on that. Using any standard view/form/field from Microsoft ensures that is it updated and supported, however, any future update will also be included in your own application and could have an unintended effect on your application UI/UX.

    Wrapping up
    Understanding how to work with tables is important for new and experienced citizen developers. Tables are the building blocks of model-driven apps on the Power Platform, enabling efficient data management and app customization. By understanding the different types of tables, their constituent objects, adhering to best practices, and keeping in mind some general do’s and don’ts, you can develop robust and scalable applications that empower users to effectively interact with data.

  • Getting started with model-driven apps – Working with solutions

    Getting started with model-driven apps – Working with solutions

    This is the first of 5 posts in my new series exploring the key things you need to know, as a citizen developer, when getting started with building model-driven apps, on the Power Platform.

    1. Working with solutions (this post)
    2. Working with tables
    3. Working with forms
    4. Working with views
    5. Working with the App Designer

    UPDATE: If you prefer to follow along in a YouTube video instead you can find it here:
    Getting Start With Model-Driven Apps – Working with Solutions

    In this post I will present the most important aspects of solutions that you need to be familiar with, when working with model-driven apps. Even though my focus is mainly on model-driven apps, many of the key points in this post also apply to canvas apps, and other objects on the power platform in general.

    For every problem, there is a Solution

    The Power Platform empowers organizations to create low-code/no-code tailored business applications and streamline their processes effectively. At the heart of this platform are the “solutions”, which serve as containers for organizing, managing, and deploying customizations.

    In this post I am going to cover the 5 key areas that I think are most important to know about when working with solutions:

    1) What are solutions
    2) Managed and unmanaged layers
    3) Best practice when working with solutions
    4) Possible pitfalls
    5) Key differences between working solutions and the app designer

    1. What are solutions?

    So what is a solution? A solution can be seen as the Power Platform framework for dealing with two distinct requirements when developing apps.

    1: The first is the need to have a clear repository of what is being developed (this can be either by a specific person, company, or for a specific change request/issue/etc.).

    2: The second is to manage the transfer of any modifications or customizations between environments – typically from the development environment, over to the test environment, and finally on to the production environment.

    In this way, Solutions act as containers for customizations such as entities, fields, views, forms, workflows, and other objects. They allow users to package and distribute applications, business processes, or specific functionalities as manageable units. Solutions can be exported, imported, and shared across environments, providing a flexible and scalable approach to application development and deployment.

    By doing this, they also provide an easy overview of what is being worked on either by a specific person or team, for a specific application or even for a specific function (the granularity of this can be determined based on your organizational needs). As mentioned above, you should adhere to a best-practice of using solutions to only contain what is being added or modified.

    2. Managed and unmanaged layers

    When working with solutions, it is imperative to understand the key differences between managed and unmanaged solutions, and the consequence of how each are used. I will first explain what the two terms mean, and then provide an example of what happens when solutions layers are applied.

    Unmanaged Solutions
    Unmanaged solutions are primarily used during the development phase. They allow direct customization of components within the solution, providing a highly flexible and iterative approach. With unmanaged solutions, changes made in one environment can be easily merged into another environment. However, caution must be exercised when using unmanaged solutions, as they offer fewer restrictions and can lead to unintended consequences if not managed properly.

    Managed Solutions
    Managed solutions are typically used for distribution and deployment in production environments. They provide a locked-down, packaged experience, ensuring that customizations within the solution cannot be modified directly in the target environment. Managed solutions offer a controlled environment where customizations are only allowed through the solution publisher, ensuring better governance, versioning, and control over the application lifecycle.

    So what does this mean for me as a Power Platform citizen developer?
    The dotted line on the left side represent the solution layer filtering. Everything goes from bottom to the top, and the top layer is always “right”. So irregardless of how many time an object has been altered throughout this filtering, the change made in the top layer will determine what actually happens in the application layer and what the end-user will see.

    A concrete example of this could be the “full name” column in the user table. In the standard Dataverse system layer, the user table has the full name column as the primary name column, but there could be a managed solution where this column was renamed to just be “Name” instead. Then in the unmanaged layer it could be renamed to “Real name”.
    The end result is that the application (including views) would see “Real name” and not any other of the options, as they are further down in the solution layers and therefore not relevant anymore.

    For this reason it is also important to never have unmanaged layers on any other environments than the development environment, as unmanaged layers do not give you any control over the specific objects, nor the ability to roll back changes made. I will make a longer post at a later point diving in to solution management between environments.

    3. Best Practices

    • Plan Ahead: Clearly define the scope and objectives of your solution before starting development to ensure a streamlined implementation.
    • Version Control: Maintain proper versioning of your solutions to track changes, rollback if necessary, and ensure smooth collaboration among team members.
    • Solution Layering: Organize your customizations into multiple layers within a solution, separating base components from customizations, and allowing easier maintenance and upgrades.
    • Documentation: Document your solution design, configurations, and dependencies to aid in troubleshooting, future enhancements, and knowledge sharing.
    • Solution Lifecycle Management: Follow a structured approach for solution deployment, testing, and promotion between environments using tools like Azure DevOps or Power Platform Build Tools.

    4. Possible pitfalls

    There are several things that you need to consider when working with solutions. These are a couple of examples of possible pitfalls:

    • Over-customization: Solutions can become complex if not planned properly, leading to performance issues, conflicts, and difficulty in maintaining and upgrading the solution.
    • Dependency Conflicts: Be cautious when managing dependencies between solutions, as changes made to one solution may impact others.
    • Solution Mismatch: Avoid deploying a solution to an environment where its dependencies or prerequisites are not met, as this can cause errors or unexpected behavior.
    • Data Loss: Exercise caution when uninstalling or removing managed solutions, as it may result in the loss of data associated with those customizations.

    5. Key differences between working solutions and the app designer

    Part five of this series will also cover the app designer in more depth, but I wanted to touch upon some key differences between the App Designer and solutions in this post, as this is important to be aware of at an early stage.

    The App Designer is a visual tool within the Power Platform that enables users to create model-driven apps. As mentioned already, solutions provide a container for organizing and managing customizations. So the App Designer focuses on the design and configuration of the user interface, business logic, and app-specific functionalities. The App Designer thus allows for rapid application development using a low-code approach, while solutions provide a broader framework for managing the entire solution lifecycle, including customizations, dependencies, and deployment.

    Many citizen developers instinctually gravitate towards working with the app designer first as a basis for building their application, which also makes sense from a UI/UX point of view, as this also lets you work with your application in preview-mode and is a graphical approach instead of the “technical” approach of the solution. However, it is important to keep in mind that any changes made in the app designer are not reflected in the solution and therefore, when exporting the solution to a new environment, changes made in the app designer need to be reflected in the solution as well. This is because the app designer itself only provides an overview of which elements are used in the application, whereas the solution only provides the image of what the specific development iteration contains. This can be hard to navigate for new users, as the layers of solutions can become quite complex.

    An example could be adding a table and making modifications to it in an application. Even if the table is a standard CDS table, any modifications made to any objects in the table also needs to be added to the solution itself, or they will not work correctly when running the application on the test and production environments.

    Wrapping up
    Solutions play a crucial role in harnessing the full potential of the Power Platform by providing a structured approach to organizing and deploying customizations. By understanding the concepts of managed and unmanaged layers, as well as avoiding the pitfalls of working with solutions, you are well on your way to becoming a successful citizen developer!

  • Building Communities and enabling Citizen Developers

    Building Communities and enabling Citizen Developers

    I sometimes have the great pleasure of doing Power Platform training for new users. This can be colleagues as well as super-users working with enterprise companies or partner companies. It never ceases to surprise me how incredibly easy it is to get started with the Power Platform, but also how overwhelming it can be to move from the first basic steps to solving only slightly more complex challenges.

    Solving the challenge of enabling the Citizen developer is key to ensure that companies see a return on investment on their investment in the Power Platform.

    Switching on the Power Platform in an enterprise context

    Many professionals working in the ISV space have made the switch to the Power Platform in recent years. This is a great step in the right direction and many companies are also reaping the benefits of this in several areas.

    The recent, and often quoted, Forrester Total Economic Impact study highlights the many clear financial benefits, and also implicitly points to lowering development & configuration time. For consulting companies this gives consultants better tools to help enable companies to focus on their core business. For the companies themselves, this allows them to access tools quickly and with lower development costs, while empowering individuals within the company so they can develop or co-develop new tools that improve their day-to-day operations. This is of course not free, as enterprise companies need to account for not only the price of licenses, but also in supporting the new platform. On top of this there is usually also reliance on external vendors for providing services on the platform.

    While there is even greater potential for both ISVs and enterprise companies adopting the Power Platform, there are some remaining obstacles that prevent companies from being able to fully reach the potential benefits.

    The term Citizen Developer has for the past several years been touted as a key component of the Power Platform strategy, and while this is clear for ISV and consulting companies, the end goal – truly allowing potentially all enterprise employees to become citizen developers and apply the Power Platform tools – can seem out of reach.

    How do citizen developers start on their journey? And how are they supported?

    For Microsoft products there are generally two types of support to be found. The first is the official support, and in this regard, Microsoft offers a plethora of resources on its own blog dedicated to all things Power Platform. The second is the community: Microsoft has always relied on having an active support community for its products. This community is also starting to offer a vast amount of resources on LinkedIn, Twitter, and YouTube. As for accessing information online, in my previous blog post about finding Power Platform help online, I covered some common challenges facing new user’s when doing just that. There is of course also a third option, which is the one I often encounter. That is when companies outsource the problem-solving to ISVs or consulting companies. Even though this puts food on the table for me and my colleagues, it also pains me in some cases, as the platform is supposed to empower all users to create and enhance the Power Apps, and, in the process, reduce development costs and reliance on external resources such as myself. Yet, we still get daily calls and e-mails from people who need our help. This motivated me to write this, to further aid people in becoming citizen developers and support the push towards companies adopting the Power Platform.

    I see two current trends moving forward in supporting the Power Platform roll-out. One is the further development of the citizen developer, the second is the increased focus on having internal resources who support the Power Platform roll-out within the enterprise company.
    My focus is on the first group, and supporting this trend. The second trend is something that I believe comes naturally as more companies buy into the Power Platform.

    Looking at the LinkedIn, Twitter feeds and blog posts from Microsoft business application MVPs and other professionals, the community has clearly recognized the need for information and guides. In my view, the community has two main target groups, the first is other professionals, the MVPs, and consultants that already work with the tools daily. However there is a much larger, and rapidly increasing last group. These are the users with little or no experience, such as super users or other types of internal company resources. There are very few resources available targeted specifically at them. I would argue that this last group is truly the real citizen developers, as the rest of us are, in several cases, actual professional developers.

    Ensuring return on investment

    In the beginning, I mentioned how many companies are investing in the Power Platform. Currently, many more are buying into it as well. We shouldn’t forget that this also means that someone made the decision to do so, and at some point, they will want to see the return. So now that someone is on the hook for those licenses, we should make sure to support those key stakeholders and the department or team around them.

    Building the community

    As is the case for anyone that has been in the community for several years, I could name many amazing individuals that other industry professionals follow closely to know what the newest features are, or which niche areas of the platform we have yet to discover. Among any business application professionals or Microsoft MVPs there is instant recognition of the name and their accolades, but how does this look for new users?
    New users need easy access to guides and tools to quickly solve their problems and get back to focusing on their daily tasks. Every day users do not have unlimited time to search for blog posts and hour-long YouTube videos to find the answer to a simple question. If the material is not available, they will resort to the alternative of using tools they already know already, Excel, SharePoint, etc.

    I would love to get feedback from all types of users in the community on the points raised. Am I missing some key elements? Are we doing exactly what is needed and it just takes time to build naturally, or do we need to do more?

    I think the space for low-code development platforms is at a crucial point and we need to be vigilant about pooling our resources to ensure user adoption to bring in the era of the citizen developer.

  • How to find answers to Power Platform challenges on the web?

    How to find answers to Power Platform challenges on the web?

    How do I find the right answers to my problem? What keywords do I use to find the right solution?

    This guide is largely inspired by this LinkedIn post by Jukka Niiranen, an industry veteran and Microsoft MVP. In the post, Jukka talks about how some parts of the Power Platform still go by the 20-year-old naming convention, CRM, in some registries.

    One problem – Many search terms

    This reminded me of a problem that me and my colleagues often face when trying to solve an issue on the Power Platform. When searching for an answer, what do we type to find the best solution? The first thing I tell colleagues is that they should try to write “CRM” after the query to help filter their results as efficiently as possible. Veterans don’t have to think about doing this, because for them, it is colloquially still called CRM (Update: As Jukka noted in a comment, many industry veterans also use the famous XRM Toolbox, so this is not even an isolated topic related to only CRM). But which other areas should new users be aware of when trying to find answers on Google/Bing?

    Let’s say you want to change the label for one of the choices in a choice column in a table. When googling “change label choice column power platform” you will find a lot of results. Unfortunately, most of them are irrelevant to your question.

    However, if you search for “change label option-set field CRM” you will find several answers that all help you achieve your goal.

    Confused? Me too. Let’s do something about it!

    Overview of past and current names of objects/items on the Power Platform

    Below, I have created an overview of the naming conventions used for the most common objects/items on the Power Platform. This can be a helpful guide when trying to google a problem. Please add comments below for any items I might have missed so they can be added to the list and we can use this going forward as a point of reference.

    I will update this guide with new names if any changes happen after creating this post. The names in bold are the current names being used, the options written below are alternatives that can be used when trying to google a problem.

    Power Platform
    Alternatives are “CRM” “Dynamics CRM” or “CRM 365”. Be aware that when searching for CRM and Dynamics CRM you might find results that relate to either on-prem versions or other Business Applications within Dynamics (F&O, Service, Field Service, etc.)

    Objects
    Alternatives are “Components”

    Dataverse
    Alternatives are “CDS” “Common Data Service” or “Dataflex”.

    Tables
    Alternatives are “Entities”

    Columns
    Alternatives are “Fields”

    Choice/Choices
    Alternatives are “Option set” (single or multi-select option set). Also previously option sets could be local or global. This option is not currently available on the power platform.

    Automation
    Technically all processes are still under the “Processes”. However, the overarching category for any process, be it a workflow, business process flow, an action, or a flow(cloud & desktop)

    Power Automate
    The service used to be called simply “Flow” or “Microsoft Flow”

    Cloud Flows(Automated/Instant/Scheduled) & Desktop Flows
    Previously all these types of flows were simply called “Flows”

    Power Apps
    Previously “PowerApps”

    Power Pages (Also currently called “Power Apps Websites” in some cases)
    Alternatives are “Power Apps Portals” and “PowerApps Portals”

    Also important to note. Some terms have remained unchanged.

    Solutions & Solution Publishers
    Layers (managed/unmanaged)
    Save & Publish changes

    Forms
    Views
    Relationships
    Charts
    Business Rules
    Dashboards

    As mentioned above, this list will be updated based on comments from you and also changes made by Microsoft, so please feel free to reach out to me with additions/changes to the list.

We use cookies to personalise content and ads, to provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics partners.
Cookies settings
Accept
Privacy & Cookie policy
Privacy & Cookies policy
Cookies list
Cookie name Active

Privacy Policy

What information do we collect?

We collect information from you when you register on our site or place an order. When ordering or registering on our site, as appropriate, you may be asked to enter your: name, e-mail address or mailing address.

What do we use your information for?

Any of the information we collect from you may be used in one of the following ways: To personalize your experience (your information helps us to better respond to your individual needs) To improve our website (we continually strive to improve our website offerings based on the information and feedback we receive from you) To improve customer service (your information helps us to more effectively respond to your customer service requests and support needs) To process transactions Your information, whether public or private, will not be sold, exchanged, transferred, or given to any other company for any reason whatsoever, without your consent, other than for the express purpose of delivering the purchased product or service requested. To administer a contest, promotion, survey or other site feature To send periodic emails The email address you provide for order processing, will only be used to send you information and updates pertaining to your order.

How do we protect your information?

We implement a variety of security measures to maintain the safety of your personal information when you place an order or enter, submit, or access your personal information. We offer the use of a secure server. All supplied sensitive/credit information is transmitted via Secure Socket Layer (SSL) technology and then encrypted into our Payment gateway providers database only to be accessible by those authorized with special access rights to such systems, and are required to?keep the information confidential. After a transaction, your private information (credit cards, social security numbers, financials, etc.) will not be kept on file for more than 60 days.

Do we use cookies?

Yes (Cookies are small files that a site or its service provider transfers to your computers hard drive through your Web browser (if you allow) that enables the sites or service providers systems to recognize your browser and capture and remember certain information We use cookies to help us remember and process the items in your shopping cart, understand and save your preferences for future visits, keep track of advertisements and compile aggregate data about site traffic and site interaction so that we can offer better site experiences and tools in the future. We may contract with third-party service providers to assist us in better understanding our site visitors. These service providers are not permitted to use the information collected on our behalf except to help us conduct and improve our business. If you prefer, you can choose to have your computer warn you each time a cookie is being sent, or you can choose to turn off all cookies via your browser settings. Like most websites, if you turn your cookies off, some of our services may not function properly. However, you can still place orders by contacting customer service. Google Analytics We use Google Analytics on our sites for anonymous reporting of site usage and for advertising on the site. If you would like to opt-out of Google Analytics monitoring your behaviour on our sites please use this link (https://tools.google.com/dlpage/gaoptout/)

Do we disclose any information to outside parties?

We do not sell, trade, or otherwise transfer to outside parties your personally identifiable information. This does not include trusted third parties who assist us in operating our website, conducting our business, or servicing you, so long as those parties agree to keep this information confidential. We may also release your information when we believe release is appropriate to comply with the law, enforce our site policies, or protect ours or others rights, property, or safety. However, non-personally identifiable visitor information may be provided to other parties for marketing, advertising, or other uses.

Registration

The minimum information we need to register you is your name, email address and a password. We will ask you more questions for different services, including sales promotions. Unless we say otherwise, you have to answer all the registration questions. We may also ask some other, voluntary questions during registration for certain services (for example, professional networks) so we can gain a clearer understanding of who you are. This also allows us to personalise services for you. To assist us in our marketing, in addition to the data that you provide to us if you register, we may also obtain data from trusted third parties to help us understand what you might be interested in. This ‘profiling’ information is produced from a variety of sources, including publicly available data (such as the electoral roll) or from sources such as surveys and polls where you have given your permission for your data to be shared. You can choose not to have such data shared with the Guardian from these sources by logging into your account and changing the settings in the privacy section. After you have registered, and with your permission, we may send you emails we think may interest you. Newsletters may be personalised based on what you have been reading on theguardian.com. At any time you can decide not to receive these emails and will be able to ‘unsubscribe’. Logging in using social networking credentials If you log-in to our sites using a Facebook log-in, you are granting permission to Facebook to share your user details with us. This will include your name, email address, date of birth and location which will then be used to form a Guardian identity. You can also use your picture from Facebook as part of your profile. This will also allow us and Facebook to share your, networks, user ID and any other information you choose to share according to your Facebook account settings. If you remove the Guardian app from your Facebook settings, we will no longer have access to this information. If you log-in to our sites using a Google log-in, you grant permission to Google to share your user details with us. This will include your name, email address, date of birth, sex and location which we will then use to form a Guardian identity. You may use your picture from Google as part of your profile. This also allows us to share your networks, user ID and any other information you choose to share according to your Google account settings. If you remove the Guardian from your Google settings, we will no longer have access to this information. If you log-in to our sites using a twitter log-in, we receive your avatar (the small picture that appears next to your tweets) and twitter username.

Children’s Online Privacy Protection Act Compliance

We are in compliance with the requirements of COPPA (Childrens Online Privacy Protection Act), we do not collect any information from anyone under 13 years of age. Our website, products and services are all directed to people who are at least 13 years old or older.

Updating your personal information

We offer a ‘My details’ page (also known as Dashboard), where you can update your personal information at any time, and change your marketing preferences. You can get to this page from most pages on the site – simply click on the ‘My details’ link at the top of the screen when you are signed in.

Online Privacy Policy Only

This online privacy policy applies only to information collected through our website and not to information collected offline.

Your Consent

By using our site, you consent to our privacy policy.

Changes to our Privacy Policy

If we decide to change our privacy policy, we will post those changes on this page.
Save settings
Cookies settings