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. Occasionally you have to do a mass operation (e.g. update status of all items in SharePoint lists)
  4. You want to save time by cutting down the overall implementation time
  5. 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.
  6. You want to improve productivity in your Office365 environment
  7. Security and contextual data trimming is important for you
  8. 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!

PowerApps and Microsoft Flow target – part 1

In this article, you will understand the context for PowerApps and Microsoft Flow. You will learn examples of implementations and whether those platforms are safe. You will also find out what are the advantages and disadvantages of the solutions built based on them. Finally, I will present you with a simple set of rules: When to use the PowerApps and Microsoft Flow applications, and when to not.

Disclaimer: it will be honest.

This article is also available in Polish 🇵🇱

Understand PowerApps i Microsoft Flow

Two weeks ago I published an article about what the Low-Code platform is and when you may need it. In the mentioned article, apart from the title issue, I briefly outlined what the purpose of the Low-Code platforms is and what the future is waiting for. The article went to the group Microsoft 365 User Group Poland, and there a very interesting discussion was initiated by Nataniel “nExoR” Zieliński.

nice article, I understand your approach as a fanboy … but personally I think it’s a small niche (I’m talking now about flow + PA) due to the performance of solutions, gruesome debugging and quite a lack of control over the entire process, depending on the connectors, and mass of intermediate elements. imho for a long time it will be only for small, frontend solutions, support processes or hobby applications. A bit like Access or even Excel instead of a normal database. which ‘biggest’ application did you have the opportunity to see? And out of curiosity – what is your opinion on the possibility of writing such a Low-Code application in the finance or security sector? (…)
For a long time I have been wondering what is the target for flow + PA. (…) On the one hand, there are simple templates for some end-user automation, on the other hand are connectors for serious systems that can be hurt in production systems. if I imagine an end-user who tries to connect the service logic and hooks to databases, CRM systems or something … I see the problems right away. I know how much time I sometimes take to write an IFa and add to this error service that I would not accidentally hurt myself … and here is such a powerful tool open to everyone and * giving the impression * of a simple. honestly – I have a serious problem if clients should be advised to take a flow license or not, because what end-user is, everyone knows. On the other hand, the tool is too weak (ok, I have little experience, only subjective assessment) for ‘serious’ use.

Nataniel “nExoR” Zieliński

First of all – nExoR, thank you very much for the extremely interesting perspective. Seriously. If the technologies were built by enthusiasts themselves, such as me, we might have ended up surrounded by insecure technologies. Only different views give the “upper light”. It allows everyone to get a full picture of the technology / solution / name it as you like. And in this context, your comment was like a bucket of cold water – as enthusiasts we haven’t had enough clear and honest communication.

PowerApps and Flow explained

A few issues have been raised, which I have grouped and I’m going to discuss as follows:

  • Examples of PowerApps and Microsoft Flow implementations
  • Who can build solutions in PowerApps and Microsoft Flow
  • Security in PowerApps and Microsoft Flow
  • When to use and when to use PowerApps and Microsoft Flow

Examples of implementations

As I mentioned in my previous post, the Low-Code platforms from the Microsoft stable bring measurable benefits to companies:

1. 70% less application development cost and effort
2. 362% return on investment over 3-year term
3. <3 months payback

Data from “The Total Economic Impact of PowerApps and Microsoft Flow” published by Forrester Consulting in June 2018(source)

In fact, there is no citation of actual implementations. Something that appeals to the imagination and shows that “actually you can”. Will PowerApps and Microsoft Flow prove themselves in solutions for really large clients? Are they suitable for solutions with greater responsibility than the “application for scanning business cards“? Let’s look at three examples.

Story logo

The first example is Virgin Atlantic. VA is an aviation company with over 10,000 employees. Manuela Pichler, Business Systems Development Manager and Microsoft MVP have already implemented several PowerApps solutions in VA. One of them is an application supporting engineers during the security audit of machines (more about the solution). The target group is modest and affects about 100 people, but it’s perfect for my needs (VA also has applications used by the entire organization).

Story image 4
Story logo

Another example is the AutoGlass company dealing with the repair and replacement of car windows. Thanks to Martin Lee, the company currently has over 40 applications implemented in production (other sources already provide more than 50) and are used by over 3,000 people! (read more about the solution)

Story image 3

One of the largest banks in the financial sector has built an application targeted at over several thousand sellers and managers responsible for customer relations. The application was to verify the actions taken by the user in terms of the legislative law prevailing in the area. The app currently operates in more than 10 countries.

REAL Support for the business

As you can see in the above examples, we have 3 different companies operating in 3h different industries and in each of them the use of PowerApps is different:

  • What distinguished VA was undoubtedly the fact that PowerApps were used in areas related to security or a critical factor in the aviation industry.
  • In AutoGlass, it was a scale: 40 applications and over 3000 users, an absolutely amazing result.
  • The last of the examples was characterized by a specific industry which is the banking sector (in this place, you must forgive me that all is shrouded in secrecy, but I’m sure Microsoft will soon send official information on this subject. I do not want to do this by myself)

The above examples prove that, however, PowerApps and Microsoft Flow can really support business. The following thing should be noted here: PowerApps and Flow are not solutions in themselves. What does it mean? What are they?

1. Integration

The purpose of PowerApps in the above examples was mainly to collect data from users and send them to another site (or database). For this purpose, standards such as HTTP protocol, REST API and data format in JSON are used. They are supported by each newly created SaaS service (if it allows integration). And that’s what it’s about building solutions with PowerApps and Microsoft Flow – for integration based on generally accepted and trusted standards! PA and MS Flow are not used to replace specialized applications f.e.: Azure, Microsoft Teams, LinkedIn, WordPress, Magento, Mailchimp, Clickfunnels, Leadpages, Jira, Github to name a few. In the same way you shouldn’t try to use PA and MS FLow for integration with protocols like SIP or POSNET.

In building PowerApps and Microsoft Flow solutions, it’s about integration different services based on generally accepted standards

2. Scale over complexity

The applications themselves did not carry out operations with high risk of error and with high computation cost. They were displaying or collecting data and sending it on – little can go wrong here. These are universal platforms for communication with the user and automation of business processes.

To use a simple analogy, imagine that a company is a human. The brains of such a “man” are his employees. Then PowerApps would be his senses: eyes, hearing and voice. These senses receive signals or allow them to be verbalised. MS Flow, in turn, would be a nervous system: it sends signals between the decision center (brain) and specialized units (muscles, organs, receptors). Human eyes do not interpret what they see, and the mouth is not to plan what to say. The brain deals with all this. He makes decisions. Following this analogy, PowerApps in the company is not used to process the collected data – its only task is to collect this data or display it.

But let’s leave the analogies on the side and let’s get back to the main topic – what is PowerApps for? PowerApps works well in applications, where it’s not about complexity as such but about saving time on frequent need. Build 10 forms, each with other fields, and the scrolling list of results can be not only in PowerApps, but also using C #, JavaScript or PowerShell. But thanks to the use of PowerApps, you save time needed to build something very similar once again. This feature does not diminish the efficiency of the platform – I can bet that 80% of processes in all companies are very similar simple cases only differing in a few names, field types and application design. In fact, Facebook, Twitter or LinkedIn could be built on the same platform. What distinguishes them is mainly destiny (enforced by rules such as short messages on Twitter), not the engine that runs them. Of course Facebook is far more advanced than any PowerPlatform solution but I’m sure you know what I mean.

The effectiveness of PowerApps and Microsoft Flow results from time savings on creating solutions


Low-Code platforms, in particular PowerApps and Microsoft Flow, are used to:

  1. Integration
  2. Time savings

And that’s how much in the first part. And in the next part you will learn who can and should build solutions in PowerApps and Microsoft Flow. Is anyone or maybe just programmers? Is the use of Low-Code platforms free of charge or is it a compromise?


(Featured Image taken from

Target dla PowerApps i Microsoft Flow cz.1

W tym artykule zrozumiesz kontekst dla PowerApps i Microsoft Flow. Poznasz przykłady wdrożeń oraz czy są one bezpieczne. Dowiesz się także jakie są wady i zalety budowanych w oparciu o nie rozwiązań. A na koniec przedstawię Ci prosty zbiór zasad: Kiedy należy używać aplikacji PowerApps i Microsoft Flow, a kiedy nie.

Disclaimer: będzie szczerze.

Ten artykuł jest także dostępny w języku angielskim 🇬🇧

Zrozumieć PowerApps i Microsoft Flow

2 tygodnie temu opublikowałem artykuł o tym czym są platformy Low-Code i kiedy możesz ich potrzebować. W wymienionym artykule, poza kwestią tytułową, przybliżyłem krótko jaki cel przyświeca platformom Low-Code i jaka przyszłość je czeka. Artykuł trafił na grupę Microsoft 365 User Group Poland, a tam bardzo ciekawą dyskusję zapoczątkował Nataniel “nExoR” Zieliński.

art fajny, i rozumiem Twoje podejście jako fanboya… ale osobiście uważam, że to niewielka nisza (mówię teraz o flow+PA) ze względu na wydajność rozwiązań, makabrycznie trudne debugowanie i spory brak kontroli nad całym procesem, zależnym od connectorów, i masy elementów pośrednich. imho przez jeszcze długi czas to będzie tylko do małych, frontendowych rozwiązań, procesów wspierających lub hobbistycznych zastosowań. trochę tak jak Access czy wręcz Excel zamiast normalnej bazy danych. jaką ‘największą’ aplikację miałeś okazję widzieć? i tak z ciekawości – jaka jest Twoja opinia na możliwość napisania takiej aplikacji Low-Code w sektorze finansów czy bezpieczeństwa? (…)

Od dłuższego czasu zastanawiam się jaki jest target dla flow+PA. (…) Z jednej strony są proste szablony do jakiś end-userowych automatyzacji, z drugiej konektory do poważnych systemów, którymi można zrobić krzywdę w systemach produkcyjnych. jeśli wyobrażę sobie end-usera, który próbuje np. podpiąć logikę obsługi i podpina się do baz danych, systemów CRM czy coś… od razu widzę problemy. wiem ile czasu mi czasem zabiera napisania jakiegoś IFa i dorobienie do tego obsługi błędów żebym sam sobie przypadkiem krzywdy nie zrobił… a tu tak potężne narzędzie otwarte dla każdego i *sprawiające wrażenie* prostego. szczerze – mam poważny problem czy powinno się klientom doradzać zabranie licencji na flow, czy nie, bo jaki end-user jest, każdy wie. z drugiej strony narzędzie jest zbyt słabe (ok! mam małe doświadczenie! tylko subiektywana ocena) do ‘poważnego’ zastosowania.

Nataniel “nExoR” Zieliński

Przede wszystkim – nExoR, bardzo Ci dziękuję za niezwykle ciekawą perspektywę. Serio. Gdyby technologie budowali sami entuzjaści, tacy jak ja, to skończylibyśmy otoczeni nie-bezpiecznymi technologiami. Tylko odmienne poglądy dają “górne światło”. To pozwala wszystkim uzyskać pełny obraz technologii / rozwiązania / nazwij to jak chcesz. I w tym kontekście Twój komentarz był jak kubeł zimnej wody. Zabrakło nam, entuzjastom, odpowiednio klarownej i szczerej komunikacji.

PowerApps and Flow explained

Poruszonych zostało kilka spraw, które pogrupowałem i omówię następująco:

  • Przykłady wdrożeń PowerApps i Microsoft Flow
  • Kto może budować rozwiązania w PowerApps i Microsoft Flow
  • Bezpieczeństwo w PowerApps i Microsoft Flow
  • Kiedy używać, a kiedy nie używać PowerApps i Microsoft Flow

Przykłady wdrożeń

Jak przytaczałem w poprzednim moim wpisie platformy Low-Code ze stajni Microsoft przynoszą wymierne korzyści firmom:

1. 70% less application development cost and effort
2. 362% return on investment over 3-year term
3. <3 months payback

Dane z “The Total Economic Impact of PowerApps and Microsoft Flow” opublikowanych przez Forrester Consulting w Czerwcu 2018 (source)

Faktycznie jednak brakuje przytoczenia faktycznych wdrożeń. Czegoś co przemówi do wyobraźni i pokaże, że “jednak można”. Czy PowerApps i Microsoft Flow sprawdzą się w rozwiązaniach dla naprawdę dużych klientów? Czy nadają się do rozwiązań obarczonych większą odpowiedzialnością niż “aplikacja do skanowania wizytówek“? Spójrzmy na 3 przykłady.

Story logo

Pierwszym przykładem jest Virgin Atlantic. VA to firma lotnicza zatrudniająca ponad 10.000 pracowników. Manuela Pichler, Business Systems Development Manager i Microsoft MVP wdrożyła w VA już kilka rozwiązań PowerApps. Jednym z nich jest aplikacja wspierająca inżynierów w trakcie dokonywania audytu bezpieczeństwa maszyn (więcej o rozwiązaniu). Grupa docelowa jest skromna i dotyczy około 100 osób, ale na moje potrzeby jest idealna (VA posiada także aplikacje wykorzystywane przez całą organizację).

Story image 4
Story logo

Innym przykładem jest firm AutoGlass zajmująca się naprawą i wymianą szyb samochodowych. Dzięki Martinowi Lee firma posiada obecnie ponad 40ci aplikacji wdrożonych produkcyjnie (inne źródła podają już ponad 50) i są wykorzystywane przez ponad 3000 osób! (przeczytaj więcej o rozwiązaniu)

Story image 3

Jeden z największych banków sektora finansowego zbudował aplikację kierowaną do ponad kilku tysięcy sprzedawców i manadzerów odpowiedzialnych za relacje z klientami. Aplikacja miała za zadanie weryfikować akcje podejmowane przez użytkownika pod kątem prawa legislacyjnego panującym na danym obszarze. Aplikacja działa obecnie w ponad 10ciu krajach.


Jak widać na powyższych przykładach mamy 3 różne firmy, działające w 3ech różnych branżach i w każdej z nich wykorzystanie PowerApps cechuje co innego:

  • Wyróżnikiem VA było niewątpliwie to, że PowerApps wykorzystywane były w obszarach związanym z bezpieczeństwem czyli krytycznym czynnikiem branży lotniczej.
  • W AutoGlass była to skala: 40 aplikacji i ponad 3000 użytkowników, to absolutnie niesamowity wynik.
  • Ostatni z przykładów cechował się specyficzną branżą jaką jest sektor bankowy (w tym miejscu wybaczcie, że wszystko owiane tajemnicą, ale z pewnością niedługo Microsoft wystosuje oficjalną informację na ten temat. Ja tego nie chcę robić)

Powyższe przykłady dowodzą, że jednak PowerApps i Microsoft Flow mogą realnie wspierać biznes. Należy przy tym zauważyć następującą rzecz: PowerApps i Flow nie stanowią rozwiązań same w sobie. Co to znaczy? To czym są?

1. Integracja

Celem PowerApps w powyższych przykładach chodziło głównie o zebranie danych od użytkowników i przesłanie ich do innego serwisu (lub bazy danych). W tym celu wykorzystywane są takie standardy jak protokół HTTP, REST API i format danych w JSON. Są one wspierane przez każdą nowo powstałą usługę SaaS (o ile pozwala ona na integrację). I o to chodzi w budowaniu rozwiązań o PowerApps i Microsoft Flow – o integrację w oparciu o ogólnie przyjęte i zaufane standardy! PA i MSFlow nie służą budowania rozwiązań po specjalistyczne zastosowania, bo te już powstały: usługi Azure, Microsoft Teams, LinkedIn, WordPress, Magento, Mailchimp, Clickfunnels, Leadpages, Jira, Github by wymienić tylko kilka z nich. Tak samo nie służą do integracji po specjalistycznych protokołach jak SIP czy POSNET.

W budowaniu rozwiązań PowerApps i Microsoft Flow chodzi o integrację różnych serwisów w oparciu o ogólnie przyjęte standardy

2. Skala, a nie złożoność

Aplikacje same w sobie nie realizowały operacji obłożonych wysokim ryzykiem błędu i kosztownych obliczeniowo. Wyświetlały bądź zbierały dane i przesyłały je dalej – mało tu może się zepsuć. To są uniwersalne platformy odpowiednio do komunikacji z użytkownikiem oraz automatyzacji procesów biznesowych.

Żeby posłużyć się prostą analogią wyobraźmy sobie, że firma to człowiek. Mózgiem takiego “człowieka” są jego pracownicy. Wówczas PowerApps byłby jego zmysłami: oczami, słuchem i głosem. Zmysły te odbierają sygnały lub pozwalał na ich werbalizację. MS Flow z kolei byłby układem nerwowym: przesyła sygnały między ośrodkiem decyzyjnym (mózg) a wyspecjalizowanymi jednostkami (mięśnie, narządy, receptory). U człowieka oczy nie służą do interpretacji tego co widzą, a usta do sformułowania tego co chcą powiedzieć. Tym wszystkim zajmuje się mózg. On podejmuje decyzje. Idąc tą analogią PowerApps w firmie nie służy do procesowania zebranych danych – jego jedynym zadaniem jest zebranie tych danych bądź ich wyświetlenie.

Ale zostawmy analogie na boku i wróćmy do konkretów – to do czego służy PowerApps? PowerApps sprawdza się w prostych zastosowaniach, gdzie nie chodzi o złożoność jako taką tylko o oszczędność czasu na prostych, ale częstych potrzebach. Zbudować 10 formularzy, każdy z innymi polami, i przewijaną listą wyników można nie tylko w PowerApps, ale także wykorzystując C#, JavaScript czy PowerShell. Ale dzięki zastosowaniu PowerApps zyskuje się oszczędność czasu potrzebnego na zbudowanie po raz kolejny czegoś bardzo podobnego. Ta cecha wcale nie umniejsza skuteczności platformy – stawiam dolary przeciw orzechom, że 80% procesów w każdej firmie, to te same, proste “case’y” tylko różniące się paroma nazwami, typami pól i designem aplikacji. Tak na dobrą sprawę Facebook, Twitter czy LinkedIn możnaby zbudować w oparciu o tą samą platformę, bo to co je wyróżnia to głównie przeznaczenie (wymuszone poprzez reguły jak np krótkie wiadomości na Twitterze), a nie funkcjonalności. Naturalnie, skala działania tych platform jest znacznie większa niż w przypadku PowerApps czy Flow, ale to temat, który omówię w części poświęconej budowaniu rozwiązań.

Skuteczność PowerApps i Microsoft Flow wynika z oszczędności czasu na tworzeniu podobnych rozwiązań


Platformy Low-Code, w szczególności PowerApps i Microsoft Flow służą:

  1. Integracji
  2. Oszczędności czasu

I to tyle w części pierwszej. A już w kolejnej części dowiesz się kto może i powinien budować rozwiązania w PowerApps i Microsoft Flow. Czy każdy czy może tylko programiści? Czy korzystanie z platform Low-Code odbywa się bezkosztowo czy jednak jest kompromisem?

Przejdź do części 2giej

Overview of SharePoint Virtual Summit 2019

In this article I’ll put short glimpse of what has been announced on SharePoint Virtual Summit 2019. Be aware that some of following features may be still in preview but are going to appear later this year. I skipped features that has been announced on Microsoft Build 2019

flow SharePoint Document Libraries

  • Build custom forms using PowerApps
  • Microsoft Teams will gets enriched metadata experience
  • Bulk Actions

    This feature was requested for a long time. And now here it is: you can select multiple items/document and take an action for all of them: update properties, download, delete, approve, move etc.

  • New Flow actions

    There are scenarios in which you need to check-in/check-out documents, get version information, grant access or create folders as a part of larger business process in Flow. Until now you could do that only by calling SharePoint HTTP REST API. But from now on you can do all of above simply by using Flow actions!

  • File request feature

    This is a bomb! You will be able to request files from other users directly from the place where you store your files! The recipients will get email with link. Once they click on it they will see consistent UI with built-in files upload.

  • Organization document templates

    governance becomes even easier!

flow Collaboration

  • Organization Home site

    It’s a communication site with some extra superpowers. It searches for data tenant wide, mark site news as organizational news, enables special SP mobile app. For me it completes perfectly org-wide Teams team. Just add tenant Home site as a tab in an Ord-wide Teams team

  • New page designs
  • New webparts – i.e. Yammer!
  • News links
  • Audience targeting
  • Sync Microsoft Teams files to you PC or Mac
  • Teams apps in SharePoint sites
  • Enhanced SharePoint list experience embedded in Teams
  • Enhanced co-authoring acroos mobile, web and desktop versions of Word, PowerPoint and Excel (only for Office 365 and files in the cloud)

flow Governance

  • Rename your SharePoint site (including its URL)
  • Replace the root site within a tenant

    you’ll be able to build a new org site on the side and once completed it swap it with a root site…it couldn’t be simpler.

  • Create SharePoint list using excel file with an option to configure columns types!
  • Share & Forget with external access expiration
  • File restore for SharePoint just as it is already for OneDrive
  • Sensitivity labels

    the mechanism known from Azure Information Protection is now being supported by SharePoint and OneDrive (and it is called Microsoft Information Protection)

  • Decide where your data related to SharePoint and O365 groups will be stored using multi-geo capabilities

flow Search

  • Customizable Search to rule them all!

    The same search experience will be shared across any Microsoft platform. Top, middle, search. Oh and there will be available to add custom verticals, custom refiners and custom display templates! What is more you will be able to search for conversations from Yammer and Microsoft Teams in any search endpoint!

  • Search in Office

    Discover your network of apps, files, folders, people, organization charts, SharePoint sites, site pages, lists and list items

  • Search in SharePoint

    Catch up on news and announcements. Find the sites that are relevant to you without scrolling through endless bookmarks. Pick up on that shared document you were working on

  • Search in OneDrive

    Discover relevant information to help you get work done where you’re working through intelligent results and sophisticated refinement

  • Search in Windows

    Search right from your Windows desktop. This way you can search not only inside your local files but also in Office365, person in organization with smart suggestions based on the people you work with the most

  • Administer your Microsoft Search

    Control organization search using provided powerful admin center and manage all of Microsoft Search endpoints!

flow Misc

As you can see SharePoint is not stopping in getting new capabilities. But what may not see and I have to tell you – many of above changes came from UserVoice. UserVoice is a forum where everyone can submit a bug, an idea or new feature request and Microsoft will implement it if only the post gets enough amount of community support (represented by likes). Changes presented on SharePoint Virtual Summit 2019 are the best prove that Microsoft is listening to its users!

What are Low-Code development platforms?

Rapid Application Development, Robotic Process Automation, Business Process Management Systems – these are all examples of Low-Code platforms. The market has already appeared in the 90s, but their popularity has grown strongly in the last few years. In this article, you’ll learn what the Low-Code platforms are, when you need them, and what future is waiting for them on the example of Microsoft platforms like PowerApps and Microsoft Flow.

Thorough transformation – Understanding ” The Why”

Before we get to know what the Low-Code platforms are, we first need to understand the reasons why we started to work on their development at all. For this purpose, let’s get back to the 90s. At the time, it was the era of computerization that got under way for good. E-commerce, e-government, e-society, e-everything has dominated the world as personal as well as business. It became obvious that there is no other way than to give IT a high priority in computerization of work and activities. Data Management, Information Management and Knowledge Management were gradually digitized, and business processes were transformed along with them. All this so that everyone can use private resources, corporate resources, and communicate with others from anywhere in the world and at any time of the day or night.


Where to get new programmers from?

Such a change naturally required the involvement of a huge number of IT specialists and engineers. IT specializations have become extremely popular and well rewarded. Everyone did what they could to increase the number of programmers:

  • Educate new developers – IT courses in higher education were gaining in popularity. Currently, in Poland, as reported by the Ministry of Science and Higher Education, 14% of all recruitment applications for 2017/2018 concerned information technology, the second was management with a result of 7% of all applications!
  • Employees of other specializations were attracted – all-year programming schools, bootcamps and IT courses are doing everything to further reduce the training time of the “complete junior”. Also the employers help in this process eg Aviva, the insurance company, in 2018 organized a 6-month course addressed to all its employees, giving them a chance to get software developer qualifications
  • Experienced developers are tempt – hundreds of recruitment companies flood with offers anyone who on linkedIn has anything to do with IT. They’re offering many benefits besides very good earnings
  • Promote awareness 😉

Despite almost 30 years, the situation has not changed. Reports estimated that in 2020, 500,000-600,000 programmers will be missing out on the European market (source, source)! Only in Poland, my homeland, there is already missing about 50,000 of developers. Demand around the world is huge and Europe Union estimates that it will last until 2030 (source). But it is not surprising. More and more industries involve IT solutions (HR, marketing, art) and the same is for areas of activity (forecasting, chatbots).

Image result for meme when a developer uploads cv

Low-code platforms for the rescue

If the demand is greater than the supply, there are two strategies to keep the balance. Increasing the supply (that is increasing “the production” of developers) has been described above. However, method no. 2 consists in reducing demand for programmers. Is it possible? It turns out that yes and no need to blow up in the air half of the companies ;). It is enough to build a platform for effective, fast and flexible building of applications and processes. The platform itself has to fulfill 5 assumptions:

  1. Ease of use – everyone, not only highly qualified engineers, should be able to use it
  2. Supporting standards – basing the platform’s operation on globally accepted and adopted standards
  3. Integration – the platform should enable integration with any systems. Achieving point 2 is very helpful in this 😉
  4. Accessibility – building solutions and using them should be independent of a user OS (Windows, Linux, macOS)
  5. Extensibility – a platform that can not be easily expanded has little chance of being longer on the market

And that’s what the so-called Low-code development platform [LCDP] – a visual approach to application development. Microsoft has at least 3 such platforms. In the further part of the article I will focus on two of them: PowerApps and Microsoft Flow. They co-exist in a very close relationship not only among themselves, but also with more than 230 other platforms (Microsoft and non-Microsoft).

Examples of Low Code platforms by the Microsoft. Microsoft Flow and Azure Logic Apps are very similar, although they differ in their purpose: Microsoft Flow is mainly used for business processes. Azure Logic Apps is responsible for the integration of data between different systems. I will deal with them in another article.

At LCDP, we build solutions using a drag-and-drop or point-and-click mechanism from the graphical interface. Thanks to this, building, modifying and maintaining it is extremely simple and saves a lot of time, and the effects are visible immediately.

Microsoft Flow example
Microsoft PowerApps example

Using LCDP is a bit like building with LEGO bricks. When you play with LEGO, you use manufactured blocks that are limited in size, color and number of pins. However, these dependencies do not limit the construction of complex and functional solutions.

With the use of LCDP you can build professional solutions supporting the company and what is important, the construction process itself is fast and agile, saving time and money.

Check out the application to scan business cards, which development took me 8 hours instead of 5 days!

This approach must give effects:

1. 70% less application development cost and effort
2. 362% return on investment over 3-year term
3. <3 months payback

Data from “The Total Economic Impact of PowerApps and Microsoft Flow” published by Forrester Consulting in June 2018 (source)

Low-Code, High-Possibilities

The possibilities of the platform itself are determined not only by the multitude of available “blocks” from which we can build a solution, but also the openness of the platform for integration. The PowerApps and Microsoft Flow platforms share a set of available connectors that are over 230!

One of such connectors are those related to HTTP query support which actually is synonymous with the ability to integrate the platform with any SaaS solution having a REST API (so the overwhelming majority).

Left: Http trigger which launches Flow when it receives an HTTP query from any source
Right: HTTP action that performs an HTTP query to any URL
(If you’re a developer, know that creating your own SaaS service could not be easier!)

But it is not everything. Microsoft Flow, like PowerApps or LogicApps, allows you to build your own “plug-in” (so-called custom connector). Developers can connect such Custom Connector, for example, with Azure Function, which can perform ANY operations using the C # code, Javascript, Python, etc. A good example is the application for document translation, which consists in:

  • Microsoft Flow sends a document to Azure Function
  • Azure Function decompose the document to separate paragraphs…
  • …and translate each paragraph independently.
  • Then the function merges together translated paragraphs…
  • … and sent back to Microsoft Flow

Thanks to this approach, the document is translated in full, maintaining the formatting and layout of information on the page.

Use the resource according to your the needs

The scenario presented above has one more extraordinary advantage. This approach is definitely beneficial for more than 1 page of the software development process:

  • LCDP developer – Can model the overall flow of the entire process. Determines from which platform the user interacts with the application (eg PowerApps), where the data is stored (eg SharePoint Online) and how the general flow of information related to the translation of the document is going (eg Microsoft Flow). However, he does not know (and does not need to know) exactly how the document is translated
  • Software developer – With the help of a regular code (eg C #) he creates an independent service that gets the document in a language at the input and translates it to any other, returning the translated document at the output. For this purpose, he can use services like Azure Function and Azure Cognitive Services. He does not know (and does not need to know) what is happening with the document before and after the translation process.
  • Business owner – he uses his resources according to their purpose, thanks to which fewer mistakes are made and more value is delivered in a shorter time. People who understand business well and have broad product knowledge can focus on modeling the overall framework of the solution. In turn, programmers can focus on this part of the solution that makes the best use of their specialization.

This is very important: using LCDP you do not give up the possibility of using solutions using a regular code.

LCDP and the vision of tomorrow

The last question is: is it worth letting LCDP platforms into your organization? There are some questions related to that:

  1. The LCDP concept is not new and it was already known in the 1990s. Why, then, have they become popular yet? Maybe it’s just a temporary hype?
  2. Will LCDP platforms be replaced soon by other platforms?
  3. When choosing a single supplier, do not we enter a one-way street?

So let me answer these questions briefly:

  1. That’s true, LCDPs have appeared before, however in my personal opinion their low popularity was associated with the lack of appropriate adaptation of programming standards (REST / GRAPH API, JSON, OAUTH). Such lack of adaptation made it impossible to build a wide range of integrated platforms. At present, the IT environment has clarified such universal standards, and newly-built solutions follow the established good practices. There is one more important reason, more precisely 3 of them:
    • Growth – it is estimated that the value of the low-code market will increase by over 21 million over the next 5 years
    • Diversification – the demand for IT solutions is growing, and at the same time software developers need a relief
    • Integration – solutions need to grow quickly while maintaining integration to be able to use the potential behind AI, robotics and machine learning
  2. In the whole history of IT solutions, a lot of products appeared and some time after sold, changed or killed. Therefore, I personally think that it is best to relate to solutions of large companies whose future is based on the trust of their clients. This trust depends directly on the possessed solutions, as well as their stability, predictability, reliability and security of entrusted data. “Trust is the Currency of the Future” as the title of an excellent Polish book by Michał Szafrański.
  3. Yes and no. On the one hand, actually choosing ANY supplier from the exit procedure, it may be even necessary to rewrite the solution in case of willingness to change. On the other hand, the construction of the graphical interface should not take much time, and in the case of RPA systems, you can implement critical parts of solutions as independent SaaS solutions (eg using Azure Functions or azure hosted web applications)


For me personally, Low-Code development platforms are a must for any company that wants to grow dynamically. They carry a huge revolution that once brought a window interface in operating systems. On the one hand, it’s just a change of interaction with the processor “on the other side.” But on the other hand, it is opening up to completely new possibilities.

If you would like to learn more about these platforms contact me! I will teach you how to use them, and if you want I can design a solution or simply build it for you!

Czym są platformy Low-Code?

Rapid Application Development, Robotic Process Automation, Business Process Management Systems – to wszystko przykłady platform Low-Code. Na rynku pojawiły się już w latach 90tych, ale ich popularność wzrosła silnie w ciągu ostatnich paru lat. W tym artykule dowiesz się czym są platformy Low-Code, kiedy możesz ich potrzebować oraz jaka przyszłość je czeka na przykładzie platform Microsoft jak PowerApps oraz Microsoft Flow.

Gruntowna transformacja – Zrozumieć “Dlaczego”

Zanim poznamy czym są platformy Low-Code najpierw musimy zrozumieć powody dla których w ogóle zaczęto pracować nad ich rozwojem. W tym celu cofnijmy się do lat 90tych. Wtedy to właściwie era informatyzacji rozkręciła się na dobre. E-commerce, e-government, e-society, e-wszystko zdominowało świat tak osobisty jak i biznesowy. Stało się oczywiste, że nie ma innego wyjścia jak w swojej strategii nadać wysoki priorytet informatyzacji pracy i działań. Zarządzanie danymi (Data Management), informacją (Information Management) czy wiedzą (Knowledge Management) podlegały stopniowej digitalizacji, a wraz z nimi ulegały przemianom procesy biznesowe. Wszystko po to by każdy mógł korzystać z zasobów prywatnych, zasobów firmowych, a także komunikować się z innymi z dowolnego miejsca na świecie i o każdej porze dnia i nocy.


Skąd wziąć nowych programistów?

Taka przemiana naturalnie wymagała zaangażowania ogromnej rzeszy specjalistów IT i inżynierów. Specjalizacje IT stały się niezwykle popularne i dobrze wynagradzane. Wszyscy robili co mogli aby zwiększyć liczbę programistów:

  • Kształocono nowych – kierunki informatyczne studiów wyższych zyskiwały na popularności. Obecnie w Polsce, jak podaje raport Ministerstwa Nauki i Szkolnictwa Wyższego, wśród wszystkich zgłoszeń rekrutacyjnych na rok 2017/2018 14% dotyczyło kierunków informatycznych, drugim było zarządzanie z wynikiem 7% wszystkich zgłoszeń!
  • Przyciągano pracowników innych specjalizacji – całoroczne szkoły programowania, bootcampy i kursy informatyczne robią wszystko by jeszcze bardziej skrócić czas kształcenia “kompletnego juniora”. Pomagają w tym także sami pracodawcy np Aviva, firma ubezpieczeniowa w 2018 roku zorganizowała 6 miesięczny kurs
    skierowany do wszystkich pracowników, dający szanse zdobycia kwalifikacji programisty
  • Zatrzymywano doświadczonych – powstałe jak grzyby po deszczu firmy rekruterskie zalewają ofertami stanowisk każdego kto na linkedIn ma cokolwiek wspólnego z IT, oferując poza bardzo dobrymi zarobkami także inne benefity.
  • Zwiększano świadomość 😉

Pomimo upływu prawie 30stu lat, sytuacja nie uległa zmianie. Szacuje się, że w 2020 na rynku europejskim będzie brakować 500.000-600.000 programistów (source, source)! W samej tylko Polsce, mojej ojczyźnie, już teraz brakuje ok. 50.000 programistów. Zapotrzebowanie na całym świecie jest ogromne i szacuje się, że utrzyma się do 2030 roku (source). Ale to nic dziwnego jeśli rozwiązania IT angażowane są w coraz to wiecej branz (HR, marketing, sztuka) i obszarów działań (prognozowanie, chatboty).

Image result for meme when a developer uploads cv

Platformy low-code na ratunek

W przypadku kiedy popyt jest większy niż podaż, są 2 strategie mające na celu zachowanie równowagi. Zwiększenie podaży, czyli większa “produkcja” developerów, zostało opisane powyżej. Natomiast sposób nr 2. polega na zmniejszeniu popytu, czyli zmniejszenie zapotrzebowania na programistów. Czy to możliwe? Okazuje się, że tak i wcale nie trzeba wysadzać w powietrze połowy firm ;). Wystarczy zbudować paltformę do skutecznego, szybkiego i elastycznego budowania aplikacji i procesów. Sama platforma musi spełniać 5 założeń:

  1. Łatwość obsługi – każdy, nie tylko wysoko wykwalifikowani inżynierowie, powinien być w stanie budować rozwiązania
  2. Wsparcie standardów – oparcie działania platformy na globalnie przyjętych i wspieranych standardach
  3. Integracja – platforma powinna umożliwiać integrację z dowolnymi systemami. Osiągnięcie punktu 2 bardzo w tym pomaga 😉
  4. Dostępność – budowanie rozwiązań jak i korzystanie z nich powinno być niezależne od wykorzystywanego systemu (Windows, Linux, macOS)
  5. Rozszerzalność – platforma której nie da się w prosty sposób rozszerzać ma nikłe szanse przyjęcia się na dłużej na rynku

I tym właśnie są tzw. Low-code development platform [LCDP] czyli wizualne podejście do tworzenia aplikacji. Microsoft posiada przynajmniej 3 takie platformy. W dalszej części artykułu skupię się 2-óch z nich: PowerApps oraz Microsoft Flow. Koegzystują one w bardzo bliskiej relacji nie tylko między sobą, ale także z ponad 230toma innymi platformami (Microsoftu jak i nie-Microsoftu).

Przykłady platform Low Code w wydaniu Microsoft. Microsoft Flow i Azure Logic Apps są bardzo podobne choć różnią się przeznaczeniem: Microsoft Flow służy głównie do procesów biznesowych natomaist Azure Lopic Apps odpowiada za integrację danych pomiędzy różnymi systemami. Zajmę się nimi w innym artykule.

W LCDP budujemy rozwiązania wykorzystując mechanizm drag-and-drop lub point-and-click z poziomu interfejsu graficznego. Dzięki temu samo budowanie, modyfikowanie i utrzymywanie jest niezwykle proste i zaoszczędza mnóstwo czasu, a efekty są widoczne natychmiast.

Przykład Microsoft Flow
Przykład Microsoft PowerApps

Korzystanie z LCDP przypomina trochę budowanie z klocków LEGO. W zabawie z LEGO używasz wyprodukowanych klocków, które są ograniczone rozmiarem, kolorem, liczbą pinów. Jednak te zależności wcale nie ograniczają w budowaniu skomplikowanych i funkcjonalnych rozwiązań.

Z wykorzystaniem LCDP można zbudować profesjonalne rozwiązania wspierające firmę i co ważne sam proces budowy jest szybki i zwinny oszczędzając czasu i pieniędzy.

Zobacz aplikację do skanowania wizytówek, której stworzenie zajęło mi 8 godzin zamiast 5 dni!

Takie podejście musi dawać efekty:

1. 70% less application development cost and effort
2. 362% return on investment over 3-year term
3. <3 months payback

Dane z “The Total Economic Impact of PowerApps and Microsoft Flow” opublikowanych przez Forrester Consulting w Czerwcu 2018 (source)

Low-Code, High-Possibilities

Za możliwości samej platformy decyduje nie tylko wielorakość dostępnych “klocków” z których możemy budować rozwiązanie, ale też otwartość platformy na integracje. Platformy PowerApps i Microsoft Flow współdzielą zestaw dostępnych connectorów których jest ponad 230!

Jednym z takich connectorów są te związane z obsługą zapytań HTTP co właściwie jest równoznaczne z możliwością integracji platformy z każdym rozwiązaniem SaaS posiadającym REST API (czyli przeważająca większość).

Po lewej: Http trigger który uruchamia Flow kiedy otrzyma zapytanie HTTP z dowolnego źródła
Po prawej: HTTP action która wykonuje zapytanie HTTP na dowolny adres URL
(Jeśli jesteś developerem, to wiedz, że stworzenie własnej usługi SaaS serveless nie mogło być prostsze!)

Ale to nie wszystko. Microsoft Flow, podobnie jak PowerApps czy LogicApps, umożliwiają zbudowanie WŁASNEGO “klocka” (tzw. custom connector). Taki Custom Connector może być połączony np: z Azure Function, które może zrealizować DOWOLNE operacje z wykorzystaniem kodu C#, Javascript, Python itp. Dobrym przykładem jest aplikacja do tłumaczenia dokumentów, która polega na tym, że:

  • Microsoft Flow wysyła do Azure Function dokument
  • Dokument jest dekomponowany przez Azure Function do pojedynczych paragrafów
  • Każdy paragraf jest niezależnie tłumaczony
  • Przetłumaczone paragrafy są sklejane w całość…
  • …i wysyłane z powrotem do Microsoft Flow

Dzięki takiemu podejściu dokument jest tłumaczony w całości z zachowaniem formatowania i układu informacji na stronie.

Wykorzystuj zasoby adekwatnie do potrzeb

Zaprezentowany powyżej scenariusz ma jeszcze jedną niezwykłą zaletę. Takie podejście jest zdecydowanie korzystne dla więcej niż 1 strony procesu wytwórczego oprogramowania:

  • LCDP developer – Może zamodelować ogólny przepływ całego procesu. Ustala z poziomu jakiej platformy użytkownik wchodzi w interakcję z aplikacją (np PowerApps), gdzie są przechowywane dane (np SharePoint Online) oraz jak przebiega ogólny przepływ informacji zwiazany z tłumaczeniem dokumentu (np Microsoft Flow). Natomiast nie wie, i nie musi wiedzieć, w jaki dokładnie sposób dokument jest tłumaczony.
  • Software developer – Z pomocą regularnego kodu (np C#) tworzy niezależną usługę, która na wejściu dostaje dokument w jakimś języku i tłumaczy go na dowolny inny zwracając przetłumaczony dokument na wyjściu. W tym celu może wykorzystać np Azure Function oraz Azure Cognitive Services. Nie wie natomiast, i nie musi wiedzieć, co się dzieje z dokumentem przed jak i po procesie tłumaczenia.
  • Business owner – wykorzystuje swoje zasoby zgodnie z ich przeznaczeniem dzięki czemu powstaje mniej błędów i dostarczona zostaje większa wartość w krótszym czasie. Osoby, które dobrze rozumieją biznes i mają szeroką wiedzę produktową mogą skupić się na modelowaniu ogólnych ram rozwiązania. Z kolei programiści mogą skupić się na tym fragmencie rozwiązania który najlepiej wykorzystuje ich specjalizację.

To bardzo ważne: korzystając z LCDP wcale nie rezygnujesz z możliwości zastosowania rozwiązań z użyciem regularnego kodu.

LCDP a Wizja jutra

Ostatnią kwestią jest: czy warto wpuszczać platformy LCDP do swojej organizacji? Pojawia się wiele pytań:

  1. Koncepcja LCDP nie jest nowa, a znana była już w latach 90tych. Czemu więc dopiero teraz zyskały na popularności? Może to tylko tymczasowa moda?
  2. Czy platformy LCDP nie zostaną niebawem zastąpione innymi platformami?
  3. Czy decydując się na jednego dostawcę nie wchodzimy w drogę jednokierunkową?

Pozwól więc, że po krótce odpowiem na te pytania.

  1. To prawda, LCDP pojawiły się wcześniej, ale ich niską popularność osobiście wiążę z brakiem odpowiedniej adaptacji standardów programistycznych (REST/GRAPH API, JSON, OAUTH). Taki brak adaptacji uniemożliwiał zbudowanie szerokiem gamy zintegrowanych platform. Natomiast obecnie środowisko IT wyklarowało takie uniwersalne standardy, a nowo budowane rozwiazania podążają za wyznaczonymi dobrymi praktykami. Jest jeszcze jeden istotny powód, a dokładniej 3 powody:
    • Wzrost – szacuje się, że wartość rynku low-code zwiększy się o ponad 21 mln w ciągu następnych 5ciu lat
    • Dywersyfikacja – zapotrzebowanie na rozwiazania IT rośnie, a jednocześnie software developerzy potrzebują odciążenia
    • Integracja – rozwiązania muszą się szybko rozwijać zachowując integrację aby móc wykorzystać potencjał stojący za dziedzinami AI, robotyki i uczenia maszynowego
  2. W całej historii rozwiązań IT rzeczywiście mnóstwo produktów pojawiało się żeby zaraz zostać sprzedanym, zmienionym lub zabitym. Dlatego osobiście wydaje mi się, że najlepiej wiązać się z rozwiązaniami dużych firm, których przyszłość opiera się na zaufaniu swoich klientów. To zaufanie zależy bezpośrednio od posiadanych rozwiązań, a także ich stabilności, przewidywalności, rzetelności oraz bezpieczeństwa powierzanych danych. “Zaufanie czyli Waluta Przyszłości” jak głosi tytuł znakomitej polskiej książki autorstwa Michała Szafrańskiego.
  3. I tak i nie. Z jednek strony rzeczywiście wybierając KTÓREGOKOLWIEK z dostawców procedura wyjścia może być wiązać się nawet z koniecznością przepisania rozwiązania na nowo w przypadku chęci zmiany. Z drugiej jednak strony budowa interfejsu graficznego nie powinna zająć dużo czasu, a w przypadków systemów RPA można zaimplementować krytyczne fragmenty rozwiązań jako niezależne rozwiązania SaaS (np z wykorzystaniem Azure Functions czy web aplikacji)

Podsumowując: dla mnie osobiście Low-Code development platforms są koniecznością każdej firmy chcącej dynamicznie się rozwijać. Niosą ogromną rewolucję jaką swego czasu przyniósł interfejs okienkowy w systemach operacyjnych. Z jednej strony, to tylko zmiana interakcji z procesorem “po drugiej stronie”. Ale z drugiej, to otwarcie na zupełnie nowe możliwości.

Gdybyś chciał dowiedzieć się więcej o tych platformach napisz do mnie! Nauczę Cię z nich korzystać, a jeśli zechcesz pomogę zaprojektować rozwiązanie albo po prostu zbuduję je dla Ciebie!