Copilot w Power Platform: jak pisać wymagania do aplikacji, żeby Copilot generował sensowne ekrany i tabele

1. Dlaczego jakość wymagań ma kluczowe znaczenie dla Copilota w Power Platform

Copilot w Power Platform potrafi przyspieszyć start projektu, bo na podstawie opisu potrafi zaproponować strukturę danych oraz wygenerować pierwsze ekrany aplikacji. Trzeba jednak pamiętać, że Copilot nie „domyśla się” intencji biznesowej w sposób magiczny — przekształca dostarczone informacje w konkretne elementy rozwiązania. Jeśli opis jest nieprecyzyjny, wynik będzie nieprecyzyjny: powstaną tabele o złej granulacji, pola bez jasnego znaczenia, ekrany niepasujące do pracy użytkownika albo proces, który nie odzwierciedla realnych zasad.

Jakość wymagań ma więc bezpośrednie przełożenie na to, czy Copilot wygeneruje coś, co nadaje się do szybkiego dopracowania, czy raczej szkic, który trzeba przebudować. Dobrze opisane wymagania działają jak „ograniczniki” i „kierunkowskazy”: pomagają Copilotowi wybrać właściwe encje, nazwy, atrybuty, relacje oraz podstawowy układ ekranów.

Copilot jest świetny w generowaniu, ale słabszy w interpretowaniu niedopowiedzeń

W typowych projektach ludzie dopytują o niejasności. Copilot natomiast reaguje na to, co zostało napisane, i w razie luk uzupełnia je założeniami. Te założenia mogą być rozsądne „ogólnie”, ale niekoniecznie zgodne z Twoją organizacją, procesem czy definicjami pojęć. Dlatego jakość wymagań to nie kwestia stylistyki, tylko ryzyka: im więcej niedopowiedzeń, tym więcej błędnych założeń w modelu danych i ekranach.

Najczęstszy problem: zbyt ogólny opis prowadzi do złej struktury danych

W Power Platform fundamentem aplikacji są dane. Jeśli wymagania nie rozróżniają kluczowych obiektów (np. co jest „zgłoszeniem”, co „zadaniem”, a co „klientem”), Copilot może połączyć pojęcia w jedną tabelę albo odwrotnie — rozbić je w sposób utrudniający raportowanie i integracje. A gdy fundament jest krzywy, kolejne elementy (formularze, widoki, automatyzacje) będą trudniejsze do utrzymania i rozbudowy.

Różnica między „opisem aplikacji” a „wymaganiami”

Opis aplikacji zwykle mówi co ma powstać na wysokim poziomie. Wymagania pomagają zrozumieć po co, dla kogo, na jakich danych i w jakich ograniczeniach ma to działać. Copilot potrzebuje właśnie tego drugiego. Im bardziej wymagania przypominają uporządkowany opis pracy użytkownika i danych, tym większa szansa, że wygenerowane ekrany i tabele będą „trafione” już w pierwszej iteracji.

Co się dzieje, gdy wymagania są słabe

• Nieadekwatne ekrany — zbyt ogólne formularze, brak kluczowych widoków, niewłaściwa kolejność kroków pracy.
• Chaotyczne nazewnictwo — pola i tabele z nazwami niezgodnymi ze słownikiem organizacji, co utrudnia komunikację w zespole i utrzymanie rozwiązania.
• Nadmiar lub brak pól — Copilot może dodać atrybuty „na wszelki wypadek” albo pominąć krytyczne informacje, jeśli nie zostały wskazane.
• Błędne relacje — brak jasnego wskazania powiązań skutkuje relacjami, które ograniczają raportowanie, historię zmian lub uprawnienia.
• Więcej ręcznych poprawek — czas oszczędzony na starcie wraca jako koszt przebudowy danych i ekranów.

Co zyskujesz, gdy wymagania są dobre

• Szybszy start i mniej iteracji — pierwsza wersja jest bliższa oczekiwaniom, a poprawki są kosmetyczne, nie fundamentalne.
• Spójny model danych — łatwiejsze raportowanie, integracje i dalsza rozbudowa.
• Lepsze dopasowanie do ról — aplikacja od początku wspiera rzeczywiste zadania użytkowników, zamiast wymuszać obejścia.
• Lepsza jakość automatyzacji — sensowne zdarzenia i punkty procesu wynikają wprost z opisu pracy, a nie z domysłów.

Wymagania jako „prompt projektowy”

W praktyce opis wymagań dla Copilota działa jak prompt, ale o większej wadze: determinuje nie tylko tekstową odpowiedź, lecz także strukturę rozwiązania. Dobra praktyka to traktowanie wymagań jako zestawu jasnych decyzji: definicji pojęć, granic zakresu i oczekiwanego rezultatu. Dzięki temu Copilot ma mniej miejsca na zgadywanie, a więcej na generowanie elementów, które realnie wspierają proces biznesowy.

2. Szablon opisu wymagań: cele, zakres i kryteria sukcesu

Copilot w Power Platform potrafi wygenerować sensowne ekrany i tabele tylko wtedy, gdy rozumie po co aplikacja powstaje, co ma obejmować oraz jak poznamy, że działa dobrze. Ten artykuł powstał jako rozwinięcie jednego z najczęstszych tematów poruszanych podczas szkoleń Cognity. Ta sekcja to minimalny szablon, który porządkuje intencję biznesową i ogranicza „zgadywanie” przez Copilota. Dzięki temu kolejne kroki (role, dane, reguły, automatyzacje) mają stabilny punkt odniesienia.

Cele (po co)

Opis celów powinien być krótki, jednoznaczny i nastawiony na rezultat. To nie lista funkcji, tylko odpowiedź na pytanie, jaki problem ma zostać rozwiązany i jaka zmiana ma zajść w procesie.

• Cel główny: jedna–dwie linijki opisujące najważniejszy rezultat (np. skrócenie czasu obsługi spraw, poprawa jakości danych, ujednolicenie procesu).
• Cele poboczne: 2–5 punktów wspierających cel główny, ale nieprzesłaniających go.
• Użytkownicy i kontekst: ogólne wskazanie, kto korzysta i w jakiej sytuacji (bez rozpisywania uprawnień i scenariuszy).
• Ograniczenia i priorytety: co jest ważniejsze (szybkość wdrożenia, prostota, kompletność danych, zgodność), oraz kluczowe ograniczenia (np. kanał: web/mobilnie, praca offline, wymogi audytu).

Wskazówka dla Copilota: cele formułuj w języku efektu. Zamiast „mieć ekran do zgłoszeń” napisz „umożliwić rejestrowanie zgłoszeń w 2 minuty i ich dalszą obsługę w jednym miejscu”.

Zakres (co obejmuje, a czego nie)

Zakres to „ramy boiska” dla Copilota. Bez niego Copilot ma tendencję do generowania dodatkowych bytów, pól i ekranów „na wszelki wypadek”. Zakres powinien opisywać granice funkcjonalne i procesowe, ale bez wchodzenia w szczegółowy model danych czy logikę formularzy.

• W zakresie: kluczowe obszary procesu, które aplikacja ma pokryć (np. rejestracja, przegląd, zatwierdzenie, raportowanie).
• Poza zakresem: co świadomie nie jest teraz budowane (np. zaawansowane raporty, rozliczenia, pełna integracja z systemami zewnętrznymi).
• Granice danych: jakie kategorie danych aplikacja przechowuje/obsługuje w uproszczeniu (np. „sprawy, osoby, statusy”), bez definiowania atrybutów.
• Interfejsy i kanały: czy aplikacja ma być tylko wewnętrzna, czy także dla użytkowników zewnętrznych; czy priorytetem jest mobilność.
• Założenia: kluczowe założenia, które wpływają na generowane ekrany (np. „większość użytkowników pracuje na telefonie”, „wymagane jest szybkie wyszukiwanie”).

Różnica, o którą chodzi: cele mówią „dlaczego”, zakres mówi „dokładnie gdzie kończymy”. To zakres najczęściej decyduje o tym, czy Copilot nie wygeneruje zbyt rozbudowanej struktury.

Kryteria sukcesu (skąd wiemy, że działa)

Kryteria sukcesu to warunki akceptacji na poziomie rozwiązania. Dla Copilota są „kotwicą”: pomagają dobrać minimalny zestaw ekranów i danych, który spełnia cel, zamiast tworzyć rozbudowaną aplikację bez jasnej definicji „gotowe”.

• Metryki procesu: mierzalne oczekiwane efekty (np. czas realizacji kroku, liczba błędów, kompletność danych).
• Metryki użyteczności: ile kliknięć/kroków, czytelność, prostota wprowadzania, wyszukiwanie.
• Jakość danych: minimalny poziom kompletności i spójności (np. wymagane pola krytyczne, brak duplikatów w kluczowych rejestrach).
• Akceptacja biznesowa: kto zatwierdza i na jakiej podstawie (ogólnie, bez listy ról i uprawnień).
• Warunki brzegowe: co uznajemy za działające w pierwszej wersji (MVP), a co może zostać odłożone.

Wskazówka: jeśli nie da się zmierzyć kryterium, opisz je jako obserwowalne zachowanie („użytkownik może dodać sprawę i odnaleźć ją po numerze/tytule”), zamiast ogólników („aplikacja ma być intuicyjna”).

Minimalny szablon do wypełnienia (do wklejenia w prompt)

Cele: [cel główny w 1–2 zdaniach]. [2–5 celów pobocznych].

Zakres: W zakresie: [3–6 punktów]. Poza zakresem: [3–6 punktów]. Założenia: [2–5 punktów].

Kryteria sukcesu: [3–8 mierzalnych lub obserwowalnych kryteriów].

Tak przygotowany opis jest wystarczająco konkretny, by Copilot zaproponował strukturę rozwiązania, a jednocześnie na tyle ogólny, by nie mieszać w tym miejscu szczegółów, które powinny zostać doprecyzowane później.

3. Szablon: role użytkowników, uprawnienia i scenariusze użycia (user stories)

Copilot w Power Platform potrafi wygenerować sensowne ekrany i tabele tylko wtedy, gdy rozumie kto będzie używał aplikacji, co ma robić i jakie ograniczenia wynikają z odpowiedzialności, bezpieczeństwa i procesu. Opis ról, uprawnień i scenariuszy użycia porządkuje wymagania tak, aby Copilot nie „uśredniał” interfejsu dla wszystkich i nie proponował funkcji, które w praktyce powinny być niedostępne.

3.1. Minimalny szablon opisu ról

Role opisuj konkretnie: nie jako stanowiska, lecz jako typy użytkowników o wspólnych celach i zakresie pracy. Dla każdej roli podaj:

• Nazwa roli (krótka, jednoznaczna)
• Cel (po co wchodzi do aplikacji)
• Zakres pracy (jakie obszary danych/rekordów obsługuje)
• Ograniczenia (czego nie wolno robić / czego nie widzi)
• Wrażliwe pola (np. dane finansowe, dane osobowe) – na poziomie wskazania, bez wchodzenia w szczegółowe modele

3.2. Uprawnienia: czym różni się „może” od „może tylko w swoim zakresie”

Wymagania dotyczące uprawnień warto zapisać prostym słownikiem akcji (CRUD + operacje specyficzne), a następnie doprecyzować zakres dostępu. To pomaga Copilotowi od razu zaproponować podział na ekrany (np. „Moje sprawy” vs „Wszystkie sprawy”) i uniknąć ekranów administracyjnych dla zwykłych użytkowników.

3.3. Tabela ról i uprawnień (do wklejenia w wymagania)

Użyj jednej tabeli, która wprost mapuje role na możliwości. Staraj się unikać nieprecyzyjnych sformułowań typu „pełny dostęp” – rozbij to na akcje i zakres.

Role:
1) Rola A – opis celu
2) Rola B – opis celu

Macierz uprawnień (przykładowy format):
- Obiekt/obszar: [np. Zgłoszenia]
  - Rola A: Odczyt (własne), Utwórz, Edytuj (własne, tylko Robocze), Usuń (brak)
  - Rola B: Odczyt (wszystkie), Zatwierdź, Zwróć do poprawy
- Obiekt/obszar: [np. Załączniki]
  - Rola A: Dodaj, Pobierz (własne)
  - Rola B: Pobierz (wszystkie)

3.4. Scenariusze użycia (user stories): jak je pisać, żeby Copilot tworzył właściwe ekrany

User stories działają jak „mapa ekranów”: z nich Copilot wywnioskuje, czy potrzebujesz list, formularzy, widoków szczegółów, kroków zatwierdzania czy ekranów wyszukiwania. Dobrze napisane scenariusze są konkretne i zawierają kontekst roli, wejście/wyjście oraz warunki.

Format (zalecany):

• Jako [rola]
• Chcę [czynność na obiekcie / w procesie]
• Aby [cel biznesowy]
• Kryteria akceptacji (2–5 punktów, testowalne)
• Dane wejściowe/wyjściowe (krótko: jakie informacje użytkownik podaje i co dostaje)
• Wyjątki (kiedy nie wolno / kiedy trzeba zablokować)

3.5. Zestaw „must-have” user stories

Aby Copilot nie pominął podstawowych ekranów, uwzględnij przynajmniej scenariusze z poniższych kategorii (zależnie od aplikacji):

• Przeglądanie: lista rekordów + filtrowanie/wyszukiwanie
• Tworzenie: nowy rekord + minimalny zestaw pól
• Szczegóły: podgląd rekordu + sekcje informacyjne
• Edycja: zmiana danych (z warunkami, jeśli występują)
• Załączniki/komentarze: jeśli użytkownicy mają współpracować przy rekordzie
• Zatwierdzenia/decyzje: jeśli występuje rola „akceptująca”
• Raportowanie: proste widoki podsumowań (co najmniej potrzeby informacyjne)
• Administracja: tylko jeśli rzeczywiście potrzebna (np. słowniki, konfiguracja)

3.6. Przykładowy szablon user story (do kopiowania)

User story: [krótka nazwa]
Jako: [rola]
Chcę: [co użytkownik robi]
Aby: [jaki efekt/cel]

Kryteria akceptacji:
1) [warunek + oczekiwany rezultat]
2) [warunek + oczekiwany rezultat]
3) [opcjonalnie]

Dane wejściowe:
- [np. pola, załącznik, komentarz – ogólnie]

Dane wyjściowe:
- [np. potwierdzenie, numer, status, widok na liście]

Wyjątki/Ograniczenia:
- [np. brak uprawnień, nieprawidłowy status]

3.7. Dobre praktyki, które poprawiają jakość generowanych ekranów

• Jedna rola = jeden zestaw celów: jeśli rola ma sprzeczne potrzeby, rozbij ją na dwie.
• Nazywaj akcje tak, jak będą w UI: „Zatwierdź”, „Zwróć do poprawy”, „Zamknij” zamiast ogólnego „Zmień status”.
• Opisuj ograniczenia wprost: „nie widzi”, „nie może edytować”, „tylko własne” – Copilot lepiej przekłada to na widoki i blokady.
• Dodaj kryteria akceptacji: bez nich Copilot ma tendencję do tworzenia zbyt ogólnych formularzy.
• Nie mieszaj poziomów: w tej sekcji trzymaj się ról, uprawnień i scenariuszy; szczegóły danych i automatyzacji zapisuj osobno.

4. Szablon: model danych (encje, atrybuty, relacje) oraz słowniki i przykładowe rekordy

Copilot w Power Platform generuje ekrany, formularze i tabele głównie na podstawie modelu danych. Jeśli opiszesz encje, ich pola oraz powiązania jasno i konsekwentnie, Copilot ma z czego „złożyć” sensowną strukturę aplikacji (widoki list, formularze szczegółów, sekcje, podtabele, pola wyboru). Gdy model jest nieprecyzyjny, Copilot zwykle tworzy przypadkowe kolumny, błędne typy danych lub relacje, które później trudno poprawić bez przebudowy. Zespół trenerski Cognity zauważa, że właśnie ten aspekt sprawia uczestnikom najwięcej trudności — dlatego poniżej znajdziesz prosty, powtarzalny standard opisu.

4.1. Minimalny standard opisu modelu danych

W opisie modelu danych warto trzymać się czterech bloków: encje (tabele), atrybuty (kolumny), relacje oraz słowniki (zestawy wartości). Dodatkowo podaj przykładowe rekordy, bo pomagają Copilotowi dobrać typy pól i układ ekranów.

4.2. Encje (tabele): co opisać

• Nazwa encji (liczba pojedyncza, np. „Zgłoszenie”, „Umowa”, „Klient”) oraz opcjonalnie nazwa mnoga.
• Cel encji: jedno zdanie „po co istnieje” (pomaga odróżnić encje podobne).
• Klucz główny (np. „NumerZgłoszenia” lub ID) i czy ma być generowany automatycznie.
• Najważniejsze pola (5–15) – nie próbuj opisywać całej organizacji w pierwszym podejściu.
• Właściciel danych na poziomie logicznym (kto odpowiada za poprawność) – bez wchodzenia w szczegóły uprawnień.

4.3. Atrybuty (kolumny): jak opisywać, żeby Copilot trafiał z typami

Przy każdym polu podaj: nazwę, opis, typ danych oraz czy wymagane. Jeśli ma znaczenie, dopisz przykładową wartość. To często wystarcza, by Copilot zaproponował właściwe kontrolki na formularzu.

Uwaga praktyczna: unikaj pól „Opis1/Opis2” i „PoleA/PoleB”. Copilot (i ludzie) nie zrozumieją intencji. Lepiej rozbić na jednoznaczne atrybuty albo zostawić pole opisowe typu „Uwagi”.

4.4. Relacje: jak je opisać bez przeciążania szczegółami

Relacje są kluczowe, bo wpływają na to, czy Copilot wygeneruje sensowne ekrany „lista → szczegóły → powiązane rekordy”. Wystarczy opisać kardynalność i nazwę powiązania.

• 1:N (jeden do wielu) – np. jeden „Klient” ma wiele „Zgłoszeń”. Copilot zwykle doda podtabelę na ekranie klienta oraz pole wyboru klienta w zgłoszeniu.
• N:1 (wiele do jednego) – to perspektywa rekordu podrzędnego; w praktyce ten sam przypadek co 1:N, tylko opisywany od drugiej strony.
• N:N (wiele do wielu) – np. „Zgłoszenie” może dotyczyć wielu „Produktów”, a „Produkt” może występować w wielu zgłoszeniach. Warto wskazać, czy potrzebna jest encja pośrednia (np. „PozycjaZgłoszenia”) z dodatkowymi polami.

4.5. Słowniki (listy wartości): co to jest i jak je opisać

„Słowniki” to kontrolowane zestawy wartości (np. statusy, kategorie, priorytety). Dla Copilota są wskazówką, że pole powinno być wyborem (dropdown/option set), a nie luźnym tekstem.

• Nazwa słownika (np. „StatusZgłoszenia”).
• Lista wartości (najlepiej 5–12, z jasnymi nazwami).
• Znaczenie wartości (krótko, jeśli nazwa nie jest oczywista).
• Czy lista jest stała czy zarządzana jako osobna encja (gdy wartości mają się często zmieniać lub wymagają dodatkowych atrybutów, np. „aktywne/nieaktywne”).

Prosty zapis słownika w wymaganiach może wyglądać tak:

StatusZgłoszenia (wybór):
- Nowe
- W toku
- Oczekuje na informacje
- Zrealizowane
- Anulowane

4.6. Przykładowe rekordy: szybki sposób na „uziemienie” modelu

Dodaj 2–5 przykładowych rekordów dla każdej kluczowej encji. Nie chodzi o dane produkcyjne, tylko o pokazanie typowych wartości, długości tekstu, formatów dat i zależności między tabelami. Copilot lepiej dobierze nazwy pól, typy i układ formularzy, gdy zobaczy realistyczne przykłady.

4.7. Gotowy szablon do wklejenia w wymagania

MODEL DANYCH

1) Encje (tabele)
- [NazwaEncji]: (cel encji w 1 zdaniu)
  Klucz: [nazwa pola klucza] (auto/manual)
  Pola:
  - [NazwaPola] (etykieta: ...): typ=..., wymagane=tak/nie, opis=..., przykład=...
  - ...

2) Relacje
- [EncjaA] (1) → [EncjaB] (N): opis relacji w 1 zdaniu
- [EncjaC] (N) ↔ [EncjaD] (N) przez [EncjaPośrednia] (jeśli dotyczy)

3) Słowniki (listy wartości)
- [NazwaSłownika]: typ=wybór / osobna encja
  Wartości: ...

4) Przykładowe rekordy
- [NazwaEncji]: {pole1: ..., pole2: ..., ...}

Tak przygotowany model danych daje Copilotowi jednoznaczne „klocki”: jakie tabele utworzyć, jak je połączyć i jakie pola pokazać użytkownikowi na ekranach.

5. Szablon: reguły biznesowe, walidacje, logika formularzy i stany procesu

Jeśli chcesz, aby Copilot w Power Platform wygenerował ekrany i tabele, które „trzymają się” Twojego procesu, musisz opisać nie tylko co użytkownik wpisuje, ale też kiedy, w jakich warunkach i co jest dozwolone. Ta sekcja szablonu zbiera zasady działania aplikacji: reguły biznesowe, walidacje, zachowanie formularzy oraz cykl życia rekordów (statusy). Bez tego Copilot ma tendencję do tworzenia zbyt ogólnych formularzy, zbyt wielu pól edytowalnych naraz i niejasnych statusów.

5.1. Jak rozróżniać: reguła biznesowa vs walidacja vs logika formularza vs stan procesu

5.2. Szablon do wypełnienia: reguły biznesowe

Opisz reguły jako jednoznaczne warunki. Unikaj sformułowań „zwykle”, „czasem”, „w miarę możliwości”. Każda reguła powinna mieć skutek, który Copilot może przełożyć na pola, akcje lub ograniczenia.

• ID reguły: RB-___
• Dotyczy: encja/rekord ______, ekran/formularz ______
• Opis reguły (IF/THEN): Jeśli ______, to ______
• Konsekwencja w aplikacji: zablokuj/ukryj/wymagaj/ustaw domyślnie/wylicz ______
• Wyjątki: kiedy reguła nie obowiązuje ______
• Priorytet: wysoki/średni/niski (co ma „wygrać”, gdy reguły się zderzają)
• Przykład danych wejściowych i oczekiwany rezultat: ______

5.3. Szablon do wypełnienia: walidacje danych

Walidacje są kluczowe, bo podpowiadają Copilotowi, które pola mają być wymagane, jakie typy danych wybrać oraz jakie ograniczenia dodać. Zawsze dopisz komunikat błędu — to wymusza precyzję.

• ID walidacji: VAL-___
• Pole(a): ______
• Rodzaj: wymagane / format / zakres / unikalność / zależność między polami
• Warunek: ______
• Poziom: blokująca zapis / ostrzeżenie
• Komunikat dla użytkownika: „______”
• Moment sprawdzenia: w trakcie edycji / przy zapisie / przy zmianie statusu

5.4. Szablon do wypełnienia: logika formularzy i zachowanie UI

Ta część powinna mówić Copilotowi, jak „prowadzić” użytkownika: co pokazać najpierw, co ukryć do czasu spełnienia warunków, co automatycznie uzupełniać. Nie opisuj tu automatyzacji między systemami — skup się na zachowaniu ekranu.

• Widoczność pól/sekcji:
  • Gdy ______, pokaż/ukryj ______
• Edytowalność:
  • W statusie ______ pole ______ jest tylko do odczytu
  • Dla roli ______ pole ______ jest edytowalne/nieedytowalne
• Wartości domyślne i autopodpowiedzi:
  • Po utworzeniu rekordu ustaw ______ na ______
  • Po zmianie pola ______ uzupełnij ______
• Wyliczenia w formularzu:
  • Pole ______ = ______ (opis słowny formuły)
• Układ i kolejność kroków w formularzu:
  • Najpierw zbierz ______, potem ______, na końcu ______
• Akcje na ekranie:
  • Przycisk „______” jest dostępny gdy ______ i wykonuje ______

5.5. Szablon do wypełnienia: stany procesu (statusy) i przejścia

Statusy porządkują pracę i są jednym z najsilniejszych sygnałów dla Copilota, jak zbudować aplikację „procesową” (z czytelnymi etapami). Opisz minimalny zestaw stanów oraz dozwolone przejścia. Jeśli status ma blokować edycję — napisz to wprost.

• Nazwa procesu/obiektu: ______
• Lista statusów (w kolejności):
  • Status: ______ | Cel: ______ | Kto ustawia: ______ | Co jest zablokowane: ______
  • Status: ______ | Cel: ______ | Kto ustawia: ______ | Co jest zablokowane: ______
• Dozwolone przejścia:
  • ______ → ______ (warunek: ______, rola: ______)
  • ______ → ______ (warunek: ______, rola: ______)
• Przejścia niedozwolone:
  • Nie wolno przejść z ______ do ______, bo ______
• Wymagania przy zmianie statusu:
  • Przed przejściem do ______ muszą być spełnione walidacje: ______
  • Po przejściu do ______ ustaw/wyczyść pola: ______

5.6. Minimalny przykład zapisu (format do skopiowania)

RB-01
Dotyczy: [Encja: ______] / [Formularz: ______]
Jeśli: ______
To: ______
Konsekwencja w aplikacji: ______
Wyjątki: ______
Priorytet: ______
Przykład: Dane: ______ → Wynik: ______

VAL-01
Pole(a): ______
Rodzaj: ______
Warunek: ______
Poziom: blokująca zapis / ostrzeżenie
Komunikat: "______"
Moment: ______

UI-01
Gdy: ______
Wtedy: pokaż/ukryj/odblokuj/zablokuj/uzupełnij pole ______

PROC-01
Statusy: ______ → ______ → ______
Przejścia:
- ______ → ______ (warunek: ______, rola: ______)
- ______ → ______ (warunek: ______, rola: ______)
Blokady edycji:
- W statusie ______ pola: ______ są tylko do odczytu

5.7. Checklist: czy opis jest wystarczająco precyzyjny dla Copilota?

• Każda reguła ma jasny warunek i skutek (bez „ogólników”).
• Walidacje mają komunikaty błędów i informację, czy blokują zapis.
• Wskazałeś, które pola są read-only w konkretnych statusach i/lub dla ról.
• Statusy mają dozwolone przejścia oraz warunki przejść.
• Opisałeś wyjątki i priorytety tam, gdzie reguły mogą się konfliktować.

6. Szablon: przepływy/automatyzacje (Power Automate), powiadomienia i integracje

Copilot w Power Platform potrafi zasugerować ekrany i tabele na podstawie wymagań, ale żeby wygenerował też sensowne automatyzacje i integracje, potrzebuje precyzyjnego opisu zdarzeń, warunków, odbiorców i systemów. W tej sekcji dostajesz szablon, który porządkuje informacje tak, aby Copilot mógł zaproponować: kiedy uruchamiać przepływy, jakie akcje wykonać, jak powiadamiać użytkowników oraz jak wymieniać dane z innymi usługami.

6.1. Kiedy opisywać Power Automate, a kiedy logikę w aplikacji?

W wymaganiach warto rozdzielić elementy, które mają być realizowane przez przepływy, od tych, które powinny działać w samej aplikacji. Dzięki temu Copilot nie „miesza” automatyzacji z walidacjami formularzy czy stanami procesu.

6.2. Szablon opisu przepływu (Power Automate)

Wklej poniższą strukturę do wymagań dla każdej automatyzacji. Jeśli przepływów ma być dużo, nadaj im identyfikatory (np. F-01, F-02), żeby Copilot i zespół odnosił się do tych samych elementów.

• ID i nazwa przepływu: [F-01] [nazwa jednoznaczna, np. „Wysłanie potwierdzenia po zatwierdzeniu”]
• Cel biznesowy: [po co istnieje przepływ, jaki problem rozwiązuje]
• Typ uruchomienia (trigger):
  • Zdarzenie danych (utworzenie/zmiana/usunięcie rekordu)
  • Akcja użytkownika (przycisk w aplikacji)
  • Harmonogram (np. raz dziennie)
  • Webhook / zdarzenie zewnętrzne
• Warunek uruchomienia: [np. tylko gdy status zmieni się z X na Y; tylko dla rekordów spełniających kryteria]
• Dane wejściowe: [jakie pola/identyfikatory są potrzebne; z jakiej encji/źródła]
• Główne kroki (akcje):
  • Krok 1: [akcja] → wynik
  • Krok 2: [akcja] → wynik
  • Krok 3: [akcja] → wynik
• Dane wyjściowe / zapis: [co ma zostać zaktualizowane i gdzie; jakie pola; jakie statusy]
• Obsługa błędów:
  • Co uznajemy za błąd: [np. brak odpowiedzi z API, brak wymaganych danych, limit]
  • Retry: [czy ponawiać, ile razy, z jakim odstępem]
  • Fallback: [co zrobić, gdy się nie uda]
  • Powiadomienie o błędzie: [kto, kanał, treść]
• Idempotencja / duplikaty: [czy przepływ może uruchomić się wielokrotnie; jak zapobiec podwójnym operacjom]
• Wydajność i limity: [wolumen, częstotliwość, SLA; okna czasowe]
• Wymagane uprawnienia/połączenia: [jakie konektory; czy wymagany account serwisowy]
• Telemetria i audyt: [co logujemy; gdzie widać historię; które pola do śledzenia]

6.3. Szablon powiadomień: kanały, reguły i treść

Powiadomienia często wychodzą poza samą aplikację. Copilot lepiej je zaprojektuje, jeśli opiszesz matrycę powiadomień zamiast ogólników w stylu „wysłać maila”.

• Wydarzenie: [co się stało; np. „rekord przeszedł w status Zatwierdzone”]
• Odbiorcy: [rola/grupa; czy autor rekordu, opiekun, przełożony; zasady zastępstw]
• Kanał: [e-mail / Teams / powiadomienie w aplikacji / SMS (jeśli dotyczy)]
• Priorytet i pilność: [informacyjne / wymagające akcji / krytyczne]
• Treść: [temat + kluczowe pola; link do rekordu; jasne CTA „Otwórz/Zaakceptuj/Odrzuć”]
• Warunki wysyłki: [kiedy nie wysyłać; progi; filtry; strefa czasowa]
• Ograniczenia: [limit liczby powiadomień; grupowanie; cooldown]
• Eskalacja: [po ilu godzinach/dniach; do kogo; w jakim kanale]

6.4. Szablon integracji: systemy, kierunek danych i mapowanie

Dla Copilota najważniejsze jest, aby integracje były opisane jako konkretne przepływy danych, a nie jako „połączyć z systemem X”. Skup się na: co, skąd, dokąd, kiedy i jak bezpiecznie.

• ID i nazwa integracji: [I-01] [np. „Pobranie danych referencyjnych”]
• Systemy i kierunek: [A → B] lub [B → A] lub dwukierunkowo
• Obiekt/zakres danych: [jakie encje/rekordy; czy pełna synchronizacja czy tylko przyrost]
• Tryb wymiany: [API / plik / webhook / konektor]
• Częstotliwość i okna: [near-real-time, co 15 min, raz dziennie; ograniczenia czasowe]
• Mapowanie pól: [lista kluczowych pól; identyfikatory; zasady transformacji (np. format dat)]
• Reguły konfliktów: [co jest źródłem prawdy; jak rozstrzygać kolizje]
• Obsługa błędów i monitoring: [alerty, kolejka błędów, ponawianie, ręczna interwencja]
• Bezpieczeństwo: [uwierzytelnianie; zakres uprawnień; przechowywanie sekretów; RODO jeśli dotyczy]
• Wymagania niefunkcjonalne: [limity API, throttling, maks. czas odpowiedzi, SLA]

6.5. Minimalna „checklista” dla Copilota (żeby nie generował ogólników)

• Nazwij zdarzenie jednoznacznie (np. „status zmieniony z A na B”), zamiast „po zmianie”.
• Podaj odbiorców po regułach (rola/relacja do rekordu), zamiast „powiadomić zainteresowanych”.
• Rozdziel integrację od powiadomienia (to różne cele i różne ryzyka).
• Opisz co najmniej jeden scenariusz błędu (brak danych, limit, niedostępność) i oczekiwane zachowanie.
• Dodaj wolumen (np. liczba rekordów/dzień), bo wpływa na dobór triggerów i harmonogramów.

6.6. Krótki przykład zapisu (do skopiowania)

[F-01] Powiadomienie o zatwierdzeniu
Cel: poinformować autora rekordu o decyzji i zapisać datę powiadomienia.
Trigger: zmiana rekordu, gdy Status przechodzi z „W trakcie” na „Zatwierdzone” lub „Odrzucone”.
Wejście: ID rekordu, Autor (użytkownik), Status, Komentarz.
Akcje: (1) zbuduj treść wiadomości z kluczowymi polami i linkiem do rekordu, (2) wyślij powiadomienie e-mail, (3) zapisz pole DataPowiadomienia.
Błędy: jeśli e-mail nie wysłany → ponów 3 razy co 10 min; po niepowodzeniu → alert do skrzynki zespołu i oznacz rekord flagą „BłądPowiadomienia”.

7. Przykłady dobrych i złych promptów: jak pisać, czego unikać i jak doprecyzowywać iteracyjnie

Copilot w Power Platform potrafi zaproponować sensowne ekrany i tabele wtedy, gdy dostaje opis jednoznaczny: co ma powstać, dla kogo, jakie dane mają być rejestrowane i jak mierzymy sukces. Różnica między „dobrym” a „złym” promptem zwykle nie polega na długości, tylko na tym, czy zawiera konkret, kontekst i granice.

Co odróżnia dobry prompt od złego

• Dobry prompt opisuje cel w jednym zdaniu i doprecyzowuje: proces, role, dane wejściowe/wyjściowe, podstawowe reguły oraz oczekiwane ekrany.
• Zły prompt używa ogólników („aplikacja do zarządzania”, „ładne UI”), miesza kilka tematów naraz albo pomija kluczowe dane („jakie tabele?” „jakie pola?”).
• Dobry prompt wskazuje zakres i ograniczenia (co jest poza zakresem, jakie źródło danych, czy to ma być Canvas czy Model-driven, jeśli ma to znaczenie).
• Zły prompt zostawia Copilotowi decyzje o krytycznej architekturze bez wskazania priorytetów (np. „zrób CRM” bez doprecyzowania, czy chodzi o prosty rejestr, czy pełny proces sprzedaży).

Przykłady: złe prompty (dlaczego nie zadziałają)

• „Zbuduj aplikację do zarządzania zgłoszeniami.”
  Problem: brak typu zgłoszeń, ról, pól, statusów, reguł i tego, co ma być wynikiem.
• „Potrzebuję bazy danych i kilku ekranów.”
  Problem: brak encji, relacji, minimalnego zestawu danych i tego, co użytkownik robi na ekranach.
• „Zrób to jak najlepsze i nowoczesne.”
  Problem: kryteria są subiektywne; Copilot nie wie, co znaczy „najlepsze” w kontekście procesu.
• „Aplikacja do obsługi klientów z integracjami.”
  Problem: nie wiadomo, jakie integracje, w jakim celu, w którym momencie procesu i jakie dane mają być wymieniane.

Przykłady: dobre prompty (co w nich działa)

• Prompt na start (pierwsza wersja):
  „Zaprojektuj aplikację do rejestrowania i obsługi zgłoszeń serwisowych. Użytkownicy: pracownik zgłaszający i osoba obsługująca. Potrzebuję tabel dla: zgłoszenie, kategoria, priorytet oraz ekranów: lista zgłoszeń, formularz zgłoszenia, szczegóły zgłoszenia. Zgłoszenie ma mieć co najmniej: tytuł, opis, kategoria, priorytet, status, data utworzenia, zgłaszający.”
  Dlaczego działa: jasno wskazuje domenę, role, minimalny model danych i oczekiwane ekrany.
• Prompt z doprecyzowaniem procesu:
  „Dodaj do aplikacji proces statusów: Nowe → W trakcie → Zakończone. Na liście pokaż priorytet i status. W formularzu status domyślnie Nowe. W widoku szczegółów umożliw zmianę statusu i dodanie komentarza.”
  Dlaczego działa: opisuje prostą logikę, którą Copilot może przełożyć na kolumny, kontrolki i układ.
• Prompt z ograniczeniami i zakresem:
  „Zakres: rejestr i obsługa zgłoszeń wewnętrznych, bez fakturowania i bez modułu magazynowego. Dane przechowuj w Dataverse. Nie twórz integracji na tym etapie.”
  Dlaczego działa: ustawia granice, dzięki czemu Copilot nie rozbudowuje rozwiązania w niepożądanym kierunku.

Jak doprecyzowywać iteracyjnie (bez przepisywania wszystkiego)

Najskuteczniejszy tryb pracy z Copilotem to krótkie iteracje: prosisz o wersję bazową, oglądasz wynik i dopiero wtedy dodajesz kolejne doprecyzowania. W praktyce pomagają trzy typy dopowiedzeń:

• Doprecyzowanie danych: „Dodaj pole X jako wymagane”, „Rozdziel pole ‘adres’ na…”, „Zgłoszenie ma relację do…”.
• Doprecyzowanie UX/ekranów: „Na ekranie listy dodaj filtrowanie po statusie”, „W formularzu ukryj sekcję, gdy…”.
• Doprecyzowanie reguł: „Nie pozwalaj zamknąć zgłoszenia bez…”, „Priorytet domyślny…”.

Czego unikać, żeby Copilot nie „zgadywał”

• Synonimów bez definicji (np. „sprawa”, „zgłoszenie”, „ticket”) używanych zamiennie — wybierz jedno pojęcie.
• Wielu celów w jednym kroku — rozdziel prośby: najpierw tabele i ekrany, potem reguły, potem automatyzacje.
• Wymagań estetycznych bez funkcji — „ładne” zastąp: „lista ma mieć kolumny…”, „formularz ma mieć sekcje…”.
• Niejawnych założeń — jeśli coś jest obowiązkowe (np. unikalność numeru), powiedz to wprost.

Mini-checklista przed wysłaniem promptu

• Jaki jest jeden główny cel aplikacji?
• Kto jej używa i do czego (2–3 role/scenariusze)?
• Jakie są kluczowe dane (minimum pól, które muszą istnieć)?
• Jakie ekrany mają powstać w pierwszej wersji?
• Jakie są 1–3 najważniejsze reguły, które nie mogą być źle zinterpretowane?

Jeśli na te pytania masz odpowiedź w promptcie, Copilot zwykle generuje układ, tabele i formularze, które nadają się do dalszego dopracowania zamiast do zaczynania od zera.

8. Checklist przed generowaniem oraz bezpieczeństwo danych (klasyfikacja, minimalizacja, RLS/DLP, środowiska)

Zanim poprosisz Copilota w Power Platform o wygenerowanie ekranów, tabel lub przepływów, upewnij się, że masz gotową krótką listę kontrolną. Jej celem jest nie tylko poprawa jakości wyniku, ale też ograniczenie ryzyka przypadkowego ujawnienia danych, utrwalenia błędnych założeń w modelu oraz wprowadzenia rozwiązania do niewłaściwego środowiska.

Checklist „minimum przed generowaniem”

• Jednoznaczny kontekst: zdefiniuj, czy budujesz aplikację Canvas czy Model-driven, oraz czy dane mają być w Dataverse czy w innym źródle. To wpływa na to, jak Copilot „myśli” o ekranach, formularzach i tabelach.
• Granice zakresu: wskaż, co ma powstać w pierwszej iteracji (MVP), a co jest poza zakresem. Copilot chętnie „dopowiada” funkcje, jeśli nie ma barier.
• Minimalny model danych: wypisz kluczowe encje i ich podstawowe atrybuty. Bez tego Copilot częściej tworzy zbyt ogólne lub niekompletne tabele.
• Role i dostępy: określ, kto widzi jakie dane i kto może je edytować. To warunkuje sensowność wygenerowanych ekranów (np. ekran „Administracja” vs. „Moje zgłoszenia”).
• Przykładowe rekordy bez danych wrażliwych: podaj przykłady, ale w formie neutralnej (syntetycznej), aby Copilot lepiej dopasował pola i walidacje, nie kopiując realnych danych.
• Wymagania niefunkcjonalne: krótko zaznacz oczekiwania dot. audytu, retencji, zgodności i integracji. Nawet jedno zdanie potrafi uchronić przed błędnymi decyzjami projektowymi.

Klasyfikacja danych: co wolno podawać w promptach

Najczęstszy błąd to wrzucanie do opisu wymagań zbyt szczegółowych danych produkcyjnych. Copilot potrzebuje struktury i reguł, a nie realnych danych osobowych. Dlatego przed generowaniem ustal klasyfikację informacji, z których korzystasz w opisach.

• Dane publiczne: bez ograniczeń, nadal warto zachować precyzję i spójne nazewnictwo.
• Dane wewnętrzne: opisuj proces i strukturę, ale unikaj szczegółów operacyjnych, które mogłyby ujawniać wrażliwe elementy organizacji.
• Dane poufne: nie wklejaj fragmentów eksportów, identyfikatorów, list użytkowników, danych finansowych w szczegółach transakcyjnych.
• Dane wrażliwe / dane osobowe: nie umieszczaj w promptach danych pozwalających zidentyfikować osobę (nawet częściowo), danych medycznych, kadrowych, numerów identyfikacyjnych, danych płatniczych itp. Zastępuj je opisem pola i syntetycznym przykładem (np. „email użytkownika” zamiast realnego adresu).

Minimalizacja danych: mniej danych, lepszy wynik i mniejsze ryzyko

Minimalizacja to zasada: opisujesz tylko to, co jest niezbędne do wygenerowania sensownej struktury. Praktycznie oznacza to trzy rzeczy:

• Ogranicz atrybuty do niezbędnych: jeśli pole nie wpływa na ekran, walidację lub raportowanie, nie dodawaj go na start.
• Nie przenoś historycznych „śmieci”: Copilot nie odróżnia pól „bo kiedyś było potrzebne” od pól krytycznych, jeśli dostanie je w opisie.
• Używaj danych przykładowych syntetycznych: przykłady mają uczyć formatu, nie przenosić realne wartości.

RLS/bezpieczeństwo na poziomie rekordów: od razu zaplanuj, kto widzi co

Bezpieczeństwo rekordów (np. „widzisz tylko swoje zgłoszenia”) powinno być rozstrzygnięte przed generowaniem, bo wpływa na logikę ekranów i filtrów oraz na to, czy potrzebujesz osobnych widoków dla ról. Na tym etapie nie chodzi o konfigurację szczegółową, tylko o decyzje typu:

• Własność danych: rekordy przypisane do użytkownika, zespołu czy jednostki organizacyjnej.
• Zakres widoczności: własne rekordy, rekordy zespołu, cała organizacja, wyjątki (np. rola kontrolna).
• Separacja obszarów: czy te same tabele mają służyć różnym działom, czy potrzebujesz logicznego rozdziału.

DLP (Data Loss Prevention): pilnuj, z czym wolno łączyć dane

Polityki DLP w Power Platform ograniczają, jakie konektory i usługi mogą współdziałać w danym środowisku. To kluczowe, bo Copilot może zasugerować automatyzacje lub integracje, które będą blokowane polityką, albo — jeśli nie zdefiniujesz granic — popchnąć projekt w kierunku niezgodnym z zasadami organizacji.

• Ustal dozwolone źródła danych: czy dane mogą trafiać do poczty, plików, komunikatorów, zewnętrznych API.
• Rozdziel grupy konektorów: podejście „biznesowe” vs. „niebiznesowe” i konsekwencje mieszania danych.
• Wymuś zgodność w opisie: w wymaganiach zaznacz, że integracje mają mieścić się w dopuszczonych konektorach.

Środowiska i cykl życia: gdzie generować i gdzie wdrażać

Generowanie najlepiej wykonywać w środowisku przeznaczonym do budowy i testów, a nie w produkcji. Środowiska porządkują ryzyko i ułatwiają kontrolę dostępu oraz polityki DLP.

• Oddziel dev/test od produkcji: aby uniknąć tworzenia tabel i aplikacji „na żywo” podczas eksperymentów z promptami.
• Dobierz środowisko do danych: jeśli musisz używać danych wrażliwych (co do zasady unikaj), rób to wyłącznie w środowisku o odpowiednich kontrolach i dostępach.
• Ustal właścicieli i zasady dostępu: kto może tworzyć zasoby, kto je zatwierdza, kto publikuje zmiany.

Ostatnie sprawdzenie: higiena promptu i artefaktów

• Usuń dane identyfikujące: nazwy użytkowników, maile, numery, identyfikatory klientów, adresy, dane transakcyjne.
• Sprawdź spójność słownictwa: jedna nazwa dla jednego pojęcia (np. „Zgłoszenie” vs. „Ticket”), aby Copilot nie tworzył duplikatów.
• Zaznacz ograniczenia: „bez danych osobowych w przykładach”, „bez integracji poza dopuszczonymi konektorami”, „z uwzględnieniem dostępu per rola”.
• Zweryfikuj, co powstanie: po generowaniu przejrzyj nazwy tabel i kolumn, domyślne typy danych, relacje i uprawnienia — zanim ktokolwiek zacznie to wykorzystywać.

Dobrze przygotowana checklist i zasady bezpieczeństwa sprawiają, że Copilot generuje rozwiązania bliższe oczekiwaniom, a jednocześnie nie wymusza kompromisów w ochronie danych i zgodności. To szczególnie ważne, gdy generowanie staje się codzienną praktyką zespołu, a nie jednorazowym eksperymentem.

W Cognity łączymy teorię z praktyką – dlatego ten temat rozwijamy także w formie ćwiczeń na szkoleniach.

Copilot w Outlooku i Teams: 11 zasad bezpiecznego streszczania wątków (żeby nie wysłać tajemnicy) 29 marca 2026

Copilot w Excelu 2026: 9 zadań, które dalej robi źle (i jak to obejść formułami) 27 marca 2026