Kategoria: Aplikacje i integracje

Przy każdej integracji pada to samo pytanie: jak połączyć dwa systemy? Odpowiedź rzadko jest kwestią gustu — zwykle wynika z tego, co druga strona w ogóle udostępnia. Poniżej przegląd sposobów wymiany danych i wskazówki, kiedy który wybrać.

REST API — domyślny wybór

Standard w nowoczesnych systemach. Odpytujesz adres, dostajesz JSON, wysyłasz dane tą samą drogą.

• Kiedy: gdy druga strona ma udokumentowane API i potrzebujesz danych na żądanie.
• Zalety: czytelność, dobre wsparcie narzędziowe, łatwa diagnostyka.
• Uwaga na: limity zapytań, stronicowanie wyników i to, że odpytywanie „co minutę na wszelki wypadek” potrafi wyczerpać limit dzienny.

Webhook — gdy liczy się czas reakcji

Odwrócenie kierunku: to system źródłowy powiadamia Cię o zdarzeniu, zamiast czekać na zapytanie.

• Kiedy: płatność zaksięgowana, zamówienie złożone, status przesyłki zmieniony — wszędzie tam, gdzie opóźnienie ma znaczenie.
• Zalety: natychmiastowość i brak zbędnych zapytań.
• Uwaga na: musisz wystawić adres dostępny z internetu, zweryfikować podpis wiadomości i przyjąć, że to samo zdarzenie może przyjść dwa razy.

Webhook wymaga idempotentności. Jeżeli nadawca nie otrzyma potwierdzenia w kilka sekund, ponowi wysyłkę. Bez zabezpieczenia utworzysz drugie zamówienie z tego samego zdarzenia. Zapisuj identyfikator zdarzenia i ignoruj powtórki.

SOAP — starsze systemy i rejestry publiczne

Wyglądem odstrasza, ale bywa jedyną dostępną drogą — zwłaszcza w systemach branżowych i części usług publicznych. Jest ściśle zdefiniowany, co ułatwia walidację, ale jest gadatliwy i mniej wygodny w diagnostyce.

Wymiana plikowa — niedoceniana i często wystarczająca

CSV lub Excel odkładany o ustalonej porze do katalogu, na serwer FTP albo do biblioteki SharePoint.

• Kiedy: system nie ma API, a dane wystarczy wymieniać raz na dobę.
• Zalety: działa praktycznie zawsze, jest tanie i łatwe do podejrzenia — plik można po prostu otworzyć.
• Uwaga na: kodowanie znaków (polskie znaki w plikach CSV to klasyka problemów), format daty i separator dziesiętny, a także rozstrzygnięcie, co zrobić z plikiem, który nie przyszedł.

Nie warto lekceważyć tej drogi. Wiele integracji, które musiały zadziałać „na wczoraj”, ruszyło właśnie tak i pracuje latami.

Bezpośrednio na bazie — ostateczność

Czasem jedyne wyjście, gdy producent nie udostępnia niczego innego.

• Do odczytu: akceptowalne, o ile korzystasz z konta z uprawnieniami wyłącznie do odczytu i najlepiej z repliki.
• Do zapisu: ryzykowne. Omijasz reguły biznesowe aplikacji i możesz naruszyć spójność danych, a producent najpewniej odmówi wsparcia.
• Zawsze: aktualizacja systemu może zmienić strukturę tabel bez ostrzeżenia. Więcej przy integracjach baz danych.

Zestawienie

Sposób	Czas reakcji	Trudność	Typowe zastosowanie
REST	sekundy	niska	Pobieranie i zapis danych na żądanie
Webhook	natychmiast	średnia	Reakcja na zdarzenia
SOAP	sekundy	średnia	Starsze systemy, rejestry
Pliki	godziny	niska	Wymiana wsadowa raz na dobę
Baza	sekundy	wysoka (ryzyko)	Gdy nie ma innej drogi

Pytania, które trzeba zadać przed wyborem

1. Jak szybko dane muszą być po drugiej stronie? Jeżeli wystarczy raz na dobę, nie buduj integracji czasu rzeczywistego.
2. Ile rekordów dziennie? Kilkadziesiąt i kilkaset tysięcy to zupełnie inne rozwiązania.
3. W którą stronę płyną dane? Wymiana dwukierunkowa wymaga rozstrzygnięcia konfliktów — to zwykle najtrudniejsza część.
4. Który system jest źródłem prawdy? Bez tej decyzji integracja prędzej czy później rozjedzie dane.
5. Co się dzieje przy awarii? Dane mają poczekać w kolejce, a ktoś ma się o tym dowiedzieć.
6. Kto to utrzyma? API po drugiej stronie będzie się zmieniać. Integracja bez opieki kiedyś przestanie działać.

Najczęstszy błąd

Budowanie integracji czasu rzeczywistego tam, gdzie wystarczyłby nocny import pliku. Rozwiązanie jest wtedy droższe, bardziej awaryjne i trudniejsze w utrzymaniu — bez realnej korzyści. Zacznij od pytania o wymagany czas reakcji, nie od wyboru technologii.

Excel jest znakomitym narzędziem analitycznym i fatalną bazą danych. Problem w tym, że granica między jednym a drugim zaciera się stopniowo — arkusz „na chwilę” po dwóch latach obsługuje kluczowy proces w firmie. Poniżej sygnały, że ten moment już minął.

Osiem sygnałów ostrzegawczych

1. W nazwie pliku jest data albo słowo „ostateczna”. Zwłaszcza gdy istnieje też wersja „ostateczna_poprawiona”.
2. Ktoś pyta na czacie, czy może już wejść do pliku. Blokada edycji to jasny znak, że narzędzie jest używane wielostanowiskowo, choć nie zostało do tego stworzone.
3. Nie da się ustalić, kto zmienił konkretną wartość. Historia wersji pokazuje plik, nie pojedynczy rekord.
4. Uprawnienia są zerojedynkowe. Albo ktoś widzi cały arkusz, albo nic — nie da się pokazać handlowcowi tylko jego klientów.
5. Formuły odwołują się do innych plików. Wystarczy, że ktoś przeniesie plik, i wszystko się sypie.
6. Plik zaczyna się długo otwierać. Kilkadziesiąt tysięcy wierszy z formułami tablicowymi potrafi zablokować komputer.
7. Dane trzeba przepisywać do innego systemu. Arkusz jest wyspą — nic z niego nie wypływa automatycznie.
8. Boisz się, że ktoś skasuje ten plik. To najlepszy sprawdzian: jeżeli utrata jednego pliku zatrzymałaby proces w firmie, to nie jest arkusz, tylko system.

Dlaczego arkusz nie jest bazą

Czego brakuje	Konsekwencja
Kontroli poprawności danych	W kolumnie „data” pojawia się tekst, w „kwocie” — spacja. Raport przestaje się liczyć.
Relacji między danymi	Nazwa klienta powtórzona w 300 wierszach, w 12 wariantach zapisu.
Jednoczesnej pracy wielu osób	Konflikty wersji albo kolejka do pliku.
Historii zmian na poziomie rekordu	Nie wiadomo, kto, kiedy i dlaczego zmienił wartość.
Uprawnień do fragmentu danych	Wszyscy widzą wszystko albo nikt nic.
Reguł biznesowych	Nic nie blokuje zamówienia bez ceny albo daty z przeszłości.

To nie znaczy, że masz porzucić Excela

Arkusz pozostaje najlepszym narzędziem do analizy doraźnej, prototypowania i jednorazowych zestawień. Chodzi o rozdzielenie ról: dane trzymaj w bazie, analizuj w Excelu. W praktyce oznacza to arkusz podłączony do bazy i odświeżany jednym kliknięciem — z zachowaniem wygody, bez ryzyka.

Ścieżki wyjścia — od najtańszej

1. Uporządkowanie arkusza

Czasem wystarczy: tabele Excela zamiast luźnych zakresów, poprawność danych na kolumnach, usunięcie odwołań do innych plików, przeniesienie na SharePoint ze współautorstwem. Kilka godzin pracy, jeśli skala problemu jest niewielka.

2. Listy SharePoint albo Microsoft Lists

Dobre dla prostych ewidencji i rejestrów: dają uprawnienia, historię zmian, kontrolę typów danych i obieg akceptacji przez Power Automate. Nie wymagają programowania i mieszczą się w posiadanych licencjach Microsoft 365. Przy dużych wolumenach i złożonych relacjach zaczynają jednak uwierać.

3. Prawdziwa baza danych

Gdy danych jest dużo, relacje są złożone albo potrzebne są wydajne raporty — czas na MySQL, PostgreSQL lub MS SQL Server. Migrację z arkuszy opisujemy przy integracjach baz danych. Nad bazą stawia się warstwę raportową, na przykład w Power BI.

4. Aplikacja webowa

Gdy z danych korzysta wiele osób, obowiązują reguły biznesowe albo dostęp mają mieć także klienci. Formularze zamiast komórek, uprawnienia w podziale na role, historia zmian, integracje z innymi systemami. Więcej przy budowie aplikacji webowych.

Jak przeprowadzić migrację bezpiecznie

1. Zamroź strukturę. Ustal, że do zakończenia migracji nikt nie dokłada kolumn.
2. Wyczyść dane u źródła. Ujednolić zapis nazw, usuń duplikaty, popraw formaty dat. Przeniesienie bałaganu do bazy niczego nie naprawi.
3. Uruchom równolegle. Przez kilka tygodni nowe rozwiązanie działa obok arkusza — to jedyny sposób, by wyłapać przypadki, o których nikt nie wspomniał.
4. Porównaj wyniki. Ten sam raport z obu źródeł musi dawać te same liczby.
5. Zachowaj arkusz w trybie tylko do odczytu jako materiał historyczny.

Najczęstszy błąd: odwzorowanie arkusza jeden do jednego w nowym narzędziu. Arkusz ma strukturę wynikającą z ograniczeń Excela, a nie z logiki procesu. Migracja to dobry moment, żeby zapytać, jak ten proces powinien wyglądać.

Kiedy zostawić jak jest

Jeżeli z arkusza korzysta jedna osoba, dane nie są krytyczne, a plik ma kopię zapasową — nie ma czego naprawiać. Migracja kosztuje czas i pieniądze; robi się ją wtedy, gdy ryzyko utraty danych albo koszt ręcznej pracy przewyższa koszt zmiany.

Power Automate jest w większości planów Microsoft 365, których firmy już używają — i w większości firm leży nietknięty. Poniżej pięć automatyzacji, które wdrażamy najczęściej, bo zwracają się najszybciej i nie wymagają programowania.

1. Obieg akceptacji faktur i wniosków

Problem: faktura krąży mailem, ktoś zapomina odpowiedzieć, po tygodniu nikt nie wie, u kogo utknęła.

Rozwiązanie: dokument trafia do biblioteki SharePoint, przepływ wysyła prośbę o akceptację do właściwej osoby, przypomina po dwóch dniach, a po akceptacji przenosi plik do folderu zatwierdzonych i powiadamia księgowość. Wszystko z historią: kto, kiedy, jaka decyzja.

Co zyskujesz: koniec z pytaniem „na jakim to jest etapie” i komplet dowodów przy kontroli.

Ta sama mechanika działa dla

• wniosków urlopowych i delegacji,
• zamówień powyżej ustalonej kwoty,
• akceptacji umów i ofert przed wysłaniem do klienta.

2. Załączniki z poczty prosto do właściwego folderu

Problem: zamówienia, protokoły i skany przychodzą mailem, a ktoś ręcznie zapisuje je na dysku — albo zapomina.

Rozwiązanie: przepływ obserwuje skrzynkę współdzieloną i zapisuje załączniki do biblioteki SharePoint, nadając nazwę według daty i nadawcy. Można rozdzielać po temacie wiadomości albo po adresie nadawcy.

Co zyskujesz: dokumenty są w jednym miejscu, dostępne dla całego zespołu i objęte kopiami zapasowymi — a nie w skrzynce jednej osoby.

3. Onboarding nowego pracownika

Problem: przy każdym przyjęciu ktoś odtwarza z pamięci listę czynności. Za każdym razem czegoś brakuje.

Rozwiązanie: formularz uruchamia przepływ, który zakłada konto, przypisuje licencję, dodaje do właściwych grup i zespołów, tworzy zadania dla przełożonego oraz dla osoby odpowiedzialnej za sprzęt, a na koniec wysyła pracownikowi wiadomość powitalną z instrukcjami.

Co zyskujesz: powtarzalność. Nowa osoba pierwszego dnia ma wszystko, czego potrzebuje. Odwrotność tego procesu opisaliśmy przy offboardingu w Microsoft 365.

4. Przypomnienia o terminach

Problem: umowy, gwarancje, przeglądy, certyfikaty i odnowienia licencji wygasają niezauważone.

Rozwiązanie: lista SharePoint z datami i przepływ sprawdzający ją codziennie. Na 60, 30 i 7 dni przed terminem wysyła powiadomienie do osoby odpowiedzialnej i do przełożonego.

Co zyskujesz: najtańsza automatyzacja z całej listy, a potrafi uchronić przed najbardziej kosztownym przeoczeniem.

5. Powiadomienia z systemów zewnętrznych

Problem: ważne zdarzenia — nowe zgłoszenie, przekroczony limit, awaria — trafiają do skrzynki, w której giną.

Rozwiązanie: przepływ odbiera zdarzenie przez webhook lub odpytuje API systemu i publikuje sformatowaną wiadomość na kanale Teams właściwego zespołu, z przyciskiem przenoszącym do sprawy.

Co zyskujesz: informacja dociera tam, gdzie ludzie faktycznie patrzą.

Czego nie automatyzować

Automatyzacja procesu, który jest źle zaprojektowany, daje szybko wykonywany bałagan. Zanim zbudujesz przepływ, sprawdź, czy niektórych kroków nie da się po prostu usunąć. Najlepsza automatyzacja to ta, która okazuje się niepotrzebna, bo proces dało się uprościć.

• Procesy zmieniające się co miesiąc — utrzymanie pochłonie więcej czasu, niż zaoszczędzisz.
• Zadania wykonywane raz na kwartał — chyba że są krytyczne i łatwe do pomylenia.
• Decyzje wymagające oceny — automatyzuj przepływ informacji i przypomnienia, nie sam osąd.

O czym pamiętać przy wdrożeniu

• Właściciel przepływu. Przepływ utworzony na koncie pracownika przestaje działać po jego odejściu. Buduj na koncie technicznym lub w rozwiązaniu współdzielonym.
• Obsługa błędów. Domyślnie przepływ po prostu przestaje działać, a mail o niepowodzeniu trafia do właściciela — czyli często donikąd. Ustaw powiadomienie do zespołu.
• Limity wywołań. Plany różnią się liczbą uruchomień. Przy dużych wolumenach sprawdź to przed wdrożeniem.
• Uprawnienia połączeń. Przepływ działa z uprawnieniami konta, na którym utworzono połączenie — nie z uprawnieniami osoby, która go uruchomiła.
• Dokumentacja. Po roku nikt nie pamięta, dlaczego przepływ robi ten dziwny krok. Krótki opis w nazwie i komentarzach oszczędza godziny.

Od czego zacząć

Wybierz jedno zadanie, które ktoś w firmie wykonuje codziennie, ręcznie i według stałych reguł. Zmierz, ile zajmuje w miesiącu. Zbuduj dla niego przepływ i po miesiącu porównaj. Ta jedna liczba przekona zarząd lepiej niż jakakolwiek prezentacja — i pokaże, czy warto iść dalej w stronę szerszej automatyzacji.

Najczęstszy powód, dla którego wdrożenie Copilota kończy się awanturą, nie ma nic wspólnego ze sztuczną inteligencją. Copilot widzi dokładnie to, co widzi zalogowany pracownik — i pokazuje mu to szybciej, niż ktokolwiek się spodziewał. Jeżeli uprawnienia w SharePoint narastały latami, Copilot je ujawni.

Mechanizm jest prosty i nieubłagany

Copilot nie omija uprawnień. Przeszukuje zasoby, do których użytkownik i tak ma dostęp, i podaje odpowiedź. Różnica polega na tym, że wcześniej trzeba było wiedzieć, czego szukać i gdzie. Teraz wystarczy zapytać po polsku.

Pracownik nie znajdzie folderu „Kadry 2025”, bo nie przyszłoby mu do głowy tam zaglądać. Ale zapyta: „jakie są widełki wynagrodzeń na stanowisku handlowca?” — i jeśli dokument jest dla niego technicznie dostępny, dostanie odpowiedź. Wraz z odnośnikiem do źródła.

Skąd biorą się nadmiarowe uprawnienia

• Linki „dla wszystkich w organizacji”. Domyślna opcja przy udostępnianiu w wielu dzierżawach. Szybka, wygodna i klikana bez zastanowienia.
• Dziedziczenie z korzenia witryny. Ktoś nadał dostęp do witryny nadrzędnej, a wszystkie biblioteki pod nią odziedziczyły uprawnienia.
• Zespoły Teams zakładane bez kontroli. Każdy zespół to witryna SharePoint. Zespół „Projekt X” z 2022 roku nadal istnieje wraz z zawartością.
• Byli pracownicy i goście. Konta gości z dawnych projektów, którym nikt nie odebrał dostępu.
• Dokumenty w OneDrive udostępnione szeroko, bo tak było prościej niż zakładać wspólną bibliotekę.
• Grupy zagnieżdżone. Grupa A należy do grupy B, która ma dostęp do wrażliwego zasobu. Nikt tego nie prześledzi ręcznie.

Żadna z tych rzeczy nie jest błędem konkretnej osoby. To naturalny efekt kilku lat pracy w organizacji, w której nikt nie odpowiadał za porządek w dostępach.

Co sprawdzić przed włączeniem Copilota

1. Zinwentaryzuj szerokie udostępnienia

Zacznij od raportu linków typu „każdy” i „wszyscy w organizacji”. Interesują Cię zwłaszcza biblioteki zawierające dane kadrowe, finansowe, prawne i handlowe. Takie zestawienie wygodnie pobrać przez Microsoft Graph API — ręczne klikanie po witrynach nie ma sensu przy większej liczbie zespołów.

2. Znajdź zasoby bez właściciela

Zespoły i witryny bez aktywnego właściciela to obszary, których nikt nie pilnuje. Wyznacz właścicieli albo zarchiwizuj i odetnij dostęp.

3. Przejrzyj konta gości

Goście z zakończonych projektów, konta bez logowania od pół roku, dostęp przyznany „na chwilę”. Wyłączenie ich jest szybkie i od razu zmniejsza obszar ryzyka.

4. Wskaż obszary wyłączone

Zdecyduj z zarządem, czego Copilot nie ma przeszukiwać: kadry, wynagrodzenia, dokumentacja prawna, dane szczególnie chronione. Realizuje się to etykietami poufności i ograniczeniem zakresu wyszukiwania.

5. Uporządkuj dane martwe

Kopie dokumentów sprzed lat, wersje robocze, pliki nazwane „ostateczna_v3_poprawki”. Copilot potraktuje je jako źródło i będzie na ich podstawie odpowiadać. Śmieci na wejściu to śmieci na wyjściu — z tą różnicą, że teraz brzmią wiarygodnie.

Kolejność ma znaczenie. Porządkowanie uprawnień po włączeniu Copilota jest znacznie trudniejsze niż przed. Gdy pracownicy zobaczą już dane, których nie powinni widzieć, sprawa przestaje być techniczna, a zaczyna być kadrowa.

Ile to trwa

W firmie do stu użytkowników przegląd i uporządkowanie uprawnień to zwykle od kilku dni do dwóch tygodni. W organizacjach, które używają SharePoint od lat bez żadnych zasad, bywa dłużej. To jednak praca, którą i tak trzeba wykonać — Copilot jedynie sprawia, że nie da się jej dłużej odkładać.

Efekt uboczny jest pozytywny

Firmy, które przechodzą ten przegląd, zwykle wynoszą z niego więcej niż gotowość na Copilota:

• wiedzą wreszcie, kto ma dostęp do czego,
• mają zamknięte konta byłych pracowników i gości,
• ograniczyły skutki ewentualnego przejęcia jednego konta — bo przejęte konto nie otwiera już całej firmy,
• mają materiał na potrzeby audytu bezpieczeństwa i wymagań RODO.

To są korzyści niezależne od tego, czy ostatecznie kupisz licencje Copilot.

Uwaga na koniec

Uporządkowane uprawnienia nie zwalniają z pozostałych zabezpieczeń. Copilot działa na koncie użytkownika, więc przejęte konto to przejęty Copilot — z wygodną wyszukiwarką po firmowych danych w komplecie. Uwierzytelnianie wieloskładnikowe, o którym pisaliśmy przy wdrożeniu MFA, jest tu warunkiem wstępnym, nie dodatkiem.

Zakładanie kont, przypisywanie licencji, porządkowanie skrzynek, raporty wykorzystania — większość powtarzalnej pracy administratora Microsoft 365 da się wykonać automatycznie przez Microsoft Graph API. Poniżej praktyczne wprowadzenie: jak się połączyć, od czego zacząć i na czym najłatwiej się potknąć.

Czym właściwie jest Graph

Microsoft Graph to jeden wspólny interfejs do danych z całego Microsoft 365. Zamiast osobnych narzędzi do Exchange, SharePoint, Teams i tożsamości, odpytujesz jeden adres i dostajesz JSON. Wszystko sprowadza się do wywołań w rodzaju:

GET  https://graph.microsoft.com/v1.0/users
GET  https://graph.microsoft.com/v1.0/users/jan.kowalski@firma.pl
POST https://graph.microsoft.com/v1.0/groups/{id}/members/$ref

Istnieją dwie wersje: v1.0 — stabilna, do zastosowań produkcyjnych, oraz beta — bogatsza, ale Microsoft może ją zmienić bez uprzedzenia. W skryptach, od których zależy praca firmy, trzymaj się v1.0.

Jak się uwierzytelnić

To miejsce, w którym najczęściej rodzi się zamieszanie. Są dwa modele:

Model	Kiedy stosować
Delegowany (w imieniu użytkownika)	Skrypt działa z uprawnieniami zalogowanej osoby. Do narzędzi uruchamianych ręcznie przez administratora.
Aplikacyjny (bez użytkownika)	Zadania w tle, harmonogramy, integracje serwerowe. Aplikacja ma własne uprawnienia, niezależne od kogokolwiek.

Do automatyzacji niemal zawsze chcesz modelu aplikacyjnego. Rejestrujesz aplikację w Microsoft Entra ID, nadajesz jej uprawnienia typu Application, zatwierdzasz je jako administrator i uwierzytelniasz się identyfikatorem dzierżawy, identyfikatorem aplikacji oraz sekretem lub certyfikatem.

Używaj certyfikatu zamiast sekretu. Sekret ma datę ważności i wygasa zwykle w najmniej dogodnym momencie — najczęściej w nocy, gdy przestaje działać synchronizacja, o której wszyscy zapomnieli. Certyfikat też wygasa, ale łatwiej objąć go kontrolą i rotacją. Niezależnie od wyboru: wpisz datę ważności do kalendarza w dniu, w którym tworzysz poświadczenie.

Zasada najmniejszych uprawnień

Przy nadawaniu uprawnień pokusa jest oczywista: zaznaczyć Directory.ReadWrite.All i mieć spokój. To zły pomysł — taka aplikacja może praktycznie wszystko w Twojej dzierżawie, a jej sekret leży w pliku konfiguracyjnym na serwerze.

• Potrzebujesz czytać listę użytkowników? User.Read.All, nie User.ReadWrite.All.
• Potrzebujesz jednej skrzynki? Ogranicz zakres dostępu do konkretnych skrzynek, zamiast dawać dostęp do wszystkich.
• Osobna rejestracja aplikacji dla każdej integracji — wtedy wyłączenie jednej nie kładzie pozostałych.

Od czego zacząć w praktyce

1. Raport wykorzystania licencji

Najprostszy start i od razu wymierna korzyść. Pobierasz listę użytkowników wraz z przypisanymi licencjami i datą ostatniego logowania. Wynik regularnie ujawnia licencje przypisane osobom, które nie zalogowały się od miesięcy — więcej o optymalizacji planów przy porównaniu planów Microsoft 365.

2. Onboarding pracownika

Jedno wywołanie tworzy konto, kolejne przypisuje licencję, następne dodaje do grup i zespołów. Zamiast dziesięciu kliknięć w kilku panelach — jeden skrypt z listą parametrów, wykonujący za każdym razem dokładnie to samo.

3. Offboarding

Zablokowanie logowania, unieważnienie sesji, konwersja skrzynki na współdzieloną, przekazanie plików z OneDrive, zwolnienie licencji. Procedurę opisaliśmy krok po kroku przy offboardingu w Microsoft 365 — Graph pozwala wykonać ją bezbłędnie i w tej samej kolejności za każdym razem.

4. Porządek w danych

Wyszukiwanie plików udostępnionych „wszystkim w organizacji”, list gości bez aktywności, zespołów Teams bez właściciela. To rzeczy, których nie widać w codziennej pracy, a które wychodzą boleśnie przy wdrożeniu Copilota — piszemy o tym w tekście o uprawnieniach przed wdrożeniem Copilota.

Pułapki, na które warto uważać

• Stronicowanie. Graph zwraca wyniki partiami. Jeżeli zignorujesz pole @odata.nextLink, dostaniesz pierwszych 100 rekordów i uznasz, że to wszystko. Klasyczne źródło raportów, które „się nie zgadzają”.
• Limity zapytań. Przy większej liczbie wywołań Graph zwróci kod 429 wraz z nagłówkiem Retry-After. Trzeba go uszanować i ponowić po wskazanym czasie, a nie odpytywać w pętli.
• Opóźnienie propagacji. Konto utworzone przed sekundą bywa jeszcze niewidoczne dla kolejnego wywołania. W skryptach onboardingowych planuj ponowienia.
• Uprawnienia delegowane a aplikacyjne. Ten sam endpoint zachowuje się inaczej w obu modelach. Większość błędów 403 bierze się z pomylenia typu uprawnienia, nie z jego braku.
• Filtrowanie po stronie serwera. Część zapytań wymaga nagłówka ConsistencyLevel: eventual wraz z parametrem $count. Bez tego filtr po prostu nie zadziała.

PowerShell czy własny kod

Moduły Microsoft Graph PowerShell wystarczą do zadań administracyjnych i raportów — są szybkie w napisaniu i czytelne dla kolejnej osoby. Gdy automatyzacja ma działać w tle, obsługiwać błędy, ponawiać i raportować, lepiej sprawdza się osobna usługa. My budujemy takie rozwiązania w Node.js z TypeScript — na tym stosie działa nasz portal B2B, korzystający z uwierzytelniania Entra ID.

Zanim wypuścisz to na produkcję

1. Przetestuj na osobnej dzierżawie testowej albo na koncie, którego skasowanie nikogo nie zaboli.
2. Operacje zapisujące uruchom najpierw w trybie „tylko podgląd”, wypisując, co skrypt zamierza zrobić.
3. Zapisuj logi — co, kiedy i z jakim skutkiem. Bez tego diagnoza po tygodniu jest niemożliwa.
4. Ustaw powiadomienie o niepowodzeniu. Cicho zepsuta automatyzacja jest gorsza od jej braku.
5. Wpisz do kalendarza datę wygaśnięcia poświadczeń.