Today I would like to present you one of my favorites apps of my own. I think it’s insanely useful. Especially when you receive an email like below from your client:
The Story
//todo
Usage
Architecture
App consists of following steps:
PowerApps present user interface to let him pick a document (Word or PowerPoint) and select languages he/she wants to translate document to.
A document is uploaded to SharePoint with all metadata (author, desired translated languages)
Microsoft Flow takes a document and pass it to Custom Azure Function
Azure Function open the document and take out each paragraph separately from XML structure.
The paragraph is then translated using Cognitive Service Translation Text API (Azure SaaS) – I used OOB service configuration but it allows for many different tweaks to improve translation output
Azure Function put translated document all together and send it back to Microsoft Flow
Flow saves each translated document as separate file in SharePoint. Thanks to this manner each document content is searchable in SharePoint search. Flow is also responsible to notify user that the documents has been translated.
User can access translated documents directly from the email or using the PowerApps app.
In this article I’ll show you what is elevated privileges, when you may need it and how to run a Microsoft Flow in elevated privilages in SharePoint Online.
Elevated Privileges
Back days, when I was a SharePoint on-premise developer, there was a code method named RunWithElevatedPrivileges() which allows to accomplishing an operation with a higher permissions. The same functionality was available in the SharePoint Designer for workflows under the name: “App Step”
Technically speaking: using RunWithElevatedPrivileges() method run code with Full Control rights despite of the permissions that come from the user context. It was possible due to executing code under the Application Pool Identity (System Account), which has Site Collection Administrator privileges on all Site Collection hosted by that Application Pool.
However In Microsoft Flow there is no such option of running flow with higher permissions. But this is not without a reason! Even though you may think the best way is to override user permissions just to accomplish one operation, a good practice is to improve your solution architecture first. But sometime you won’t have another choice. When it may happen?
When you may need to elevate user permissions?
Some time ago on polish Microsoft 365 User Group I saw following question: “Can I create / configure the flow to be run on elevated privileges for SharePoint Online?”.
First tendency of repliers were to discourage the author of doing so. But he had a good reason.
Case 1
The author tried to achieve a two-level approval. Everything setup on a list of requests and a status field on it. Users and approvers should only have read access on this list and the logic (status update) should be done seamlessly “under the hood”. So in this case, no matter from which list or platform (ie. PowerApps) you start the flow, it still run under user context…a user who shouldn’t have access to the list with requests.
To be honest, when I though for a seconds I’ve found next example when you may need to run flow with an elevated privileges.
Case 2
Imagine that your users need to submit a request or an order that is stored in a simple SharePoint list. But in the same time you want to submit a record anonymously that is HIDE USER CONTEXT.
Is it possible? Actually it is 🙂
Impersonating Microsoft Flow
Please note that from now on I’ll stop using “elevated privileges” or “elevated permissions” and use “Flow Impersonation” because it’s more coherent to what we will really do. We will not give the user higher permissions, we will use another account with a higher permissions instead.
To explain you the architecture I’m going to use the sample of another solutions of mine: Whistleblowing app. The architecture of that app is as followed:
PowerApp gets information from a user and pass to flow. On this stage everything is personalized in PowerApps and Flow. We know who send what.
Flow A pass over HTTP request data to a Flow B. This is the exact moment where we pass data that is essential for the business logic, lose all context information, and impersonate user.
Impersonation is possible because connectors in Flow triggered by HTTP request runs under the accounts which was used during configuration step.
The whole IKEA-alike instruction of setting this up you can find in below video 🙂
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
