In this blog post I’ll show you how you can build your own Microsoft Flow that is triggered by RSS feed and then re-post it to your social media channels eg. LinkedIn, Twitter or Facebook. I’ll give you example scenarios as well as show how you can aggregate multiple RSS feeds and handle them using Microsoft Flow.
Oh, and I also share my flows – download them, import and use them 🙂
Keep updated
Today, it is not enough to be good at something. To be an expert in technology, to sell services / products or to be an influencer (vloger, blogger, podcaster) one should constantly observe changes in the area subject he specializes in. And here comes the challenge – we have a lot of sources on the Internet (news sites, blogs, internet forums, facebook groups, twitter etc) that create information content. Some of them, especially the most official ones (eg the official PowerApps blog), create content at irregular intervals. So in order to be up to date you can:
Check manually every day using a web browser if the new content appeared on the site. However, this solution is not very scalable (at 10 sources it starts to be uncomfortable. At 30 we start to think about the meaning of life).
Use tools such as Feedly, which observe the latest content using a special summary page with the latest information, the so-called RSS. Today, RSS has the majority of blogs, forums and information services. However, such a solution still requires that we regularly check the selected tool in search of new content.
But if it could be more…
“Keep updated” automated
I love automation. I really do. Automation free my brain memory and processing units so I can focus on more important things. It’s like setting up the alarm instead of constantly checking “what time is now?”.
Some examples of how a one can automate being update:
When a new post appeared on Microsoft Flow blog add me a task to my Todoist (or any other task organizer). BUT! If the new post has been published after 12 PM add the task for tomorrow (so I can keep myself well organized).
In Microsoft Flow portal go to templates and search for RSS (and LinkedIn in my case)
Hit “Create Flow”.
Provide RSS URL
Done.
Want to do it from scratch? No problem.
3 steps:
Add a new Automated Flow and use the RSS trigger
Provide RSS URL
Add LinkedIn (V2) action and fill up the fields
RSS feed connector
The heart of the Flow is the RSS connector. It contains multiple fields which you can use in further Flow actions. The list of all fields is displayed below:
If you’re curious how the example RSS trigger data would be look like check code below – it contains everything I received in the Flow once my previous article has been published:
{
"id": "https://michalguzowski.pl/?p=1544",
"title": "5 steps that increased Office365 adoption",
"primaryLink": "https://michalguzowski.pl/5-steps-that-increased-office365-adoption/",
"links": [
"https://michalguzowski.pl/5-steps-that-increased-office365-adoption/"
],
"updatedOn": "0001-01-01 00:00:00Z",
"publishDate": "2019-07-05 16:42:42Z",
"summary": "<p>Implementation of the Office365 environment in an organization is a complex process. It is not enough to create a company account in Office365, buy subscriptions, add users and connect the organization’s domain. You also have to take care of the transfer of company resources, as well as transfer the solutions used in the organization (or … <a href=\"https://michalguzowski.pl/5-steps-that-increased-office365-adoption/\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> \"5 steps that increased Office365 adoption\"</span></a></p>\n<p>The post <a rel=\"nofollow\" href=\"https://michalguzowski.pl/5-steps-that-increased-office365-adoption/\">5 steps that increased Office365 adoption</a> appeared first on <a rel=\"nofollow\" href=\"https://michalguzowski.pl\">Michał Guzowski Consulting</a>.</p>\n",
"copyright": "",
"categories": [
"Flow",
"In english",
"IT",
"Microsoft",
"PowerApps",
"SharePoint Online",
"Teams"
]
}
Multiple RSS triggers
Once you’ll use RSS trigger you’ll notice that it allows only to put one and only one RSS URL. What to do if you have 3 or 10 RSS feeds to follow? Is there a way to subscribe to multiple RSS feeds using Microsoft Flow?
Answer: yes there is but instead of using simple action or action configuration you need to use a bit of architecture pattern of your whole Flow solution. For reference and instruction please check my video below:
#ProTip: it’s good idea to pass an extra information from a RSS triggered Flow to your Aggregator Flow with the name of the origin Flow. When something goes wrong this field shortcut the time of inspecting the communication flow (which flow send the specific data to aggregator).
And that’s it – hope you find this post helpful. If you have any question feel free to leave a comment below or DM on my twitter account.
P.S.
Thanks to Brad Sams for an inspiration of this post
RSS feed to post on LinkedIn (is this even possible?
Implementation of the Office365 environment in an organization is a complex process. It is not enough to create a company account in Office365, buy subscriptions, add users and connect the organization’s domain. You also have to take care of the transfer of company resources, as well as transfer the solutions used in the organization (or take care of their integration) – that is, make the so-called migration. However, it does not guarantee the success of Office365 implementation. In order for the entire operation to be successful, it should bepersuaded to change the person in the organization. In this article, I will present 5 steps that will increase your chance for effective adoption.
Disclaimer: The steps have been written as a retrospection of the cooperation with one of my clients. Each company is different and requires an individual approach. I encourage you to make an informed decision whether all, some or none of the following steps will be useful to you.
Step 1: Discover the product you bought
Office365 is much more than Outlook, Word, Excel and PowerPoint. Even if we add OneDrive, SharePoint Online, Microsoft Flow and PowerApps to this list, it will not be half as much! And based only on the platforms mentioned above, you can achieve a lot (examples can be found here). How many of these products are in Office365? A very successful combination was made by the jump365.com team:
Be sure to try the interactive version! https://app.jumpto365.com/
It is worth remembering that each of the products has a huge range of its own functionalities and various configurations that allow you to cover countless scenarios.
Finally, the maximum use of the built-in capabilities of Office365 returns with interest – Microsoft constantly improves its products and adds new opportunities, so the answer to the question “build yourself or wait a while” is not at all obvious. Np recently appeared the possibility of integrating the Common Data Service with Outlook, which is another argument to use the CDS database as a data container instead of SQL or SharePoint.
Tip # 1: Make sure you have used the maximum of Office365 built-in features before you approach the development of custom solutions
Step 2: Keep it Simple and Straightforward
We consultants know that everything can be achieved in various ways. For example, sharing the file can be done from the level of SharePoint, OneDrivem application, synchronized folder on the computer, Teams etc. For many people a lot of options are freedom of choice and high integration. But for many, it’s chaos (“means again, how many ways can I do it?”), Lack of coherence (“why do you share from the browser and once from a folder on your computer?”) And this makes them return to “safe places “: the methods they used so far – they were simple, transparent and consistent.
That’s why:
Choose the best and the only right way to proceed. At least at the beginning of implementation. For example, to share a file with people outside the organization, you must first synchronize the OneDrive folder on your computer. Period.
Create instructions for the most key scenarios. For us, these were:
Document scanning (using the mobile application)
Synchronize all team files on your computer
Providing a file to a person outside the organization
Submitting the attachments from the email to the channel in the team
Planning a meeting with the Teams conference
The statement can not be based on an action that has not been described. For example, if you need to synchronize a folder on your computer at some point, remember to create an instruction to set up such a synchronization
Tip # 2: Choose the best and only right course of action. Clearly communicate it in the organization.
Step 3: Segmentation of users
The language of the needs is important (see the next paragraph), but if the organization is of medium size (more than 50 people) or more, it is impossible to talk to each employee. So one should approach the topic methodically.
group employees according to the areas they deal with, for example: finance, processes, IT
identify “key units”, ie people who have a high impact on others and / or decision-making and have resistance to implementing new solutions
identify “influencers” or people who will be promoters of change. They will help others adapt change not only out of a sense of duty, but they will also realistically see the benefits of the upcoming changes. Important: do not choose these people for strength!
Step 4: Learn the language needs
Users themselves will not start using ready-made tools. Even if the company thinks otherwise, for some employees, “excel on the local computer is enough”. The reason is simple – tools are just tools. They are there to meet needs. So in order to implement tools effectively:
Understand the needs of users: get to know the context of their work. See what difficulties are currently. Understand why new solutions would not help them (if they say so)
Express your needs: explain to users the needs for which change is being implemented (see scenario 1)
Speak the language of the users’ needs: show them what benefits they will get thanks to the change. How this change will affect their work (see scenario 1)
think out-of-the-box: declaring the user that something can not be done is not testimony. Because what the user actually says is “it can not be done differently for the adopted assumptions, limitations and understanding of the whole process”. He built a wall around his process. Your task is to move every brick of this wall and remove one after another until the wall collapses. It is important that it involves the process itself (that is, the business would continue its goal). (see scenario 2)
Scenario 1 (real life example)
null
[User] “Using OneDrive is pointless, I already have all the files on my disk and when I need it, I send them to other people by email. Why should we move all the files to another place?”
[Consultant] “We want to limit the e-mails we send in the organization, and we also want to archive all documents and maintain version history.”
[User] “Nothing is lost in emails, but I understand. I will send messages less frequently”
[Consultant] “Hm, and remember how much time it takes you to find the last version of the document in email messages. And imagine that you work on the document for 3 days and it was supposed to be sent in an email, but suddenly the computer broke down and you are not able to recover your 3-day job … “
[User] “Eh … I understand … maybe it’s actually better. But I have all the shortcuts on the desktop, how do we transfer the files, where are they going to be?” [here was the real reason for the resistance]
[Consultant] “Do not worry, we’ll do all the files will be available from your computer and all desktop shortcuts will work. Only the place where these files will be stored will change.”
[User] “super!”
Scenario 2 (real life example)
[Accountant] “We can not digitize the invoice circulation, because every invoice requires a president’s stamp, unless it is possible to attach a picture of such a stamp … but this is only an additional step in the whole process.
[Consultant] “Why is this stuff?”
[Accountant] “For the accounting department to know that the president read and accepted the invoice”
[Consultant] “And the invoice with the stamp stays later inside the company only?”
[Accountant] “Yes”
[Consultant] “And if the president came and said:” I read and accept it”, that would be enough?
[Accountant] “Yes”
[Consultant] “So you use stamps, because it’s faster than personal confirmation and also faster than writing an email. If it was just as simple as: The president gets a notification on the phone and only clicks “accepts” or “reject” and all further communication takes place automatically?
[Accountant] “Hm …. well … all in all it could be so …”
Bingo! 🙂
Tip # 3: Challenge “because we work like this”. Inquires. Be inquisitive. 5x Why.
Tip # 4: To learn about the needs of users, conduct a training / workshop with them. At the beginning of the group, and then carry out ad hoc consultations 1: 1.
Step 5: Apply with small spoons to one plate
When you enter a lot of new tools, some users may be scared of the number of changes. They will feel lost and will return to the old known processes in which they felt comfortable. Therefore, add new tools and improvements slowly, one by one. If possible, do not multiply new applications. Integrate everything in one place. A good idea is, for example, to start with communication through Teams and define teams there. Then incrementally build a daily work process around Teams. Then talk to the identified employees / employee segments and slowly move the subsequent processes.
Tip # 5: Keep your finger on the pulse – Office365 is constantly evolving.
When you’re doing something for the first time there is always the same feeling of chaos. So many new things, uncountable number of topics to learn, mechanisms and concepts that are similar to nothing. How to know it all? Where to start? Of course, from one side, when it comes to IT, every software has its documentation (and in case of PowerApps it’s truly well written). However from the others side…show me at least ONE person who have read the whole documentation before started with something (programming, using tools, develop new app in PowerApps) :). Of course there is none – otherwise people like me, consultants & trainers, won’t have much to do. That’s why I’ve created below a list of 10 tips I wish to know before I’ve started with PowerApps.
When you do something for the first time you feel like a hero in my favorite game from the childhood – HoM&M3. You see gems & crystal, mines and powerful artifacts (that was the promise) but you don’t know how to get them. The fog of war covers the paths. You have to find it by discovering unknown areas. Most of the time you just travel, searching and trying. From time to time you fight an imp or zombie and finally (but rarely in comparison to other activities) you pick your dreamed artifact.
Learning PowerApps
If you read the image description above you probably see a lot of similarities to learning anything. Let’s take PowerApps for example. You want to build an app, create a solution to support your process or build that powerful customized SharePoint list form. For the most of the time you try different approaches, different controls and just discover new functionalities of the platform. From time to time you need to solve an error or warning (eg. my favorite one: delegation) and rarely (in comparison to other activities) you’re completing your dreamed app. And that’s ok – you’re learning. You need to get an experience. Is there a way to increase the effectiveness of your learning path? Yes there is. Follow me 🙂
Minimal effort to maximum effect
To shorten your launch with powerapps I’ve noted down 10 things I wish to know earlier – on the beginning of my PowerApps adventure. Treat them as my footprints you can follow to get your “artifact” quicker.
1. Templates
In PowerApps portal when you go to “Create” page you’ll see bunch of tiles. First three are for creating your app but all the others (28 tiles) are ready-made applications. They presents final solution to a specific requirement (Help Desk, Budget Tracker, Leave Request etc). By clicking on them you’ll add them to your environment and be able to use them. But that’s not all! You can edit them and see how they’re were built! It’s an awesome opportunity to investigate the app structure, logic, used controls and functions to learn the PowerApps. Moreover you can copy app parts and paste into your solution – why not!
Play, test & analyse at least 1 of them.
Tip #1: If you’re beginning with PowerApps focus on templates with the “Canvas app” label
Tip #2: There are two app templates you can’t miss: PowerApps Training and PowerApps Training for Office. A must for everyone who wants to know PowerApps better.
2 . Controls & Properties
There are many controls you can use in your app. Text input, Slider or Timer are just few examples. Use them to interact with a user on multiple ways: display information, gather some data or even record video or take a picture. All controls are under the “Insert” ribbon tab and grouped in categories (Text, Controls, Media etc). Take 10 minutes to discover all the controls in PowerApps. In most cases reading control label is enough to get the general context of it. However take in mind some controls are more complex (eg. gallery or forms).
Another great things about controls are their properties that are for customization. Want this label text to be red? No problem! You don’t like those rounded corners of a button? Sure thing, I don’t like it neither. Properties extends capabilities of the controls. Thank to them you can use a control in multiple ways and in different contexts.
Tip #3: Hardly abused controls are: label, text input, icons, button, gallery, forms. Starts with them. Almost any application needs them.
Tip #4: Check the Advanced tab from the properties pane (the above image). It contains much more properties than Properties tab.
3. Functions
Interaction with a user is one thing but what will happen if a user click this button? And how to show error message once user forget about providing required data? You won’t do much without a logic in your app. And that’s what PowerApps functions are for. Controls, properties and functions are PowerApps bread and butter. Without knowing them you’ll be like a kid in the dark.
There are 155 functions and they are fully described here. In documentation each function description contains a note what it does, when to use it, required arguments and some usage examples. And to be honest probably never use all of them. But below list is really worth of those 30 minutes to check them in documentation.
Tip #5: Some functions are unknown even to those who builds PowerApps professionally. They waste a ton of time to make workarounds for I’m solving in a minute. Some of those functions: User, Param, Language, HashTags,ColorFade, PlainText. Make sure you know them 🙂
4. Connectors
True power of PowerApps (and PowerPlatform generally speaking) lays not in the platform itself but in the integration with other platforms. Thanks to that your app can use the capabilities of another service. I like to think about integration as “borrow the power of other service” in a way. PowerApps contains over 230 connectors to different (! not only Microsoft) services.
From that list few connectors deserve for special attention because of their flexibility and how they greatly improve PowerPlatform extendibility:
Office 365 Users
Power BI
HTTP with Azure AD
HTTP / HTTP Request (available as an action/trigger via Flow)
Tip #6: You want to integrate your own service? Check out Custom Connectors
5. Store data in the right place
Ok, before I’ll say anything more I have to announce one really important thing.
Generally speaking. Ok to store simple tabels. Perfect to store documents. But for storing tabels with relationships model? Absolutely not!
Side note: why some people pick Blob Storage over SharePoint? Versioning, Permissions model, Sharing capabilities, Integration with Teams and Onedrive – SharePoint has it all!
Uf, I’m good now.
So when it comes to storing data there are few places you can do it: OneDrive (Excel), SharePoint and common database (CDS, SQL). First two are a common pick for PowerApps adepts and after some time they always search for help. Because neither excel nor SharePoint are not relational database. But CDS and SQL are! And from my perspective, after last updates, CDS is the first pick when it comes to PowerApps solutions. I won’t dive into my approach details in this post but I’ll definitely cover that in the nearest future. CDS made huge progress and is safe and trustworthy relational database.
Tip #7: Files? SharePoint. Relational database? CDS.
6. Delegation
When it comes to data source connection there will be a moment in time when you’ll see below warning.
But don’t worry! It’s the delegation thing. The delegation mechanism is well described in the documentation. However sometimes delegation is not a solution. If you’ll get to such point read my post: https://michalguzowski.pl/500 . I’ve described 4 workarounds for the 500 limitation (whereas delegation is only 1 of them) + 2 extra my own methods which you won’t find in the Microsoft official resources 😉
7. Turn on Advanced Settings
If you want to build your apps more efficiently and faster there are few options hidden from you by default(!). But as a app maker you can easily turn them on.
Go to File -> App Settings -> Advanced settings
There are awesome functionalities that will boost your productivity. 2 examples:
Components
It’s a group of controls that you can reuse across screen and apps! It’s like you build your own control! Example:
If you want to read more about how to build components and my best practices, patterns and tricks check this blog post.
Formula bar result view
Normally there is no way to see what your filter function will actually return in result unless you display the data using some control (eg. gallery). However turning on “Enable formula bar result view” allows you to see first few results right in your formula bar. Like this:
8. Extra content
The old saying says: “Don’t reinvent the wheel”. When you start with something it’s impossible to always avoid this mistake of reinventing the wheel. Because finding out what has been already made is actually a part of the learning process, right? Sometimes you’ll read about it in documentation, sometimes you’ll see it in one of the PowerApps templates and sometimes you read about in a blog post. That’s why I’ve put this part here 🙂
Remember those times when a 3 hours task already taken 6 hours and you’re not even in the middle of it? That’s the moment when your time management (plan control, reality observations, taking action based on measurements) is crucial but what’s even more important is…your self-control. Quit the berserker mode. Stop the “ohhh…I’ve already spent so much time on this task that now I HAVE TO finish it”.
Follow below:
Your app/task is estimated to be done in X hours
Make a checkpoint every 1/4 * X
Define what you want to have on the particular checkpoint.
If there is “expectations vs reality mismatch” -> ask for help. PowerApps Community & #PowerAddicts are here for you.
Protip #8: don’t be obsessive, know when to quit. Ask for help earlier
10. Practice practice practice
This is universal but very true sentence: “To make apps you have to make apps”. In other means no knowledge gives you as much expertise as practice. If you want to make great apps there is no other way than just make 100 of them.
Every 100 starts with 1.
Task for today: make a simple app.
Eg. with a button that sends you an email on click. But make it so good you could use it in the future. Eg. email can be send to your family member with a random message:
“Will be late – traffic today is horrible”
“Sorry for late, had some bugs in one of my projects but I’m close to fix them. Need ~30 minutes more. Love you!”
“My client asked me to help him in emergency case: they have some problems on production environment! Will be in 2 hours :(”
Can’t find the keys – did you see them?
Was it helpful? Or maybe you think I’ve missed anything?
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:
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:
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)
You want to integrate different components or platforms of your digital workplace (e.g. SharePoint + Outlook + Mailchimp)
Occasionally you have to do a mass operation (e.g. update status of all items in SharePoint lists)
You want to save time by cutting down the overall implementation time
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.
You want to improve productivity in your Office365 environment
Security and contextual data trimming is important for you
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.
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)
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.
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.
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.
Role-driven forms and screens in Canvas Apps – this is however greatly supported by model-driven apps
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:
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)
Use 3rd party solutions for automation – there are other solutions and software tools ready to be use (e.g. UIPath, CodeTwo)
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.
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.
Disclaimer
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.
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:
Licenses
Connectors
User Context
App sharing & versioning
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
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 .
Connectors
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.
WHAT TO WATCH OUT
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)
WHAT TO WATCH OUT
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.
WHAT TO WATCH OUT
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.
WHAT TO WATCH OUT
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:
He understands business well
Has a tooling understanding
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).
Summarizing
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.
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
Disclaimer
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.
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:
Licenses
Connectors
User Context
App sharing & versioning
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ł.
Licenses
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).
Connectors
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.
NA CO UWAŻAĆ
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:
Dobrze rozumie biznes
Posiada rozeznanie narzędziowe
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).
Podsumowując
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.
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:
If it has syntax, it’s code.
— • J O N L E V E S Q U E • (@JonJLevesque) April 30, 2019
PowerApps and Microsoft Flow are not a No-Code platforms.
DISCLAIMER: 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.
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.
1. CREATING IT SOLUTIONS IS EXPENSIVE
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:
Developers need relief in simple tasks. More vividly, to replace a wheel in a car, you do not need rocket engineer services.
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)
2. IT KNOWS IT ON
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).
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
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.
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
If it has syntax, it’s code.
— • J O N L E V E S Q U E • (@JonJLevesque) April 30, 2019
PowerApps i Microsoft Flow to nie są platformy No-Code. Kropka.
DISCLAIMER: 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
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.
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:
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
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:
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).
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
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.
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.
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.
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).
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)
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
Conclusion
Low-Code platforms, in particular PowerApps and Microsoft Flow, are used to:
Integration
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?
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.
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.
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ę).
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)
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.
REALNE WSPARCIE DLA BIZNESU
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ń
Podsumowując
Platformy Low-Code, w szczególności PowerApps i Microsoft Flow służą:
Integracji
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?
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.OkPrivacy policy
