--- title: "Power Apps: jak wybrać typ aplikacji biznesowej" url: "https://majchrzycki.com/blog/co-to-jest-microsoft-power-apps" description: "Porównaj canvas i model-driven w Power Apps. Sprawdź rolę danych, licencji i testów oraz policz koszt procesu na modelowym przykładzie zakupów." --- # Power Apps: jak wybrać typ aplikacji biznesowej 4 lutego 2024· Aktualizacja: 17 września 2026·4 min czytania·Krzysztof Majchrzycki Temat: [Microsoft AI](https://majchrzycki.com/blog/filar/microsoft-ai) Czy nowa aplikacja ma przede wszystkim prowadzić pracownika przez kilka ekranów, czy porządkować rozbudowane dane i relacje? **W Power Apps wybór zaczyna się od procesu i modelu danych.** Sam wygląd formularza nie wystarczy. Zanim uruchomisz projekt, zapisz, kto podejmuje decyzję, na jakich informacjach i co ma się wydarzyć po zatwierdzeniu rekordu. ## Co daje Power Apps [Microsoft Power Apps](https://learn.microsoft.com/en-us/power-apps/powerapps-overview) to zestaw narzędzi, usług i połączeń do tworzenia aplikacji biznesowych. Aplikacja może korzystać z Dataverse oraz innych źródeł, zależnie od przyjętej architektury. Twórcy mogą konfigurować interfejs i logikę, a programiści rozszerzać rozwiązanie kodem. Podejście low-code ogranicza część pracy programistycznej, ale nie usuwa potrzeby projektowania. Nadal trzeba ustalić znaczenie pól, dostęp do danych, obsługę błędów i sposób utrzymania. Formularz przygotowany w godzinę nie jest automatycznie gotowym procesem produkcyjnym. Aktualny opis Microsoft wyróżnia dwa podstawowe typy aplikacji: canvas i model-driven. Nie traktuj historycznej listy funkcji albo materiału demonstracyjnego jako zamkniętego katalogu możliwości. Szczególnie nowe doświadczenia tworzenia z AI mogą mieć osobny status dostępności i ograniczenia. ## Canvas czy model-driven Aplikacja canvas daje twórcy dużą kontrolę nad układem ekranów i interakcją. To podejście warto rozważyć, gdy użytkownik wykonuje konkretną czynność i potrzebuje interfejsu dopasowanego do jej przebiegu. Elastyczność oznacza też odpowiedzialność za czytelność i zachowanie na różnych urządzeniach. [Aplikacja model-driven](https://learn.microsoft.com/en-us/power-apps/maker/model-driven-apps/model-driven-app-overview) opiera się na modelu danych w Dataverse. Formularze, widoki i nawigacja korzystają z tabel oraz relacji. Jest przydatna przy pracy na wielu powiązanych rekordach, na przykład sprawach, klientach i zadaniach. Układ w większym stopniu wynika z komponentów platformy. Pytanie projektowe Kierunek do sprawdzenia Co zweryfikować Potrzebujesz ściśle zaprojektowanego przebiegu ekranów? Canvas Obsługę telefonu, klawiatury i błędów Użytkownik przechodzi między wieloma powiązanymi rekordami? Model-driven Tabele, relacje i widoki Dane pozostają w kilku istniejących systemach? Canvas z odpowiednimi połączeniami Dostęp, wydajność i licencje Proces ma wspólne dane w Dataverse? Rozważ oba podejścia Potrzeby użytkownika i koszt utrzymania To lista pytań, nie automatyczny algorytm wyboru. Dataverse może również służyć aplikacji canvas. Nie utożsamiaj więc wyboru bazy danych z koniecznością zastosowania jednego rodzaju interfejsu. ## Modelowy przykład: rejestr zgłoszeń zakupowych Wyobraź sobie fikcyjną firmę, która chce zastąpić wiadomości e-mail rejestrem zakupów. Pracownik zgłasza potrzebę, kierownik podejmuje decyzję, a osoba odpowiedzialna za zakup wpisuje status realizacji. Przed budową ekranu ustal trzy obiekty: zgłoszenie, pozycję zakupu i decyzję. Jeżeli jedno zgłoszenie zawiera kilka pozycji, wpisanie ich do jednego długiego pola utrudni późniejsze zestawienia. Jeżeli kierownik zmienia decyzję, nadpisanie samego statusu może zgubić kontekst. Projekt danych powinien odpowiadać na pytania, które firma rzeczywiście będzie zadawać. W tym syntetycznym przykładzie zespół obsługuje 100 zgłoszeń miesięcznie. Ręczne dopisywanie brakujących informacji zajmuje średnio sześć minut na zgłoszenie: łącznie 600 minut. Jeżeli pilotaż zmniejszy tę pracę do dwóch minut, otrzymasz 200 minut i różnicę 400 minut. To hipoteza pomiaru, nie obietnica oszczędności. Do porównania trzeba dodać czas poprawiania błędów, obsługę wyjątków i utrzymanie aplikacji. Jeśli miesięcznie wymaga ono pięciu godzin, z hipotetycznej różnicy pozostaje 100 minut. Taka kalkulacja pomaga dobrać skalę rozwiązania zamiast zakładać, że każda automatyzacja się opłaci. ## Licencja i dostęp wymagają osobnej decyzji [Dokumentacja licencjonowania Power Platform](https://learn.microsoft.com/en-us/power-platform/admin/pricing-billing-skus) rozróżnia uprawnienia i modele rozliczania. Obecność Microsoft 365 w firmie nie oznacza automatycznie prawa do każdej aplikacji, wszystkich połączeń i pełnego Dataverse. Warunki sprawdzaj dla planowanego rozwiązania oraz jego użytkowników. Nie wyceniaj wdrożenia wyłącznie według liczby twórców. Sporządź listę osób korzystających z aplikacji, wymaganych usług, połączeń i automatyzacji. Dopiero na jej podstawie ustal koszt. W tym tekście nie podaję stawki abonamentu, ponieważ sam cennik bez zakresu uprawnień nie rozstrzyga kosztu procesu. Oddziel możliwość otwarcia aplikacji od prawa do zobaczenia lub zmiany danych. Przed pilotażem sprawdź rzeczywiste konta pracownika i kierownika. Test administratora nie potwierdza, że ograniczenia użytkownika działają poprawnie. ## Odbierz proces, zanim rozszerzysz grupę użytkowników Poniższa lista jest propozycją roboczą do odbioru prostego rozwiązania. Dostosuj przypadki do konsekwencji błędu. Aplikacja przyjmująca sugestie pracowników i aplikacja zatwierdzająca wydatki wymagają innej szczegółowości kontroli. Próba Oczekiwany dowód Poprawne zgłoszenie Rekord ma komplet danych i właściciela Brak wymaganej informacji Użytkownik dostaje zrozumiałe wyjaśnienie Osoba bez uprawnienia Nie widzi ani nie zmienia chronionych danych Awaria zapisu Wiadomo, czy rekord powstał i jak ponowić działanie Zmiana osoby utrzymującej Druga osoba potrafi przejąć obsługę rozwiązania Sprawdź również podwójne kliknięcie przycisku oraz ponowienie działania po przerwaniu połączenia. Użytkownik nie powinien zgadywać, czy zamówienie zostało zgłoszone dwa razy. Ustal sposób rozpoznania duplikatu i osobę odpowiedzialną za wyjaśnienie niepewnego wyniku. Funkcje AI mogą pomagać w tworzeniu lub używaniu aplikacji, ale nie zastępują tych prób. Wygenerowany opis pola, formuła czy klasyfikacja zgłoszenia wymagają sprawdzenia. Dla każdego proponowanego zastosowania ustal, jak użytkownik zauważy błąd i poprawi wynik. Zapisz także prostą instrukcję awaryjną: gdzie zgłaszać problem, kto podejmuje decyzję o przerwie i jak obsłużyć sprawy w tym czasie. Utrzymanie nie zaczyna się dopiero przy pierwszej awarii. Jeśli aplikacja jest częścią szerszej zmiany, powiąż ją z odpowiedzialnością opisaną w [systemie pracy firmy z AI](https://majchrzycki.com/system). Następnie sprawdź, jak [Fluent Design pomaga projektować czytelny interfejs aplikacji AI](https://majchrzycki.com/blog/microsoft-fluent-design-system-ai-apps). W poniedziałek wybierz jeden formularz i opisz trzy zwykłe przypadki oraz dwa wyjątki. Dopiero potem porównaj canvas i model-driven na tych samych zadaniach. Wybierz wariant, który da się poprawnie obsłużyć i utrzymać w twojej firmie. - Dane i analityka - Power Platform - Zarządzanie zmianą - Strategia ## Przełóż temat na projekt w Twojej firmie Zobacz zakres współpracy: od rozpoznania procesu i danych po projekt rozwiązania AI. [Zobacz współpracę](https://majchrzycki.com/wspolpraca) ## Czytaj dalej - [Microsoft Power Platform: jak dobrać narzędzia do procesu](https://majchrzycki.com/blog/co-to-jest-microsoft-power-platform-poradnik-dla-firm) - [Power Platform i AI: od prototypu do aplikacji firmowej](https://majchrzycki.com/blog/microsoft-power-platform) - [Microsoft Power Automate: od zadania do stabilnego procesu](https://majchrzycki.com/blog/co-to-jest-microsoft-power-automate) - [Microsoft Dynamics 365 CRM: jak uporządkować relacje](https://majchrzycki.com/blog/microsoft-dynamics-365-crm)