How to work with option set in PowerApps

In this article I’ll share my experience and everything I learned about Option Set in PowerApps. Check out my cheat sheet.

Prepare for a battle

Before I start a project I prepare myself and gather all information that helps me to avoid getting into technical dead ends, improve project delivery pace and work efficiency. I read documentation, articles, watch tutorials and do proper exams (for PowerApps & CDS I can recommend MB-200 exam). Like Abraham Lincoln once said:

Image result for abraham lincoln give me six hours meaning

At the same time, no matter how hard you try you won’t be prepared to everything. Especially in IT projects where you can expect the unexpected. Sometimes you’ll need to solve those corner cases which are “very specific only to your project & to this very unique setup” only you have. But sometimes you just try to do some “ordinary operation” (at least as you think about it) and you discovered that it’s not possible or at least is not easy. The common reason for such situations is that the functionality or feature is so new that documentation does not cover it sufficiently and you can’t find ANYTHING (video, article, blog) that completely covers the topic.

Option Sets for PowerApps Canvas apps are one of those topics and this article is about to group all information together.

CDS Option Set cheat sheet for PowerApps

Did you know: You can contact me if you need my help with PowerApps and Flow. I conduct trainings, consultations, build PoC or Solution and also make an audit of your PowerApps app.

What is Option Set? A field type
What it contains? List of text values
Technical synonyms A dictionary, an array of enums
Main pros Centrally managed
Dynamic extending No, only predefined values
When not to use it? Case 1: 
If you need to reference to Option Set values without creating connection to Entity with this Option Set.
For local usage use Collection.
For global usage use Entity.

Case 2:
You need additional metadata to Option Set values (ie. Country Population)
Solution: Use Entity.

Option Sets in PowerApps

In PowerApps Option set is one of the field types you can use in your Entity. The information type that Option Set stores is a list of text values. And here comes the Option Set advantage – once you define its text values you can centrally managed it.

Imagine you have a list of countries you have offices in. Once you define such list you can use it in any of your apps. And even more than that – you can use it in PowerBi reports, Flow, Dynamics365 and all other applications that can integrate with CDS.

CASE 1: You’re doing so well that you’re opening a new office in a new country. Would you update all solutions that use your Option Set? Of course not! You only need to update your Option Set definition.

Case 2: You’re doing even better and your office in England start to operate all over United Kingdom. Would you add new text value to a list and update all solutions that use your Option Set? Of course not! You only need to rename England to United Kingdom. And that’s it – this is possible because technically speaking Option Set is a table with 2 columns: Id and Text.

The Text column is only for us – the humans. The Id is used by them – computers, programs, solutions etc. And this is where all misunderstandings begins. People are confused “why I can’t use a text value to set Options Set value? Machines are confused “why humans does not appreciate I can distinguish 2 options even if they have the same text value?”

Yes, in CDS Option Set you can have 2 items with the same name. CDS will use Id value to differentiate them.

How to work with the field in PowerApps and Flow?

Let’s split the above question on 2 parts:

  1. How to reference an Option Set Value in Microsoft Flow?
  2. How to use Option Set field in PowerApps?
    • Option Set with Dropdown
    • Filter by Option Set field
    • Update Option Set field using Patch function

How to reference an Option Set value?

Long story short: use the item Id. How to find it?

  1. In PowerApps website open Option Sets
  2. Open your Option Set
  3. Click on “…” > View More

Elaiza Benitez recorded a video where she shows how to use option set value in Flow so I’ll skip reinventing a wheel and just give you a link to the video already starting in the right time.

How to use the field?

Option Set with Choice dropdown

Using Choices function with a name of Option Set works great.

Filter by Option Set field

Use special [@ColumnName] reference that directly point to the Option Set. You’ll see the Option Set values you can easily choose from.

Disclaimer: Last year there was anupdate that improved how PowerApps makers could reference to Option Set field values but…somehow it doesn’t work for me no matter on how many tenants I tried that :(. But I’m sure sooner or later described in above article method (that is reference using ‘OptionSetName (Entity Name)’.Value) will work so stay tuned and treat my post as workaround.

To turn this feature on go to App Settings > Advanced Settings > “Relational data, option sets and other new features for CDS”

Update Option Set field using Patch function

Use the same method as I’ve described in previous section (use [@ColumnName].
Following formula works for me like a charm:


Hope this will be useful for you.

If you have any questions – let me know.

Add fields to SharePoint List using Flow

Last week I’ve explained how to create SharePoint list or library using Microsoft Flow. This time I’ll show you how you can add fields to your SharePoint List using Microsoft Flow, and add items to your list. This will complete the scenario so you’ll get a full solution for dynamic creation SharePoint List along with fields and values.

Automation is the key

Just before I’ll deep dive into the details let’s first cover the question of: why you may even need such dynamic list creation with fields and values?

So imagine you have multiple PowerApps apps for different purposes each ie:

  • time tracking
  • resources booking
  • goals review
  • team members praise
  • retrospective meetings notes

Each app stores data in SharePoint and is team specific – this means some team may want to have it, others not. Also the app data should be team related.

Other often scenario is when you have an app that you want easily deploy in your client’s environment. This was my case when I’ve created my Delegation Playground app that uses SharePoint list – I wanted to automate the process of list creation so app user don’t need to create it manually. I wanted it to be as simple as possible.

In PowerApps there is a Solution concept but it applies only to PowerApps with data stored in Common Data Service (which I highly recommend – check this post of mine) so if your app works with SharePoint Online lists or libraries you may need the below Flow.

The Plan

Ok, so last time we end up with created SharePoint list. Now we need to:

  • Add Number and Boolean fields
  • Add 3000 rows to the list
Image result for over 9000 meme
I wish to make it 9001 but…there are some limits 🙁

Add new fields to SharePoint list using Microsoft Flow

To create new SP field we’ll going to use SP REST API (by using Send an HTTP request to SharePoint action). However this time we need to use new Uri – the one dedicated to list modification. As you can see in this POST request example we need to know list guid to make proper operation. The Uri need to be like:

http://<site url>/_api/web/lists(guid'<your_new_list_guid')

But how to get a newly created list GUID? Oh that’s simple – make a sample call of the Flow we’ve made last time and use data it returns.

Disclaimer: Some of you may already know that there is a simpler Uri API endpoint _api/web/lists/GetByTitle(‘<list name>’) as described here but the way I present brings an additional learning value.

Just follow guideline below 🙂

1. Run Flow that creates list in SharePoint site location
2. Copy its output JSON
3. Add Parse JSON action
4. Put “body” in Content property
5. Click “Generate schema”, paste JSON and click Done
6. Add new string variable
7. As value add id field
8. Selected it and paste into the Expression field
9. Remove closing } and opening @{
10. Add split( on the beginning – we’ll use Split function and use id field value as first argument
11. Add ,’_api’)[1] on the end – we’ll split the string by ‘_api’ substring and take second element from the output collection
The whole expression looks like this:

Now once we have the Uri of our newly create SharePoint list we can use example from this documentation page and use a field type value related to expected field type (all possible sharepoint field types values are here).

Disclaimer: As you can see we’re now working a lot with Microsoft official documentation. I recommend this as a really well written and complete reference source for any O365 developer.

Your action should be configured this way now:

Warning: please note that for number field I used Number field type type value, not the Integer field type value. The latter won’t work

Create similar action to create Boolean field:

Protip: Use copying action to clipboard – it’s new and fancy and I love it. And everyone was waiting for it 😀

Add SharePoint items to SharePoint list using Microsoft Flow

To add 9001 items we’re going to use Microsoft Flow “Do Until” loop. It will do defined operations and at the end of the iteration it will increase the iterator. Once the iterator exceed 9001 flow will know that it’s the right time to go out of the loop.

So add new variable called “Iterator”

Now add Do Until loop and select Iterator variable as value property. Set the check to be “is greater than 3000”. Remember also to unfold Change limits section and increase Count to 3000 items and Timeout to PT5H (just in case 1 hour will be to short)

Warning: Do Until has hard limit on 5000 iterations at maximum.

At this point we’ll normally use “Create item” action for SharePoint in Microsoft Flow. However we’ve just created the list and the mentioned action won’t work with dynamically created list. So…for the forth time we’ll use Send HTTP request to SharePoint 🙂

Protip: “Send HTTP request to SharePoint” is sooo universal and powerful. You can do almost ANYTHING using this action. One of my favorite.

You can find here documentation page where the example Create List Item POST HTTP request is made (see? I told you it’s well written and helpful). Let me show you configured action and code first and then I’ll describe it:

                type: "SP.Data.Delegation_x0020_PlaygroundListItem"  
Title: 'Item @{variables('Iterator')}',

So what I’ve done is (follow my steps):

  1. Add “Send HTTP Request to SharePoint” action inside Do Until loop
  2. Fill Site Address, Method, Uri and Headers as in the screenshot
  3. Paste above code but please make sure to:
    • swap Delegation_x0020_Playground with your list name
    • have ListItem suffix. So for your list named “MyList” the type string will be SP.Data.MyListListItem
    • swap all special characters (like space) in the list name. Good article about it was written here by Stefan Bauer
    • When providing field names remember about special characters rule described above
    • In my case I used expression with modulo function so every even item has Bool field = true

Last thing we need to do is to increase the iterator by 1 inside Do Until loo to not end up with infinite loop.



You’ve just created flow that create list with fields and list items. And everything done with one push of a button to trigger your flow 🙂

Automation is beautiful.

And just in case you want to download ready made solution – you can download it from here 🙂

Hope this post was helpful. Write me a comment if you have any question or used my flow.

Create SharePoint list using Flow

Microsoft Flow is a great automation tool. It integrates with over 230 services using connectors where each of them contains multiple triggers and actions. One of those connectors is a SharePoint Online connector with a set of 10 triggers and 47 actions(!). Such big set allows to create many scenarios. Starting from managing simple resource list to invoice approvals along with permissions on different levels. Even though, SharePoint Online connector does not contains actions like “Create list”. Such actionmay be useful if you want to create those elements dynamically. Before you think “what a bummer” and turn your eyes on custom code solutions please read this article. I’ll show you how you can create SharePoint List or SharePoint Library using Microsoft Flow.

Create list from list template

Before I’ll show you how I did that let me explain why I need this kind of solution.

Last week I’ve publishing Delegation Learning App. The app was an extension to what has been described in article How to overcome 500 items limit in PowerApps. Using my app a user is walkthrough different integration scenarios – static data, excel from onedrive and SharePoint Online. To make all steps easy I wanted the data sources to be already prepared for the user. With static and excel data there was no problem – I’ve simply attached them to app package. But how to prepare SharePoint Online list? I had 2 options:

  1. Give access to my environment – however I didn’t want to add external access for anyone who want to use an app. I didn’t want to create an account which I would be shared to others too.
  2. Prepare an excel that a user can import to his SharePoint Online – however this option has some import column limitations and I my aim was to create an universal solution.
  3. Create a list dynamically using Microsoft Flow – for me this method was perfect. I could defined any list definition and add items to this list. The only thing that the user had to do is import import flow (which is done automatically if you import PowerApps package) and run it.

Now you know why I decided to go with this option. Now let me explain what I’ve used and how it works.

Create SharePoint list using Flow

To achieve my goal I need use “Send as HTTP request to SharePoint” action which allows to execute any action that is available through SPO REST API.

SharePoint Online REST API is a special way of sending instructions to SPO using HTTP requests. I.e. by making HTTP GET call to https://<Site ABCD url>/_api/web/lists you can get a list off all lists in ABCD site.

Did you know?
Your browser is constantly using such way of communication. Every time when you open some web site your browser is making an HTTP GET request. Go ahead, open a new browser tab and try it: paste https://<Site ABCD url>/_api/web/lists URL (of course swap <Site ABCD url> with your own SPO site url) to see the XML representation of all lists that exists in the site along with metadata

To create a SharePoint list I need to do what is described in this section. In above section you can find below example:

1. url: "http://<site url>/_api/web/lists"
2. type: "POST"
3. headers:{
            "content-type": "application/json;odata=verbose",
            "accept": "application/json;odata=verbose"
4. body: { '__metadata': { 'type': 'SP.List' }, 'AllowContentTypes': true,
 'BaseTemplate': 100, 'ContentTypesEnabled': true, 'Description': 'My list description', 'Title': 'Test' }

Let me quickly translate it for you.

1. Hey SharePoint, I'm going to do something with your lists...
2. ...and that'll be a modification (create or update)...
3. ...And in step 4 (that is body) I'll send you the details using JSON notation ("content-type" header). If you want to communicate with me please use the JSON notation ("accept" header)...
4. Ok, so the message is this: <the body>

Normally you would also need to authorize yourself providing an token – OAuth token to be precise – but thanks to MS Flow action, the connector is taking care of it 🙂

The last question you may have now is: “how should I know what to put in the body?”. There is a wonderful resource that explains everything you can do using SharePoint REST API: REST API references and samples (add it to your bookmarks, trust me).

Now, in above knowledge base there is a sub-page where you can find all properties you can use in the body: List Properties. You can find there the definition of all used properties. I.e. Base Template represents a ListTemplateType value (see ListTemplateType reference for template type values).

So the last thing is to…

Bring everything back together

Now let’s convert theoretical knowledge into our Microsoft Flow solution.

Disclaimer: Normally I would paste some image below and describe what it shows + what you need to do to achieve the presented result. But thanks to Clarissa Gillingham I realized that if an image is worth a thousands words, a movie is worth a thousands images (23 images per second to be precise #GeekContent). That’s why I’ll just leave with a movie – I hope it’s self explanatory 🙂

Code used for Send an HTTP request to SharePoint is below:


content-type = application/json;odata=verbose
accept = application/json;odata=verbose

{ '__metadata': { 'type': 'SP.List' }, 'AllowContentTypes': true, 'BaseTemplate': 100, 'Description': 'List with items to work with delegations in PowerApps', 'Title': 'Delegation Playground' }

Ready Flow you can download from here.

PERFECT! Now you can click Flow button, provide ANY SharePoint Site URL you have access to and the defined list will be created there. Is that everything? OF COURSE NOT! A list with the default settings contains only built-in fields which won’t be enough in 99% cases. So now we should add some fields…but this part I’ll cover next week 🙂

Stay tuned!

Multiple RSS feeds to LinkedIn using Flow

In this blog post I’ll show you how you can build your own Microsoft Flow that is triggered by RSS feed and then re-post it to your social media channels eg. LinkedIn, Twitter or Facebook. I’ll give you example scenarios as well as show how you can aggregate multiple RSS feeds and handle them using Microsoft Flow.

Oh, and I also share my flows – download them, import and use them 🙂

Keep updated

Today, it is not enough to be good at something. To be an expert in technology, to sell services / products or to be an influencer (vloger, blogger, podcaster) one should constantly observe changes in the area subject he specializes in. And here comes the challenge – we have a lot of sources on the Internet (news sites, blogs, internet forums, facebook groups, twitter etc) that create information content. Some of them, especially the most official ones (eg the official PowerApps blog), create content at irregular intervals. So in order to be up to date you can:

  • Check manually every day using a web browser if the new content appeared on the site. However, this solution is not very scalable (at 10 sources it starts to be uncomfortable. At 30 we start to think about the meaning of life).
  • Use tools such as Feedly, which observe the latest content using a special summary page with the latest information, the so-called RSS. Today, RSS has the majority of blogs, forums and information services. However, such a solution still requires that we regularly check the selected tool in search of new content.

But if it could be more…

“Keep updated” automated

I love automation. I really do. Automation free my brain memory and processing units so I can focus on more important things. It’s like setting up the alarm instead of constantly checking “what time is now?”.

Some examples of how a one can automate being update:

  1. When a new post appeared on Microsoft Flow blog add me a task to my Todoist (or any other task organizer). BUT! If the new post has been published after 12 PM add the task for tomorrow (so I can keep myself well organized).
  2. When a new app appeared in Power Users PowerApps Gallery reshared in on my LinkedIn

Create RSS feed to LinkedIn Flow

Using Microsoft Flow it’s very easy to do.

3 steps:

  1. In Microsoft Flow portal go to templates and search for RSS (and LinkedIn in my case)
  2. Hit “Create Flow”.
  3. Provide RSS URL


Want to do it from scratch? No problem.

3 steps:

  1. Add a new Automated Flow and use the RSS trigger
  2. Provide RSS URL
  3. Add LinkedIn (V2) action and fill up the fields

RSS feed connector

The heart of the Flow is the RSS connector. It contains multiple fields which you can use in further Flow actions. The list of all fields is displayed below:

If you’re curious how the example RSS trigger data would be look like check code below – it contains everything I received in the Flow once my previous article has been published:

  "id": "",
  "title": "5 steps that increased Office365 adoption",
  "primaryLink": "",
  "links": [
  "updatedOn": "0001-01-01 00:00:00Z",
  "publishDate": "2019-07-05 16:42:42Z",
  "summary": "<p>Implementation of the Office365 environment in an organization is a complex process. It is not enough to create a company account in Office365, buy subscriptions, add users and connect the organization’s domain. You also have to take care of the transfer of company resources, as well as transfer the solutions used in the organization (or … <a href=\"\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> \"5 steps that increased Office365 adoption\"</span></a></p>\n<p>The post <a rel=\"nofollow\" href=\"\">5 steps that increased Office365 adoption</a> appeared first on <a rel=\"nofollow\" href=\"\">Michał Guzowski Consulting</a>.</p>\n",
  "copyright": "",
  "categories": [
    "In english",
    "SharePoint Online",

Multiple RSS triggers

Once you’ll use RSS trigger you’ll notice that it allows only to put one and only one RSS URL. What to do if you have 3 or 10 RSS feeds to follow? Is there a way to subscribe to multiple RSS feeds using Microsoft Flow?

Answer: yes there is but instead of using simple action or action configuration you need to use a bit of architecture pattern of your whole Flow solution. For reference and instruction please check my video below:

#ProTip: it’s good idea to pass an extra information from a RSS triggered Flow to your Aggregator Flow with the name of the origin Flow. When something goes wrong this field shortcut the time of inspecting the communication flow (which flow send the specific data to aggregator).

And that’s it – hope you find this post helpful. If you have any question feel free to leave a comment below or DM on my twitter account.


Thanks to Brad Sams for an inspiration of this post

5 steps that increased Office365 adoption

Implementation of the Office365 environment in an organization is a complex process. It is not enough to create a company account in Office365, buy subscriptions, add users and connect the organization’s domain. You also have to take care of the transfer of company resources, as well as transfer the solutions used in the organization (or take care of their integration) – that is, make the so-called migration. However, it does not guarantee the success of Office365 implementation. In order for the entire operation to be successful, it should be persuaded to change people in the organization. In this article, I will present 5 steps that will increase your chance for effective adoption.

Disclaimer: The steps have been written as a retrospection of the cooperation with one of my clients. Each company is different and requires an individual approach. I encourage you to make an conscious decision which of following steps will be useful to you.

Step 1: Discover the product you bought

Office365 is much more than Outlook, Word, Excel and PowerPoint. Even if we add OneDrive, SharePoint Online, Microsoft Flow and PowerApps to this list, there are still many left! And using only platforms mentioned above, you can achieve a lot (examples can be found here). So what is the total number of platforms/applications in Office365? A very successful combination was made by the team:

Be sure to try the interactive version!

It is worth remembering that each of the products has a huge range of its own functionalities and various configurations that allow you to cover countless scenarios.

Finally, the maximum use of the built-in capabilities of Office365 seems to not have a limit – Microsoft constantly improves its products and adds new opportunities, so the answer to the question “to build yourself or to wait a while” is not obvious at all . I.e. recently appeared the possibility of integrating the Common Data Service with Outlook, which is another argument to use the CDS database as a data container instead of SQL or SharePoint.

Tip # 1: Make sure you have used the maximum of Office365 built-in features before you approach the development of custom solutions

Step 2: Keep it Simple and Straightforward

We, consultants, know that everything can be achieved in various ways. For example, sharing the file can be done from the level of SharePoint, OneDrive application, synchronized folder on the computer, Teams etc. For many people a lot of options are freedom of choice and high integration. But for many, it’s chaos (“so you mean…again…how many ways can I do it?”), lack of coherence (“why sometimes you share file using browser and sometimes directly from a folder on your computer?”) And this makes them want to return to “the safe places “: the old habits and methods they used to use so far – those that were simple, transparent and consistent.

That’s why:

  1. Choose the best and the only right way to proceed. At least at the beginning of implementation. For example, to share a file with people outside the organization, you must first synchronize the OneDrive folder on your computer. Period.
  2. Create instructions for the most key scenarios. For us, these were:
    • Document scanning (using the mobile application)
    • Synchronize all team files on your computer
    • Providing a file to a person outside the organization
    • Submitting the attachments from the email to the channel in the team
    • Planning a meeting with the Teams conference
  3. The statement can not be based on an action that has not been described. For example, if you need to synchronize a folder on your computer at some point, remember to create an instruction to set up such a synchronization

Tip # 2: Choose the best and only right course of action. Clearly communicate it in the organization.

Step 3: Segmentation of users

The language of the needs is important (see the next paragraph), but if the organization is of medium size (more than 50 people) or more, it is impossible to talk to each employee. So one should approach the topic methodically.

  • group employees according to the areas they deal with, for example: finance, processes, IT
  • identify “key people”, ie people who have a high impact on others and / or decision-making and have resistance to implementing new solutions
  • identify “influencers” or people who will be promoters of change. They will help others adapt the change not only out of a sense of duty, but they will also realistically see the benefits of the upcoming changes. Important: try as hard as possible to not force people to take this role! They should be natural, not controlled and managed.

Step 4: Learn the language of needs

Users themselves will not start using ready-made tools. Even if the company thinks otherwise, for some employees, “excel on the local computer is enough”. The reason is simple – tools are just tools. They are there to meet needs. So in order to implement tools effectively:

  1. Understand the needs of users: get to know the context of their work. See what difficulties are currently. Understand why new solutions would not help them (if they say so)
  2. Express your needs: explain to users the needs for which change is being implemented (see scenario 1)
  3. Speak the language of the users’ needs: show them what benefits they will get thanks to the change. How this change will affect their work (see scenario 1)
  4. think out-of-the-box: declaring the user that something can not be done is not testimony. Because what the user actually says is “it can not be done differently for the adopted assumptions, limitations and understanding of the whole process”. He built a wall around his process. Your task is to move every brick of this wall and remove one after another until the wall collapses. It is important that it involves the process itself (that is, the business would continue its goal). (see scenario 2)

Scenario 1 (real life example)

  • [User] “Using OneDrive is pointless, I already have all the files on my disk and when I need it, I send them to other people by email. Why should we move all the files to another place?”
  • [Consultant] “We want to limit the e-mails we send in the organization, and we also want to archive all documents and maintain version history.”
  • [User] “Nothing is lost in emails, but I understand. I will send messages less frequently”
  • [Consultant] “Hm, and remember how much time it takes you to find the last version of the document in email messages. And imagine that you work on the document for 3 days and it was supposed to be sent in an email, but suddenly the computer broke down and you are not able to recover your 3-day job … “
  • [User] “Eh … I understand … maybe it’s actually better. But I have all the shortcuts on the desktop, how do we transfer the files, where are they going to be?” [here was the real reason for the resistance]
  • [Consultant] “Do not worry, we’ll do all the files will be available from your computer and all desktop shortcuts will work. Only the place where these files will be stored will change.”
  • [User] “super!”

Scenario 2 (real life example)

  • [Accountant] “We can not digitize the invoice circulation, because every invoice requires a president’s stamp, unless it is possible to attach a picture of such a stamp … but this is only an additional step in the whole process.
  • [Consultant] “Why is this stuff?”
  • [Accountant] “For the accounting department to know that the president read and accepted the invoice”
  • [Consultant] “And the invoice with the stamp stays later inside the company only?”
  • [Accountant] “Yes”
  • [Consultant] “And if the president came and said:” I read and accept it”, that would be enough?
  • [Accountant] “Yes”
  • [Consultant] “So you use stamps, because it’s faster than personal confirmation and also faster than writing an email. If it was just as simple as: The president gets a notification on the phone and only clicks “accepts” or “reject” and all further communication takes place automatically?
  • [Accountant] “Hm …. well … all in all it could be so …”

Bingo! 🙂

Tip # 3: Challenge “because we work like this”. Inquire. Be inquisitive. 5x Why.

Tip # 4: To learn about the needs of users, conduct a training / workshop with them. At the beginning for the groups of users and later on carry out ad hoc consultations 1 : 1.

Step 5: Make small step at a time

When you enter a lot of new tools, some users may be scared of the number of changes. They will feel lost and will return to the old known processes in which they felt comfortable. Therefore, add new tools and improvements slowly, one by one. If possible, do not multiply new applications. Integrate everything in one place. A good idea is, for example, to start with communication through Teams and define teams there. Then incrementally build a daily work process around Teams. Then talk to the identified employees / employee segments and slowly move the subsequent processes.

Tip # 5: Keep yourself updated – Office365 is constantly evolving.

When to use PowerApps and Microsoft Flow

In my last post I’ve described how security & compliance are solved in PowerPlatform. This post is a summary for all posts series. Moreover I want to give you simple rules when you should and when you should not use PowerApps and Flow. The main reason is just to avoid the dead ends. I hope you’re curious so let’s move on!

What we already know about when to use PowerApps

The whole post series started in affect to the discussion that followed my post about Low-Code platforms (why they’re so popular and the overall market demand constantly increase). During this post series you could read:

  1. What are Low-Code Development Platforms
  2. Real examples of Low-Code solutions
  3. Who can build on Low-Code platforms
  4. Is the PowerPlatform secure?
  5. Summary & Key Takeaways (this post)

I recommend reading them if you’ve not already done that. They cover big picture of Low-Code development platform, especially PowerPlatform (PowerApps, Flow). In case you would like to have a simple bullet-list to follow by, please keep reading – I’ve prepared it for you 🙂

When the PowerPlatform should be a No-Brainer

There are situations in your work or in your personal live when using PowerApps and Flow should be the first thing that comes to your mind. Let me exposure such situations:

  1. Simple repeatable operation occurred frequently and it takes a lot of time in total of a user (e.g. scan business card and import to CRM, book company resource, get holiday approval)
  2. You want to integrate different components or platforms of your digital workplace (e.g. SharePoint + Outlook + Mailchimp)
  3. You want to save time by cutting down the overall implementation time
  4. From my experience most of task-oriented processes (get data from user, add a task in planner, send email…basically things you could define as a tasks list) can be implemented on PowerPlatform.
  5. You want to improve productivity in your Office365 environment
  6. Security and contextual data trimming is important for you
  7. You have a business process implemented in Excel 😉

Of course PowerPlatform is not a universal tool. Having that said it’s crucial to be aware when using those platforms may get us into a dead end (if you’re no developer).

When you need to reconsider using PowerApps or Microsoft Flow

There are specific limitation of PowerApps and Flow – if you meet any of these then be careful and think twice if the PowerPlatform is the right tool. Disclaimer: It doesn’t mean you cannot achieve any of listed below but rather providing such functionality may require advanced software developer skills.

  1. If the UX design (i.e. front-end) has very restrictive requirements (specific controls, drag-n-drop support, support for legacy browser or mobile devices without PowerApps app)
  2. Your application need to support multiple users interaction in real time – yes, you can simulate simple chat in PowerApps but to be honest – PowerApps is not for that.
  3. Gaming – even though you can create simple animations in PowerApps (and sometimes it is very desired), the general purpose of PowerPlatform is far from it. And in the first place performance of the apps does not suit to gaming industry requirements.
  4. Complex calculations in Microsoft Flow – as I tested and confirmed PowerApps has much higher computing power than Microsoft Flow. (even 30x!). This is possible because PowerApps use user device for the computations. However if you need good computation capabilities outside the user device use Azure Function or Logic Apps instead (Logic Apps has so called Integration Service Environment (ISE) which allows for adjusting processing efficiency)
  5. App need to be used by anonymous users or users outside your organization. Although there will be some support for such cases (PowerApps Portals has been already announced) it will provide some limited functionality over normal PowerApps apps.
  6. Role-driven forms and screens in Canvas Apps – this is however greatly supported by model-driven apps
  7. When compliance & logs are very important for you and your business – so for now PowerPlatform has simple support for security and compliance management. But that would definitely change in time.

If not PowerPlatform – then what?

The last questions is if you may not want to use PowerPlatform- then what? You have few options:

  1. Change business requirements – it’s a common misunderstanding that business requirements are untouchable. They are! And sometimes it’s easier and even desired that business could adjust to the whole software solution (application or process)
  2. Use 3rd party solutions for automation – there are other solutions and software tools ready to be use (e.g. UIPath, CodeTwo)
  3. Develop your custom app or script <developers applause> – yes, when your toolbox is not enough you need to manufacture your own tools. C#, React, Frameworks: GO!

Hope this post clarifies few things related to PowerPlatform, PowerApps and Flow.

Thank you for reading up to here.

Let me know if you like it or not!

Security and Compliance in PowerApps and Flow

In my previous article, I’ve brought you closer to the main recipients of PowerApps and Microsoft Flow. In the third part I will take a closer look at the security management in PowerPlatform. And as I promised from the beginning: it will be honest. You will learn from me about things that you do not read in the documentation. Also when you should pay extra attention to security and compliance when working with PowerApps and Flow.


When I started working on this part, I just wanted to discuss issues related to PowerApps and Flow security. With time it turned out that describing the security of a small piece of the service (eg connectors) it is very easy to inadvertently move several threads, each of which should be discussed a little bit more (eg is OAUTH2 secured communication safe? Is the public availability of our services and cloud a good idea?). Not even to say that the security and compliance tools are dependent on the license.

So finally I realized (I admit, a bit too late, hence this post appeared with a slight delay) that in order for this article not to turn into a book, it should be reduced. Therefore, I made the decision that I should only remain on issues related strictly to PowerPlatform. If any topic seems to you that could appear, and it isn’t, then you’re probably right. However, this was a conscious and necessary decision. If you think that it would be worth discussing a topic, let me know in a comment – I will definitely answer. If on the other hand you would like to take a full picture of security, then I recommend watching people like Tomasz Onyszko czy Kamil Bączyk, who in the area of ​​security are one of the best I know.

Security by Design

Going back to the merits.

The reason why I took care of this subject is simple: IT puts a lot of emphasis on security. And the reason is very simple: unauthorized access to data can result in huge property losses. In order not to look far in 2016, it turned out that information on a total of about 3 billion users leaked from the popular (back then) Yahoo site. This resulted in losses of $ 50 million in compensation, $ 350 million in the lower acquisition of Yahoo by Verizon and an additional $ 35 million for dragging the closure of the data leak. A total of $ 435m loss. But this is not the end of problems, because the company’s value is not only a hard currency. It’s also customers. You have been working on their trust for years and you can lose them in a moment. Making up for such a loss is very difficult and very expensive.

Trust is the currency of the future

And that’s why IT engineers put security first. Microsoft even says that it designs its services in such a way that they will be safe first, and then they design the rest: Security-by-design . The questions that appeared in the first part of this series of posts are a living example of the inquisitiveness that engineers apply when it comes to security and management, because they are aware of possible consequences.

Security and Governance in PowerApps and Flow

Security and Governance of solution built with based on PowerPlatform I’ll split on following parts:

  1. Licenses
  2. Connectors
  3. User Context
  4. App sharing & versioning
  5. Environments & Data Policies

Below I will briefly describe what a given form of security is and what to watch out for when using it. However, as I would like to avoid entering into technical nuances, I will refer to more extensive sources.


Licenses are a way to assign user permissions to any work with a given platform. In the Office365 admin panel, as long as we have the appropriate permissions, we can easily assign or take away licenses for the product or application to the user.

What to watch out

Licenses specify general access to the application, but do not define the level of permissions (read-only, edit, delete etc.). When allocating licenses to someone remember to ensure the appropriate level of rights in the application (the service) itself .


As I described the idea of connectors in thesecond part of this seriesit is one of the foundations of PowerPlatform. PowerApps and Flow users have access to over 200 connectors. And if that was not enough, they can build their own connector or use HTTP connectors to connect to any REST / GRAPH API supporting service

The use of such connectors is very simple and easily accessible. After selecting any connector, the user will have access to its methods. Of course, only to those that the provider implemented. However, the supplier is obliged to ensure that the connector provides the appropriate quality of security (authentication), support and SLA. What is important, the supplier must also prove that he owns the website to which the published connector connects. Thanks to this, there will not be a situation when suddenly third companies will start racing for the title of the best supplier of connectors, producing 10 of the same connections, thus littering the collection of connectors.


Connectors in the heads of many give a question whether, besides being easy, they are also safe? While safe can mean a lot:

  • Is the data sent using them will not be intercepted and changed along the way?
  • Will the data reach where we want it to go?
  • How to control from which a connector can a given user use?
  • Where can one find the call logs of a given connector?

First of all, communication with the use of connectors is definitely secure. For this purpose Microsoft enforces the use of proven standards to secure transmission data.

However, at the moment the connectors have a modest layer of managing rights to them and putting down logs. For example, we can define who can create applications (and thus use connectors), but we can not define who the connectors can be used. Similarly, we will not find options to define whiteliste URLs for HTTP connectors or to extract logs containing the URL and body connections made.

Communication with the use of connectors is secure, but their governance is modest…yet

User Context

Basically, this topic fits the previous fragment with connectors, but I would like it to sound good – the user working with connectors works ONLY in his own context. In other words, when working with, for example, PowerApps, you should think of a view of the data to which the user has access. If you should not have something to do or the application would have to work in the context of an account with higher rights, then I do not recommend doing it with PowerApps.

However, theory is just a theory. In life, as everyone knows. I have seen different approaches in IT myself. And I’m not surprised by the serious and large companies that used the usual excel file as their database. Because at the end of the day the effect counts (read: money), not best practices and safe architecture (we only care about it when it starts to threaten the “effect”;)). So sometimes it happens that:

  • you may need to carry out the operation on higher privileges. Then, for this purpose, you can apply the Flow trick that I wrote in this article.
  • based on the group O365 to which the user belongs, you want to limit the visibility of certain controls on the screen. Then you can use the Office365 groups connector available in PowerApps. If the view is limited based on the SharePoint group, the matter gets a bit complicated, but with the help of Flow and Graph API there is a way to go.

If you use PowerApps to control access (eg by conditionally hiding the controls), remember that the user will still have access to the data in the source (eg on the SharePoint list)


Some connectors do not use the user context and require a service account – an example is the example of SQL connector. Then, when using the application, the user’s context is not taken into account. The connection works within the context of the given service account. This means that if the user had the additional ability to create an application, he could use the connector to get to any board or view to which the service account has access (!). It is worth remembering. But there is a way shown by PowerApps guru – Shane Young. This method uses an additional environment (so-called environment) and appropriate permissions on it. More in the video below:

App sharing & versioning

For each application, you can define users who can use it and edit it.

In the above image, pay attention to the information at the co-owner checkbox: even if we add the user as co-owner, he will not be able to delete the application or change the owner.

On this occasion, we can observe one more interesting thing – the CDS connector has an additional option of role management:

CDS has extra permissions model (security roles) . Only CDS.

Each application, apart from the sharing option, also has a versioning mechanism.

Each time the application is saved, it will leave a separate entry in the repository. Thanks to this, we can go back to any version at any time. In addition, the publicly available version for everyone is marked with the appropriate label. So the versioning mechanism allows you to sleep peacefully, that if any of the Co-owners spoils in the application, everything will be able to recover.


As I wrote, co-owers can not delete the PowerApps application – only owner can do it. But if he does, then there is NO way to reverse it. So it is worth to export your application from time to time in a safe place.

Export full versions of your applications. If you ever lose them for some reason, the exported packages will be your last resort.

Environments & Data Policies

Environment, are special containers for applications and connectors under tenant. Tenant can have many environments, and each environment can contain a lot of applications and connectors. What is important, environments do not share content with each other, and what’s more, each of them can have a unique definition of macros and users. Users can use the content of the environment. Makeers can create their own apps in it. It is easy to imagine the example architecture of environments in the organization: production, testing and development.

In addition to environment permissions, you can also define Data Policies, which are special rules about which connectors can share information with each other.

For the above example, no PowerApps or Flow application can display any of the “Business data only” connectors and the connector from the “No business data allowed” group at the same time. When this happens, we will see an error while trying to add an unacceptable connector

What’s important – the created policy works immediately on all applications. Where they find unlicensed connectors, they simply stop reporting data. In the case of Flow, they will be turned off.

Environments are containers for applications and connectors in the organization. The minimum recommended set of environments is Production and Test.


As in the case of connectors, governance of environments and policies is still modest. And sometimes it would be useful to be able to exclude certain connectors from use. Or at least limit the people who can use them. Because the division into business data and non-business data alone does not protect the organization from the fact that someone builds 2 apps and combines them, for example, with an excel file. So if you put the utmost caution to data security, you can still give yourself a moment to improve the above mentioned tools. As I observe Microsoft’s actions, it is a matter of time when the tools for governance and security will be upheld.

So if there are any dangers to be considered with each of the above options, is there any sense now to use PowerApps and Flow?

PowerPlatform is not a cure for everything

If you’ve read my previous entry, you know that PowerApps and Flow are not meant to replace 100% of solutions. They are to replace 80% of these small and simple applications that accelerate daily work, while saving time and energy for programmers. Thanks to this, they can deal with more difficult cases than the hundredth implementation of the task list. Because knowing life will not be a standard implementation anyway. This time, the requirements will be difficult for someone from marketing who will come up with the idea that he wants to have integration with this service whose developer has just left the company and you will need to learn this site first. That is a month of work … unless the quote is raised two times to put an intern behind the keyboard. And then there will only be moans, shock and disbelief that a simple application to organize meetings took 3 times as much and cost 5x more than initially assumed (intern makes mistakes, mistakes must be corrected).

The art of choice

The solutions built on the basis of low-code platforms are therefore about knowledge, knowledge of the possibilities of various ready-made services (not only Microsoft), understanding of their flexibility and, above all, understanding of business. And paraphrasing the famous joke (choose 2 of 3ech: fast, cheap, good), projects in a company operating at the interface between business and IT would like to be done by a person who:

  1. He understands business well
  2. Has a tooling understanding
  3. He has specialist technical skills

Choose 2 of the above.

The art of compromise

PowerApps and Microsoft Flow is a lever that does not give the user more than he could, but allows him to do things more easily and on a larger scale. This, of course, is a compromise between work streamlining and configurability. Between trust and control. But isn’t it a fundamental trend in IT?. If this were not the case, then we would still write in assembler and we would not create languages that would allow us to write faster and easier, frameworks implementing complex operations using one method, and we would not build Open Source solutions. The demand for programmers is not diminishing, so solutions are built up as simple as possible to be adopted by new adepts.

My point is that programmers should be more in number (thus creates a natural stratification). And they themselves are relieved of simple tasks (especially when it can be done by someone else just as quickly and not worse).


PowerPlatform gives you some control and information security mechanisms. So far, it’s still modest, but with time it will certainly be developed (as announced during MBAS2019). But I doubt that they will reach the level of configurability and control that gives us a written inhouse .NET application embedded on IIS installed on our on-premis server. However, it seems to me that PowerApps and Flow does not even start on such a race against full code .NET app. It is like a fast agile car that you can take to move around a city. And if you want to go to war, take a tank.

Bezpieczeństwo w PowerApps i Flow

W moim poprzednim artykule przybliżyłem Ci głównych odbiorców PowerApps i Microsoft Flow. W części trzeciej przyjrzę się bliżej kwestiom zarządzania bezpieczeństwem w PowerPlatform. I tak jak obiecywałem od początku: będzie szczerze. Dowiesz się o ode mnie o rzeczach o których nie wyczytasz w dokumentacji i które podkreślą kiedy należy przyłożyć szczególną uwagę w kwestiach bezpieczeństwa pracując z PowerPlatform


Kiedy rozpoczynałem pracę nad tą częścią chciałem poruszyć tylko kwestie związane z bezpieczeństwem PowerApps i Flow. Z czasem okazało się, że opisując bezpieczeństwo małego fragmentu usługi (np konektorów) bardzo łatwo nieopatrznie poruszyć kilka wątków z których każdy wypadałoby troszkę szerzej omówić (np czy komunikacja zabezpieczona OAUTH2 jest bezpieczna? Czy publiczna dostępność naszych usług i chmura to dobry pomysł?). No i nie wspomnę, że możliowści zabezpieczania są zależne od licencji. Jednak Zdałem sobie w końcu sprawę (przyznaję, trochę za późno stąd też ten wpis pojawił się z drobnym poślizgiem), że aby ten artykuł nie zamienił się w książkę, to należy go solidnie zredukować. W związku z tym podjąłem decyzję, że należy pozostać tylko przy kwestiach dotyczących stricte PowerPlatform. Jeśli jakaś kwestia wydaje Ci się, że mogłaby się pojawić, a nie ma, to zapewne masz rację. Była to jednak świadoma i konieczna decyzja. Ale jeśli uważasz, że jakąś kwestię warto byłoby omówić szerzej, to daj znać w komentarzu – na pewno odpowiem. Jeśli natomiast interesowałby Cię pełny obrazek security, to polecam obserwować osoby takie jak Tomasz Onyszko czy Kamil Bączyk, które w obszarze security znają się jak mało kto.

Security by Design

Wracając do meritum. Powód dla którego zająłem się tym tematem jest prosty: w IT kładzie sie duży nacisk na bezpieczeństwo. A powód jest bardzo prosty: nieautoryzowany dostęp do danych może przynieść ogromne straty majątkowe. Żeby nie szukać daleko w 2016 roku wyszło na jaw, że z popularnego (wtedy) serwisu Yahoo wyciekły informacje dotyczące łącznie ok. 3 mld użytkowników. To spowodowało straty w wysokości 50mln dolarów z tytułu odszkodowania, o 350mln dolarów niższą kwotę przejęcia Yahoo przez Verizon oraz ekstra 35mln dolarów za przeciąganie zamknięcia sprawy wycieku danych. Łącznie 435mln dolarów straty. Ale to nie koniec problemów, bo wartość firmy, to nie tylko twarda waluta. To także klienci czyli użytkownicy. Na ich zaufanie pracuje się latami, a stracić je można w chwilę. Odrobienie takiej straty jest bardzo trudne i bardzo kosztowne.

Zaufanie to waluta przyszłości

I dlatego właśnie inżynierowie IT stawiają bezpieczeństwo na pierwszym miejscu. Microsoft mówi nawet, że swoje usługi projektuje tak by wpierw były bezpieczne, a potem dopiero myśli o całej reszcie: tzw. Security-by-design. Pytania, które pojawiły się w pierwszej części niniejszej serii wpisów są żywym przykładem dociekliwości jaką przykładają inżynierowie, kiedy w grę wchodzi bezpieczeństwo i zarządzanie nim, bo są oni świadomi możliwych konsekwencji.

Bezpieczeństwo oraz zarządzanie w PowerApps i Flow

Bezpieczeństwo i tzw. Governance rozwiązań opartych o PowerPlatform rozbić można na kilka podpunktów:

  1. Licenses
  2. Connectors
  3. User Context
  4. App sharing & versioning
  5. Environments & Data Policies

Poniżej opiszę po krótce na czym polega dana forma zabezpieczenia oraz na co należy uważać przy jej stosowaniu. Ponieważ jednak chciałbym możliwie nie wchodzić w niuanse techniczne, to będę odsyłał do obszerniejszych źródeł.


Licencje to sposób na przypisanie uprawnień użytkownikowi do jakiejkolwiek pracy z daną platformą. W panelu administracyjnym Office365, jeśli tylko posiadamy odpowiednie uprawnienia, możemy w prosty przydzielić bądź zabrać użytkownikowi licencje do produktu bądź aplikacji.

Na co uważać

Licencje określają ogólny dostęp do aplikacji, ale nie definiują poziomu uprawnień (read-only, edit, delete itd). Przydzielając komuś licencje pamiętaj aby zadbać o odpowiedni poziom uprawnień w samej aplikacji (usłudze).


Tak jak opisywałem w drugiej części tej serii idea konektorów, to jeden z fundamentów PowerPlatform. Użytkownicy PowerPlatform mają dostęp do ponad 200 konektorów. A gdyby to było za mało, to mogą zbudować własny konektor lub użyć konektorów HTTP do połączenia się z dowolnym serwisem wspierającym REST/GRAPH API

Korzystanie z takich konektorów jest bardzo proste i łatwo dostępne. Po wybraniu dowolnego konektora użytkownik uzyska dostęp do jego metod. Oczywiście tylko do tych które zaimplementował dostawca. Natomiast dostawca ma obowiązek zadbać aby konektor zapewniał odpowiednią jakość bezpieczeństwa (uwierzytelnianie), wsparcia i SLA. Co ważne dostawca musi także udowodnić, że ma prawa własności do serwisu z którym łączy się opublikowany konektor. Dzięki temu nie będzie sytuacji w której nagle firmy trzecie zaczną robić wyścigi o miano najlepszego dostawcy konektorów produkując 10tki takich samych połączeń zaśmiecając tym samym kolekcję konektorów.


Konektory w głowach wielu rodzi pytanie czy poza tym, że łatwe, to są one także bezpieczne? Przy czym bezpieczne może oznaczać bardzo wiele:

  • Dane przesyłane za ich pomocą nie zostaną przechwycone i zmienione po drodze?
  • Czy dane dotrą tam, gdzie chcemy aby trafiły?
  • W jaki sposób kontrolować z którego konektora może korzystać dany użytkownik?
  • Gdzie znaleźć logi wywołań danego konektora?

Przede wszystkim z całą pewnością komunikacja z wykorzystaniem konektorów jest bezpieczna. W tym celu Microsoft wymusza korzystanie sprawdzonych standardów do zabezpieczenia przesyłu danych.

Jednakże na chwilę obecną konektory posiadają skromną warstwę zarządzania uprawnieniami do nich i odkładania logów. Np możemy zdefiniować kto może tworzyć aplikacje (i tym samym korzystać z konektorów), ale nie możemy już zdefiniować kto jakie konektory może wykorzystywać. Podobnie nie znajdziemy opcji by dla konektorów HTTP zdefiniować whiteliste URLi czy wydobyć logi zawierające URLem oraz body wykonanych połączeń.

Komunikacja z wykorzystaniem konektorów jest bezpieczna, ale ich governance jest jeszcze skromny

User Context

W zasadzie ten temat pasuje do poprzedniego fragmentu o konektorach, ale chciałbym aby dobrze wybrzmiał – użytkownik pracując z konektorami działa WYŁĄCZNIE we własnych kontekście. Innymi słowy pracując np z PowerApps powinieneś myśleć jak o widoku danych do których użytkownik ma dostęp. Jeśli do czegoś mieć nie powinien lub aplikacja miałaby zadziałać w kontekście konta o wyższych uprawnieniach, to nie polecam realizować tego za pomocą PowerApps.

Jednak teoria, to tylko teoria. W życiu jak bywa każdy wie. Sam widziałem różne podejścia w IT. I nie dziwią mnie już poważne i duże firmy, które jako bazę danych używały zwykłego pliku excel. Bo na koniec dnia liczy się efekt (czyt: pieniądz), a nie best practices i bezpieczna architektura (nią przejmujemy się dopiero wtedy gdy zaczyna zagrażać “efektowi” 😉 ). Tak więc czasem zdarza się, że:

  • możesz potrzebować zrealizować operację na wyższych uprawnieniach. Wtedy do tego celu możesz zastosować sztuczkę z Flow o której pisałem w tym artykule.
  • na podstawie grupy O365 do której przynależy użytkownik chcesz ograniczyć mu widoczność pewnych kontrolek na ekranie. Wtedy możesz skorzystać z konektora Office365 groups dostępnego w PowerApps. W przypadku ograniczenia widoku na podstawie grupy SharePoint sprawa nieco się komplikuje, ale z pomocą Flow i Graph API jest do zrobienia.

Jeśli użyjesz PowerApps do kontroli dostępu (np poprzez warunkowe ukrycie kontrolek), to pamiętaj, że użytkownik dalej będzie miał dostęp do danych w źródle (np na liście SharePoint)

Na co uważać:

Niektóre konektory nie wykorzystują kontekstu użytkownika i wymagają podania konta serwisowego – takim przykładem jest np SQL connector. Wówczas przy korzystaniu z aplikacji kontekst użytkownika nie jest brany pod uwagę. Połączenie działa w ramach kontekstu podanego konta serwisowego. To oznacza, że gdyby użytkownik miał dodatkowo możliwość tworzenia aplikacji, to mógłby z pomocą konektora dostać się do każdej tablicy czy widoku do której ma dostęp konto serwisowe(!). Warto o tym pamiętać. Ale jest na to sposób pokazany przez guru PowerApps – Shane Young. Sposób ten wykorzystuje dodatkowe środowisko (tzw. environment) oraz odpowiednie uprawnienia na nim. Więcej w filmie poniżej:

App sharing & versioning

Dla każdej aplikacji można zdefiniować użytkowników mogących jej używać jak i ją edytować.

Na powyższym obrazku zwróć uwagę na informację przy checkboxie Co-owner: nawet jeśli dodamy użytkownika jako co-ownera, to nie będzie on mógł usunąć aplikacji bądź zmienić ownera.

Przy tej okazji możemy zaobserwować jeszcze jedną ciekawą rzecz – konektor CDS posiada dodatkową opcję zarządzania rolami:

CDS posiada dodatkowy model uprawnień (security roles) . Tylko CDS.

Każda aplikacja poza opcją udostępniania posiada również mechanizm wersjonowania.

Każdorazowe zapisanie aplikacji zostawi w repozytorium oddzielny wpis. Dzięki temu w każdym momencie możemy cofnąć się do dowolnej wersji. Dodatkowo wersja dostępna publicznie dla wszystkich jest oznaczona odpowiednią etykietą. Tak więc mechanizm wersjonowania pozwala spać spokojnie, że jeśli któryś z Co-ownerów popsuje w aplikacji, to wszystko będzie do odratowania.

Na co uważać

Jak już pisałem co-ownerzy nie mogą usuwać aplikacji PowerApps – może to zrobić tylko owner. Ale jeśli już to zrobi, to NIE MA sposobu na odwrócenie tego. Tak więc warto co jakiś czas robić export swojej aplikacji w bezpieczne miejsce.

Rób eksport kolejnych pełnych wersji swoich aplikacji. Jeśli kiedyś z jakiegoś powodu je stracisz, to wyeksportowane paczki będą Twoją ostatnią deską ratunku.

Environments & Data Policies

Środowiska, to specjalne kontenery na aplikacje i konektory w ramach tenanta. Tenant może posiadać wiele środowisk, a każde środowisko może zawierać mnóstwo aplikacji i konektorów. Co ważne środowiska nie współdzielą między sobą swojej zawartości, a co więcej każde z nich może posiadać unikalną definicję makerów i userów. Userzy mogą korzystać z zawartości środowiska. Makerzy mogą w nim tworzyć własne apki. Łatwo więc wyobrazić sobie przykładową architekturę środowisk w organizacji: produkcja, test i development.

Oprócz uprawnień na środowisku można jeszcze zdefiniować Data Policies czyli specjalne reguły mówiące o tym które konektory mogą współdzielić między sobą informację.

Dla powyższego przykładu w żadnej aplikacji PowerApps czy Flow nie może pojawić któryś z konektorów grupy “Business data only” i jednocześnie konektor z grupy “No business data allowed”. Gdy tak się stanie zobaczymy błąd podczas próby dodania niedozwolonego konektora

Co ważne – utworzona polityka działa natychmiastowo na wszystkich aplikacjach. Tam, gdzie znajdują niedozwolone konektory po prostu przestają one zwracać dane. W przypadku Flow flowy zostaną wyłączone.

Środowiska to kontenery na aplikacje i konektory w organizacji. Minimalny zalecany zestaw środowisk to Produkcyjne i Testowe.

Na co uważać

Podobnie jak w przypadku konektorów governance środowisk i polityk jest jeszcze skromny. A czasem przydałoby móc wykluczyć pewne konektory zupełnie z użycia lub chociaż ograniczyć osoby mogące z nich korzystać. Bo sam podział na business data i non-business data wcale nie chroni organizacji przed tym aby ktoś zbudował sobie 2 apki i połączył je np plikiem excel. Więc jeśli przykładasz najwyższą ostrożność do bezpieczeństwa danych, może jeszcze daj chwilę na usprawnienie w/w narzędzi. Jak obserwuję poczynania Microsoftu, to jest kwestią czasu, kiedy narzędzia do governance i security zostaną upsrawnione.

Skoro więc przy każdej z powyższych opcji istnieje jakieś niebezpieczeństwo na które należy uważać, to czy jest sens już teraz wykorzystywać PowerApps i Flow?

PowerPlatform to nie jest lekarstwo na wszystko

Jeśli czytałeś mój poprzedni wpis, to wiesz, że PowerApps i Flow nie mają zastąpić 100% rozwiązań. Mają zastąpić 80% tych małych i prostych aplikacji, które przyspieszają codzienną pracę, a jednocześnie oszczędzają czasu i energię programistom. Dzięki temu mogą się oni zająć trudniejszymi przypadkami aniżeli setna implementacja listy zadań. Bo i tak znając życie to nie będzie standardowa implementacja. Tym razem wymagania utrudni np ktoś z marketingu kto wymyśli sobie, że chce mieć integrację z tym serwisem którego developer odszedł właśnie z firmy i trzeba się bedzie wpierw nauczyć tego serwisu. Czyli jakiś miesiąc pracy…o ile wycena nie zostanie podniesiona dwókrotnie by za klawiaturą posadzić interna. A potem będą już tylko jęki, szok i niedowierzanie, że prosta aplikacja do organizowania spotkań zajęła 3 razy tyle i kosztowała 5x więcej niż początkowo zakładano (intern robi błędy, błędy trzeba poprawić).

sztuka wyboru

W rozwiązaniach budowanych w oparciu o platformy low-code chodzi więc o wiedzę, znajomość możliwości różnych gotowych usług (nie tylko Microsoft), rozumienie ich elastyczności oraz przede wszystkim rozumienie biznesu. I parafrazując słynny żart (wybierz 2 z 3ech: szybko, tanio, dobrze), projekty w firmie operujące na styku biznesu i IT chciałbyś aby wykonała osoba która:

  1. Dobrze rozumie biznes
  2. Posiada rozeznanie narzędziowe
  3. Posiada specjalistyczne umiejętności techniczne

Wybierz 2 z powyższych.

Sztuka Kompromisu

PowerApps i Microsoft Flow to lewar, ktory nie daje userowi wiecej niz on sam by mogl, ale pozwala mu zrobic pewne rzeczy prościej i na wieksza skale. To oczywiscie jest pewien kompromis miedzy usprawnianiem pracy a konfigurowalnością. Między zaufaniem a kontrolą. Ale to chyba fundamentalny trend w IT(?). Gdyby tak nie było, to nadal byśmy pisali w assemblerze i nie tworzylibyśmy języków pozwalających pisać szybciej i łatwiej, frameworków realizujących złożone operacje za pomocą jednej metody i nie budowalibyśmy rozwiązań Open Source. Zapotrzebowanie na programistów nie maleje, więc buduje się rozwiązania możliwie proste do zaadoptowania przez nowych adeptów. Chodzi o to aby programistow moglo byc wiecej (tym samym tworząc naturalne rozwarstwienie) a oni sami odciążeni od prostych zadań (szczególnie, gdy może to wykonać ktoś inny równie szybko i wcale nie gorzej).


PowerPlatform daje pewne mechanizmy kontroli i bezpieczeństwa informacji. Póki co jeszcze skromne, z czasem z pewnością zostaną rozwinięte. Ale wątpię by osiągnęły one poziom konfigurowalności i kontroli jaki daje nam napisana wewnętrznie aplikacja .NET osadzona na IIS zainstalowanym na naszym serwerze on-prem. Jednak wydaje mi się, że PowerApps i Flow nie pretendują do takiego miana. To ma być szybki zwinny samochód do poruszania się po mieście (że tak pozwolę sobie na porównanie). A jeśli chcesz jechać na wojne, to weź czołg.

PowerApps and Microsoft Flow target – part 2

In my previous article, I’ve introduced the most important features of PowerApps and Microsoft Flow platforms, basing on examples of three different organizations. In this part, I will present who these platforms are addressed to. Moreover, I will also explain what are the reasons for the growing popularity of Microsoft Low-Code platforms. Let’s start with the basic question.

Who can build solutions in PowerApps and Microsoft Flow?

Ever since these platforms have appeared on the market, they tend to be described as Low-Code or even No-Code platforms. There is no full accordance regarding its naming. Similarly, there is no agreement whether all people or only technical persons can work on the platforms mentioned above. Do people outside of IT as sellers, traders and managers can benefit from these platforms? To answer these questions I will discuss 2 issues:

  • Is PowerPlatform a No-Code platform?
  • Is PowerPlatform for everyone?

There is no No-Code

By definition, No-Code concept does not require writing ANY code. The whole process of building the solution is based on the use of a special wizard where it can be built using the drag-n-drop method. It would imply that the above-mentioned tools are so simple that ANYONE could use them to build solutions. In this case, the application developer does not even have to be a programmer. Then such a person starts using one of the platforms mentioned and surprisingly it turns out that:

  • platforms use a specific function language with syntax
  • they have IF condition blocks
  • they have loops
  • they use the concept of variables and collections.

For those of you who first time see above items, I’ll explain – these are universal concepts that characterize all programming languages. Below a conclusion of one of my favorite influencers, Jon Levesque:

PowerApps and Microsoft Flow are not a No-Code platforms.

Of course, I do not mean that Microsoft does not have any No-Code platforms. They have quite a lot of them, and in order to not looking far enough, I’ll give an example of Microsoft Forms (an interesting review of this platform was written by Tomasz Poszytek on his blog). But certainly, PowerApps and Microsoft Flow do not belong to them.

Now let’s deal with the second, hotter issue, whether anyone can create solutions on these platforms.

ANYONE can’t do programming

Since we already know that PowerApps and Microsoft Flow are not No-Code platforms, can we still recommend them to everyone? I intentionally used the word ‘programming’ rather than ‘coding’ in the headline . To build solutions, you do not have to write code, but still you use programming skills. It is enough to build a solution based on the fact that it is:

  • a repetitive process (not necessarily a business one)
  • based on the capabilities of a specific platform or platforms
  • implements a repetitive sequence of cause-and-effect events
  • a complete solution carries the marks of uniqueness (ie not the functionality out-of-the-box platform)
  • (probably you could add something more, but it’s enough for my needs).

In this perspective, even No-Code platforms require programming skills. Both Microsoft Forms, SharePoint, MailChimp and WordPress etc. need a certain degree of understanding of knowledge (often technical) and learning about the capabilities of platforms. I would like to put a special emphasis on “UNDERSTAND”, because this is often an overlooked aspect. Please note that with increasing complexity of solutions increases the likelihood of errors. And then the skill of the so-called debugging, the process of finding and repairing errors, will be needed. Unless you want to run every time to your IT department with a request such as “DO NOT WORK HERE! REPAIR!” … but I guess it’s not that the whole idea of No-Code / Low-Code platforms. I will not mention that sometimes much more sophisticated skills, such as reverse engineering, are also useful.

To illustrate the issue even better, let’s look at what Bob Reselman, a programmer, architect and journalist with many years of experience says about it, in one of his articles:

For example, imagine using a low-code visual composer to bind data from a poorly written SQL query to a UI. All should work fine, right? That’s the promise. Everything should be peachy keen, except that the app is slow as molasses in February. Why is it so slow? DB? UI code? The network?

Most likely, the low-code software developer won’t know. He was not hired to know. He was hired to drag and drop components to create business forms, not to do data performance debugging.

TechTarget, Bob Reselman

And although I do not agree with everything that Bob wrote in the whole article, this piece has some truth in it. Low-code software developers are not software developers. But all in all … is not that just the point? Because…

Not everyone can create solutions based on the Low-Code platform, but definitely more people can do it than just developers.

Did you wonder why the ideas of Citizen Developers (programmers of Low-Code platforms) and the possibility of easy building solutions are propagated so intensely? It seems to me that there are 2 reasons for this.


I have already written about the problems on the developers’ market in my article ‘What are Low-Code platforms‘. Huge staff shortages (it is estimated that in 2020 there will be a shortage of 500,000-600,000 programmers on the European market), which means that developers, as befits luxury goods, have a high price. Implementation of IT solutions is often an extremely expensive undertaking (requirements analysis, architecture, infrastructure, licenses, programmer’s hour of work, adoption, maintenance, etc.). To make matters worse, the work of programmers is not effective, because they repeatedly implement the same parts of the application (login layer, permissions, data link layer, etc.). This raises the following conclusions:

  1. Developers need relief in simple tasks. More vividly, to replace a wheel in a car, you do not need rocket engineer services.
  2. Ideally, if we would only once create a given functionality. Do not reinvent the wheel. Let us use parts of solutions repeatedly.

And with this in mind, Low-Code platforms were built. In particular, PowerApps and Microsoft Flow emphasize the following:

  • maximum coverage of repetitive parts of the application (login layer, permissions, data link layer, etc.)
  • integration support by using a wide range of “connectors” (not only for Microsoft platforms)
  • extensibility (the ability to build your own connectors based on generally accepted IT standards)


When in 2018 along with a friend for almost a year we were conducting a start-up after hours, life gave us a valuable lesson. We had an idea for solving a problem of the HR industry, and more specifically for career counseling. It seemed to us that we had everything to get from the so-called side-hustle to build a real value wrapped in a scalable product:

  • We had an idea of what effect we want to achieve
  • We had technologies: me and my colleague worked in IT, programming and machine learning algorithms were not a problem for us.

Our plan was to obtain funding, but investors’ doors still did not want to accept us. When finally came time for reflection, we understood what was missing. Technical skills and the target effect are not everything. You still need to know HOW. In our case, there was no specialization in the field of career counseling – we did not have a person who would be able to develop an appropriate psychometric test and interpret its results.

Many companies have a similar problem. They have IT that can implement everything but does not know what. They also have non-IT departments who know what they need, but they do not know how. It is enough to combine both, right? Exactly – and then suddenly it turns out that IT is expensive (see the previous paragraph).

Screen from
Screen from


The whole concept of Low-Code platforms in the PowerApps and Microsoft Flow area is designed to solve the issue of high costs of IT projects and to eliminate problems resulting from narrow specialization.

Microsoft’s Low-Code platforms reduce the costs generated by IT solutions and support the interdisciplinary work environment.

Thanks to PowerApps and Microsoft Flow, non-IT people who have technical skills (a necessary condition!) can easily show and even build what they need. On the other hand, developers and administrators can support them in more difficult areas, help in integration and even expand the capabilities of platforms (through Custom Connectors).

PowerApps and Microsoft Flow developers = Low-code developers = Citizen Developers
PowerApps and Microsoft Flow developers = Low-code developers = Citizen Developers

You’ll be surprized at how many people outside of IT in your organization are doing great with technical topics. All you have to do is help them get started.

It’s all in this part. In my next article I will discuss issues related to the security of PowerApps and Microsoft Flow solutions.

Stay tuned!

Target dla PowerApps i Microsoft Flow cz.2

W moim poprzednim artykule pokazałem na przykładzie 3ech różnych organizacji najwazniejsze cechy platform PowerApps i Microsoft Flow. W tej części wytłumaczę Ci do kogo kierowane są te platformy. Objaśnię także jakie są moim zdaniem przyczyny rosnącej popularności platform Low-Code Microsoft. Zacznijmy więc od podstawowego pytania.

Kto może budować rozwiązania w PowerApps i Microsoft Flow?

Od kiedy tylko tytułowe platformy pojawiły się na rynku, mówi się że są one platformami typu Low-Code, a nawet No-Code. Tutaj nie ma pełnej zgodności. Tak samo nie ma zgodności czy z w/w platform mogą korzystać wszyscy czy tylko osoby techniczne. Czy osoby spoza IT jak sprzedawcy, handlowcy i managerzy mogą czerpać korzyści z tych platform? Aby odpowiedź na te pytania omówię 2 kwestie:

  • Czy PowerPlatform jest platformą typu no-code?
  • Czy PowerPlatform jest dla każdego?

There is no No-Code

No-Code, to pojęcie zgodnie z którym narzędzie nie wymaga pisania ŻADNEGO kodu. Cały proces budowania rozwiązania opiera się o korzystanie ze specjalnego kreatora w którym za pomocą metody drag-n-drop można zbudować rozwiązanie. To miało implikować, że w/w narzędzia są tak proste, że KAŻDY może z nich korzystać do budowania rozwiązań. Wystarczy, że chce – twórca aplikacji nie musi być nawet programistą. Wówczas taka osoba uruchamia którąś z wymienionych platform i ku zdumieniu okazuje się, że:

  • platformy korzystają ze specjalnego języka funkcyjnego posiadającego składnię
  • posiadają bloki warunkowe IF
  • posiadają pętle
  • wykorzystują koncepcję zmiennych oraz kolekcji

Dla tych z Was którzy pierwszy raz widzą na oczy powyższe pozycje wyjaśniam – są to uniwersalne pojęcia cechujące wszystkie języki programowania. Trafnie ujął to swego czasu jedej z moich ulubionych influencerów – Jon Levesque

PowerApps i Microsoft Flow to nie są platformy No-Code. Kropka.

Oczywiście nie chodzi mi o to, że Microsoft nie posiada platform No-Code. Ma ich całkiem sporo, a żeby nie szukać daleko wystarczy podać za przykład Microsoft Forms (ciekawe review tej platformy napisał swego czasu Tomasz Poszytek na swoim blogu). Ale z pewnością PowerApps jak i Microsoft Flow do nich nie należą.

Teraz zajmijmy się drugą, znaczniej bardziej gorąco kwestią czyli czy każdy może tworzyć roziwązania na tych platformach.

ANYONE can’t do programming

Skoro już wiemy, że PowerApps jak i Microsoft Flow nie są platformami typu No-Code, to czy nadal możemy je polecić każdemu? Nie przypadkowo w nagłówku celowo użyłem słowo “programowanie” a nie “kodowanie”. Żeby budować rozwiązania wcale nie trzeba pisać kod, aby wciąż korzystać z umiejętności programowania. Wystarczy, że buduje się rozwiązanie w oparciu o to, że jest ono:

  • reprezentacją powtarzalnego procesu (niekoniecznie biznesowego)
  • oparte o możliwości określonej platformy lub platform
  • implementuje powtarzalny ciąg zdarzeń przyczynowo-skutkowych
  • kompletne rozwiązanie niesie znamiona unikalności (czyli nie jest funkcjonalnością out-of-the-box platformy)
  • (pewnie jeszcze można by coś dodać, ale na moje potrzeby to wystarczy)

W tym ujęciu nawet platformy No-Code wymagają umiejętności programowania. Zarówno Microsoft Forms, SharePoint, MailChimp jak i WordPress itp. do budowania na nich rozwiązań potrzebują pewnego stopnia zrozumienia wiedzy (nierzadko technicznej) i poznania możliwości platform. Szczególny nacisk chciałbym położyć na “ZROZUMIEĆ”, bo to często pomijany aspekt. Należy pamiętać, że wraz ze wzrostem złożoności rozwiązania rośnie prawdopodobieństwo wystąpienia błędów. A wtedy obowiązkowa będzie umiejętnośc tzw. debugowania czyli procesu odnajdywania i naprawiania błędu. Chyba, że chce się co chwila biec do swojego działu IT z prośbą typu: “TU NIE DZIAŁA! NAPRAW!”…ale chyba nie o to chodzi w całej idei No-Code/Low-Code paltforms. Nie wspomnę o tym że czasami także przydają się znacznie bardziej wyrafinowane umiejętność jak np inżynieria wsteczna.

Żeby zobrazować jeszcze lepiej opisywaną przeze mnie kwestię spójrzmy jak na ten temat wypowiada się Bob Reselman, programista, architekt i dziennikarz z wieloletnim stażem, w jednym ze swoich artykułów:

For example, imagine using a low-code visual composer to bind data from a poorly written SQL query to a UI. All should work fine, right? That’s the promise. Everything should be peachy keen, except that the app is slow as molasses in February. Why is it so slow? DB? UI code? The network?

Most likely, the low-code software developer won’t know. He was not hired to know. He was hired to drag and drop components to create business forms, not to do data performance debugging.

TechTarget, Bob Reselman

I choć nie zgadzam się ze wszystkim o czym pisał Bob w całym artykule, to ten fragment ma w sobie trochę prawdy. Low-code software developers, to nie software developers. Ale w sumie…czy nie o to właśnie chodzi? Bo…

Tworzyć rozwiązania w oparciu o platformy Low-Code nie może każdy, ale zdecydowanie może więcej osób niż tylko programiści.

Czy zastanawiałęś się czemu tak instensywnie propaguje się idee Citizen Developers (programistów platform Low-Code) i możliwość łatwego budowania rozwiązań? Wydaje mi się, że są 2 powody takiej sytuacji.

1. Tworzenie rozwiązań IT jest drogie

O kwestii problemów na rynku programistów pisałem już w swoim artykule poświęconemu zagadnieniu “Czym są platformy Low-Code“. Ogromne braki kadrowe (dla przypomnienia szacuje się, że w 2020 na rynku europejskim będzie brakować 500.000-600.000 programistów) powodują, że programiści, jak przystało na “towar” luksusowy, mają wysoką cenę. Wdrożenie rozwiązań IT to często niezwykle drogie przedsięwzięcia (analiza wymagań, architektura, infrastruktura, licencje, godzina pracy programisty, adopcja, utrzymanie itp itd). Na domiar złego często praca programistów nie jest efektywna, bo wielokrotnie implementują oni te same fragmenty aplikacji (warstwa logowania, uprawnienia, warstwa łącza danych itd). To rodzi następujące wnioski:

  1. Programiści potrzebują odciążenia w prostszych zadaniach. Mówiąc bardziej obrazowo do wymiany koła w samochodzie nie potrzebujesz usług inżyniera rakietowego
  2. Idealnie by było, gdyby tylko raz tworzyć daną funkcjonalność. Nie wymyślajmy koła na nowo. Korzystajmy wielokrotnie z powtarzalnych części rozwiązań.

I z tą myślą zbudowane zostały platformy Low-Code. W szczególności w PowerApps i Microsoft Flow jest kładziony nacisk na:

  • maksymalne pokrycie powtarzalnych fragmentów aplikacji (warstwa logowania, uprawnienia, warstwa łącza danych itd)
  • wsparcie integracji za pomocą szerokiej gamy “connectorów”(nie tylko do platform Microsoft)
  • rozszerzalność (możliwość budowania własnych connectorów bazujących na ogólnie przyjętych w IT standardach)

2. IT zna się na IT

Gdy w 2018 roku wraz z koleżanką przez prawie rok po godzinach prowadziliśmy start-up życie dało nam cenną lekcję. Mieliśmy pomysł dotyczący rozwiązania pewnego problemu branży HR, a dokładniej doradztwa zawodowego. Wydawało nam się, że mieliśmy wszystko by z tzw. side-hustle zbudować realną wartość opakowaną w skalowalny produkt:

  • Mieliśmy pomysł jaki efekt chcemy uzyskać
  • Mieliśmy technologie: ja i koleżanka pracowaliśmy w IT, programowanie i algorytmy uczenia maszynowego nie stanowiły dla nas problemu

Chcieliśmy pozyskać dofinansowanie, ale drzwi inwestorów wciąż nie chciały nas przyjąć. Gdy w końcu przyszedł czas na refleksje zrozumieliśmy czego nam brakowało. Umiejętności techniczne i docelowy efekt to nie wszystko. Trzeba jeszcze wiedzieć JAK. W naszym przypadku zabrakło specjalizacji z zakresu doradztwa zawodowego – nie mieliśmy osoby która byłaby w stanie opracować odpowiedni test psychometryczny oraz zinterpretować jego wyniki.

Podobny problem posiada wiele firm. Mają IT, które umie wdrożyć wszystko, ale nie wie co. Mają też działy nie-IT, które wiedzą co potrzebują, ale nie wiedzą jak. Wystarczy więc połączyć jednych i drugich, prawda? Dokładnie – i wtedy nagle okazuje się, że IT jest drogie (patrz poprzedni akapit).

Screen from
Screen from


Cała koncepcja platform Low-Code w wydaniu PowerApps i Microsoft Flow ma za zadanie rozwiązać kwestię wysokich kosztów projektów IT oraz niwelować problemy wynikające z wąskiej specjalizacji.

Platformy Low-Code Microsoft zmniejszają koszty generowane przez rozwiązania IT i wspierają interdyscyplinarne środowisko pracy

Dzięki PowerApps i Microsoft Flow osoby nie-IT mające jednak zdolności techniczne (warunek konieczny!) mogą w łatwy sposób pokazać, a nawet zbudować to co potrzebują. Z drugiej strony programiści i administratorzy mogą wspierać je w trudniejszych fragmentach, pomagać w integracji a nawet rozszerzać możliwości platform (poprzez Custom Connectory).

PowerApps and Microsoft Flow developers = Low-code developers = Citizen Developers
PowerApps and Microsoft Flow developers = Low-code developers = Citizen Developers

Zdziwisz się jak wiele osób spoza IT w Twojej organizacji świetnie radzi sobie z tematami technicznymi. Wystarczy tylko im pomóc zacząć.

To wszystko w tej części. W moim następnym artykule omówię kwestie związane z bezpieczeństwem rozwiązań PowerApps i Microsoft Flow.

Stay tuned!