Jak działa integracja z Microsoft SharePoint?

SharePoint może stać się centralnym repozytorium dokumentów dla innych aplikacji. Integracja przez Microsoft Graph pozwala automatycznie tworzyć foldery, przesyłać pliki, odczytywać zmiany i kontrolować dostęp.

Microsoft SharePoint jest często kojarzony z miejscem, w którym pracownicy przechowują pliki Word, Excel, PDF czy dokumentację projektową.

Jego możliwości są jednak znacznie większe.

SharePoint Online może pełnić rolę centralnego repozytorium dokumentów, z którego korzystają jednocześnie:

Dzięki integracji użytkownik nie musi pobierać dokumentu z jednego programu, zapisywać go na komputerze i ręcznie przesyłać do SharePoint.

System może zrobić to automatycznie.

Przykładowo po podpisaniu umowy aplikacja CRM może utworzyć w SharePoint odpowiedni katalog klienta, przesłać do niego PDF, dodać metadane i zapisać link do dokumentu przy kontrahencie.

To właśnie jest integracja.

Czym właściwie jest integracja z Microsoft SharePoint?

Najprościej:

aplikacja uzyskuje kontrolowany dostęp do zasobów SharePoint i wykonuje na nich operacje automatycznie.

W zależności od potrzeb może:

W SharePoint Online jednym z podstawowych sposobów realizowania takich integracji jest Microsoft Graph API. Microsoft Graph udostępnia dostęp m.in. do witryn SharePoint, list oraz bibliotek dokumentów, a dla elementów list i plików dostępne są operacje odczytu i zapisu.

SharePoint, witryna, biblioteka, folder – jak to rozumieć?

Żeby zrozumieć integrację, warto najpierw uporządkować strukturę.

Można ją uprościć do schematu:

Microsoft 365 → SharePoint → witryna → biblioteka dokumentów → folder → plik

Przykład:

Firma ABC

→ witryna „Sprzedaż”

→ biblioteka „Umowy”

→ folder „Klient XYZ”

→ plik „Umowa-2026.pdf”.

Dla użytkownika jest to zwykła struktura katalogów.

Dla integracji poszczególne elementy posiadają jednak własne identyfikatory.

Microsoft Graph reprezentuje pliki i foldery SharePoint jako zasoby typu driveItem. Element można wskazywać zarówno za pomocą jego identyfikatora, jak i ścieżki.

Czym jest „drive” w Microsoft Graph?

To określenie może być mylące.

Biblioteka dokumentów SharePoint jest w Microsoft Graph reprezentowana jako drive.

Dlatego integracja może operować przykładowo na:

W praktyce po pierwszym połączeniu system może zapamiętać te identyfikatory i później używać ich przy kolejnych operacjach.

Nie musi za każdym razem wyszukiwać biblioteki od początku.

Jak działa integracja krok po kroku?

Prześledźmy typowy proces.

Firma posiada własny system CRM.

Chce, aby każda umowa klienta trafiała automatycznie do SharePoint.

Krok 1. Administrator łączy Microsoft 365 z aplikacją

Administrator wybiera w systemie:

Połącz z Microsoft SharePoint.

Następuje proces autoryzacji Microsoft.

System uzyskuje odpowiednie uprawnienia.

Krok 2. Wybierana jest lokalizacja dokumentów

Administrator może wskazać:

Przykład:

SharePoint → Sprzedaż → Umowy klientów

Od tej chwili aplikacja wie, gdzie przechowywać dokumenty.

Krok 3. Powstaje nowy klient

CRM tworzy klienta:

ABC Sp. z o.o.

System może automatycznie utworzyć:

/Umowy klientów/ABC Sp. z o.o./

Krok 4. Powstaje dokument

Handlowiec generuje umowę.

CRM tworzy PDF.

Zamiast zapisywać go wyłącznie we własnym systemie, aplikacja wysyła plik do SharePoint przez API.

Krok 5. SharePoint zapisuje dokument

Powstaje:

/Umowy klientów/ABC Sp. z o.o./Umowa-2026-001.pdf

Krok 6. CRM zapisuje identyfikator dokumentu

To bardzo ważne.

System nie powinien zapamiętywać wyłącznie nazwy pliku.

Lepiej zapisać również identyfikator SharePoint.

Dzięki temu, nawet jeżeli ktoś zmieni nazwę dokumentu albo przeniesie go w obrębie obsługiwanego procesu, łatwiej zachować poprawne powiązanie.

Krok 7. Użytkownik otwiera dokument

Przy kliencie w CRM może pojawić się:

Umowa 2026-001 – Otwórz w SharePoint

Użytkownik jednym kliknięciem przechodzi do dokumentu.

Nie musi przeszukiwać katalogów.

Microsoft Graph – podstawa nowoczesnej integracji

Microsoft Graph jest wspólnym API dla wielu usług Microsoft 365.

Dzięki temu ta sama aplikacja może potencjalnie współpracować nie tylko z SharePoint, ale również z innymi usługami Microsoft.

W przypadku SharePoint Graph obsługuje podstawowe obiekty takie jak:

SharePoint API dostępne przez Graph umożliwia pracę z witrynami, listami oraz bibliotekami dokumentów.

Daje to ogromne możliwości.

Integracja nie musi ograniczać się do przesłania PDF.

Co można zrobić z plikami przez integrację?

Przesyłać dokumenty

Najbardziej oczywista funkcja.

System generuje:

a następnie automatycznie zapisuje dokument w odpowiedniej bibliotece.

Microsoft Graph udostępnia operacje pozwalające przesyłać zawartość plików do bibliotek SharePoint.

Pobierać dokumenty

Integracja może działać również w drugą stronę.

Użytkownik otwiera dokument w systemie, ale faktyczny plik znajduje się w SharePoint.

Aplikacja pobiera jego zawartość dopiero wtedy, gdy jest potrzebna. Microsoft Graph udostępnia możliwość pobierania zawartości plików z bibliotek SharePoint.

Tworzyć foldery

Przykładowa automatyczna struktura:

Klienci

→ ABC Sp. z o.o.

→ Umowy

→ Faktury

→ Projekty

→ Korespondencja.

Folder może zostać utworzony automatycznie przy dodaniu kontrahenta.

Zmieniać nazwy

Przykład:

plik:

scan00001.pdf

po przetworzeniu dokumentu zostaje zmieniony na:

Umowa-ABC-2026-04.pdf

Przenosić dokumenty

Dokument może przechodzić przez kolejne etapy:

Robocze → Do akceptacji → Zatwierdzone → Archiwum

Nie zawsze jednak foldery są najlepszym sposobem odwzorowania procesu.

W wielu przypadkach lepsze są metadane.

SharePoint to nie tylko foldery

To jeden z najważniejszych elementów, który odróżnia SharePoint od zwykłego dysku sieciowego.

Dokument może posiadać dodatkowe informacje.

Przykład:

Umowa.pdf

Metadane:

Dzięki temu dokument można później znaleźć nie tylko po nazwie katalogu.

Można go filtrować i klasyfikować według danych biznesowych.

Folder czy metadane?

Wyobraźmy sobie strukturę:

Klienci/2026/Polska/Warszawa/ABC/Umowy/Podpisane

Po kilku latach taki system może stać się trudny do utrzymania.

Alternatywą jest prostsza biblioteka:

Umowy

a każdy dokument posiada pola:

Integracja może automatycznie uzupełniać te informacje.

Integracja z listami SharePoint

Microsoft SharePoint posiada również listy.

Można je traktować jako uporządkowane zbiory danych przypominające tabelę.

Przykładowa lista:

Integracja może:

Microsoft Graph obsługuje operacje odczytu i zapisu dla listItems, dlatego SharePoint może pełnić nie tylko funkcję repozytorium plików, ale również prostego źródła uporządkowanych danych.

Czy SharePoint przechowuje historię dokumentów?

Tak.

Jedną z dużych zalet SharePoint jest wersjonowanie.

Po zmianie pliku może powstać kolejna wersja, dzięki czemu możliwe jest:

Microsoft wskazuje, że wersjonowanie pozwala przechowywać, śledzić i przywracać wcześniejsze elementy list oraz pliki bibliotek. W Microsoft 365 wersjonowanie jest standardowym mechanizmem bibliotek dokumentów.

To ogromna różnica w porównaniu z integracją polegającą na prostym kopiowaniu dokumentów do katalogu FTP.

Przykład

W SharePoint znajduje się:

Oferta-ABC.docx

Handlowiec zmienia cenę.

Powstaje kolejna wersja.

Później okazuje się, że zmiana była błędna.

Poprzednia wersja może nadal znajdować się w historii.

Nie trzeba tworzyć plików:

oferta_final.docx

oferta_final2.docx

oferta_final_poprawiona.docx

oferta_final_OSTATECZNA.docx

SharePoint pozwala również na współpracę nad dokumentem

Dokumenty znajdujące się w SharePoint mogą być współtworzone przez kilka osób, zależnie od typu pliku, aplikacji i konfiguracji biblioteki.

Microsoft zwraca przy tym uwagę, że wymaganie wyewidencjonowania dokumentu blokuje współtworzenie, dlatego przy zespołowej edycji konfiguracja biblioteki ma znaczenie.

Integracja z zewnętrznym systemem nie powinna więc bez potrzeby tworzyć lokalnych kopii dokumentów.

Lepiej, aby system prowadził użytkownika do jednego źródła prawdy.

Jedna kopia dokumentu zamiast pięciu

To jeden z najważniejszych powodów wdrażania integracji.

Bez integracji może wyglądać to tak:

Powstaje kilka wersji tego samego dokumentu.

Która jest aktualna?

Nie wiadomo.

Po integracji można zastosować model:

CRM przechowuje dane i link → SharePoint przechowuje właściwy dokument.

Wtedy istnieje jedno główne repozytorium.

Jak działa logowanie do SharePoint przez API?

Nowoczesnej integracji nie powinno się budować poprzez przechowywanie loginu i hasła użytkownika Microsoft 365.

Do autoryzacji wykorzystywany jest Microsoft Entra ID.

W uproszczeniu:

Dzięki temu dostęp można:

Dwa podstawowe modele uprawnień

Dostęp w imieniu użytkownika

To tzw. delegated permissions.

Użytkownik jest zalogowany.

Aplikacja wykonuje operację w kontekście jego konta.

Przykład:

pracownik klika:

Dodaj dokument z SharePoint

i widzi pliki, do których sam ma odpowiedni dostęp.

To naturalny model w aplikacji interaktywnej.

Dostęp aplikacji bez zalogowanego użytkownika

To application permissions, często nazywane app-only.

Przydaje się w automatyzacji.

Przykład:

o godzinie 2:00 system:

mimo że żaden pracownik nie jest zalogowany.

W SharePoint Online Microsoft wskazuje obecnie integrację opartą o aplikację Microsoft Entra ID jako preferowany model dostępu aplikacyjnego.

Ważna zmiana w 2026 roku – stare integracje Azure ACS

To szczególnie istotne przy czytaniu starszych poradników dotyczących SharePoint.

W internecie nadal można znaleźć instrukcje wykorzystujące:

Ten model jest przestarzały.

Microsoft wycofał SharePoint Azure ACS App-Only, a możliwość korzystania z tego mechanizmu w SharePoint Online została zakończona 2 kwietnia 2026 r.. Dla nowych integracji Microsoft zaleca model oparty na Microsoft Entra ID.

W sierpniu 2026 r. nowej integracji z SharePoint Online zdecydowanie nie warto więc projektować na podstawie starej dokumentacji ACS.

Jakie uprawnienia nadać integracji?

Tu łatwo popełnić bardzo poważny błąd.

Aplikacja ma zapisywać faktury do jednej biblioteki.

Programista nadaje:

pełny dostęp do całego SharePoint firmy.

Technicznie działa.

Bezpieczeństwo jest jednak znacznie gorsze, niż powinno.

Dobrą zasadą jest:

integracja powinna otrzymać najmniejsze uprawnienia niezbędne do działania.

Microsoft Graph rozróżnia między innymi szerokie uprawnienia typu Sites.ReadWrite.All oraz ograniczone modele typu Sites.Selected, pozwalające udostępnić aplikacji tylko wybrane witryny.

Sites.Selected – bardzo ważna opcja dla integracji firmowych

Wyobraźmy sobie, że organizacja posiada:

System CRM potrzebuje wyłącznie:

SharePoint Klienci.

Nie ma powodu, aby otrzymywał dostęp do:

Uprawnienie Sites.Selected umożliwia ograniczenie aplikacji do wybranych witryn SharePoint. Po samym nadaniu zakresu aplikacja nie otrzymuje automatycznie dostępu do wszystkich witryn – trzeba wskazać konkretne zasoby.

To znacznie bezpieczniejszy model w wielu integracjach serwerowych.

Czy można ograniczyć dostęp jeszcze bardziej?

Tak.

Ekosystem Microsoft Graph obsługuje również bardziej szczegółowe „Selected permissions”, pozwalające ograniczać integrację np. do wybranych:

Microsoft dokumentuje obecnie m.in.:

Nie każda integracja musi korzystać z maksymalnie szczegółowego modelu, ale zasada pozostaje taka sama:

nie dawaj całego SharePoint aplikacji, która potrzebuje jednego katalogu.

Synchronizacja jednokierunkowa czy dwukierunkowa?

To jedna z pierwszych decyzji projektowych.

Synchronizacja jednokierunkowa

Przykład:

CRM → SharePoint

CRM jest źródłem danych.

Po utworzeniu dokumentu przesyła go do SharePoint.

Zmiany dokonane ręcznie w SharePoint nie wracają do CRM.

To najprostszy model.

Dobrze sprawdza się przy:

Synchronizacja dwukierunkowa

Przykład:

CRM ↔ SharePoint

Zmiana po jednej stronie może wpływać na drugą.

Przykładowo:

To daje znacznie większe możliwości, ale wymaga rozwiązania dodatkowych problemów.

Najtrudniejszy problem dwukierunkowej synchronizacji – konflikt

Załóżmy:

o 10:00 użytkownik edytuje dokument w CRM.

W tym samym czasie druga osoba edytuje go bezpośrednio w SharePoint.

Która wersja jest prawidłowa?

Integracja musi mieć ustalone zasady.

Możliwe strategie:

Bez takiej reguły dwukierunkowa synchronizacja może sama generować problemy.

Jak system dowiaduje się, że plik zmienił się w SharePoint?

Można zastosować kilka mechanizmów.

Okresowe sprawdzanie

Aplikacja np. co godzinę pyta:

Czy coś się zmieniło?

Jest to proste, ale przy dużej liczbie plików może być nieefektywne.

Delta API

Microsoft Graph udostępnia mechanizm delta.

Pozwala on pobierać zmiany, które wystąpiły od poprzedniej synchronizacji.

Po pełnym odczycie system otrzymuje deltaLink.

Przy następnym uruchomieniu nie musi ponownie analizować całej biblioteki.

Pyta:

Co zmieniło się od mojego ostatniego punktu synchronizacji?

Microsoft dokumentuje mechanizm driveItem: delta jako sposób śledzenia zmian plików i folderów w czasie.

To bardzo dobre rozwiązanie przy synchronizacji dużych bibliotek.

Webhook – SharePoint może poinformować system o zmianie

Jeszcze inny model polega na powiadomieniach.

System rejestruje subskrypcję.

Kiedy pojawia się zmiana, Microsoft Graph wysyła powiadomienie do przygotowanego endpointu HTTPS aplikacji.

Dzięki temu system nie musi co kilka minut pytać Microsoft:

„Czy coś nowego?”

Microsoft Graph obsługuje change notifications poprzez webhooki. Endpoint odbiorcy musi być publicznie dostępny przez HTTPS, a subskrypcje wymagają obsługi ich cyklu życia i odnawiania.

Webhook + delta to bardzo dobre połączenie

Praktyczny model może wyglądać tak:

Dzięki temu system jest szybki, ale jednocześnie nie musi polegać wyłącznie na danych znajdujących się w samym powiadomieniu.

Co jeśli webhook nie dotrze?

Dobrze zaprojektowana integracja nie powinna zakładać, że każde zewnętrzne powiadomienie zawsze dotrze.

Microsoft ostrzega, że niewłaściwie działający lub zbyt wolno odpowiadający endpoint może prowadzić do problemów z dostarczaniem powiadomień.

Dlatego bezpieczny model może obejmować również okresową kontrolę delta.

Webhook przyspiesza reakcję.

Delta zapewnia możliwość odtworzenia stanu zmian.

Co z dużymi plikami?

Nie każdy dokument powinien być wysyłany jednym prostym żądaniem.

Dla większych plików Microsoft Graph udostępnia upload sessions, czyli mechanizm przesyłania pliku w częściach.

Dzięki temu chwilowe przerwanie połączenia nie musi oznaczać ponownego rozpoczynania całego transferu.

Ma to znaczenie przy:

Czy integracja może zarządzać uprawnieniami do dokumentów?

Tak.

Microsoft Graph pozwala również odczytywać i w określonych scenariuszach tworzyć uprawnienia dotyczące plików.

Przykład:

po utworzeniu projektu system może:

Trzeba jednak uważać.

Nadmierne tworzenie indywidualnych uprawnień dla każdego pojedynczego pliku może znacząco komplikować administrację.

W wielu przypadkach lepiej oprzeć bezpieczeństwo na:

zamiast tworzyć setki wyjątków na poziomie pojedynczych dokumentów.

Uprawnienia użytkownika a uprawnienia aplikacji

To dwa różne poziomy.

Załóżmy, że pracownik nie ma dostępu do folderu:

Zarząd.

Jeżeli integracja działa w kontekście użytkownika, naturalne może być respektowanie jego uprawnień.

Jeżeli jednak backend posiada szerokie uprawnienia aplikacyjne, technicznie może mieć dostęp do znacznie większej ilości danych.

Dlatego architektura bezpieczeństwa musi być świadomą decyzją.

Nie należy zakładać:

„Skoro użytkownik tego nie widzi w SharePoint, nasza aplikacja też na pewno tego nie może odczytać.”

To zależy od modelu autoryzacji.

Integracja SharePoint w systemie SaaS

Jeszcze ciekawszy przypadek występuje, gdy z SharePoint integruje się zewnętrzna aplikacja SaaS obsługująca wiele firm.

Proces może wyglądać następująco.

Firma A

Administrator łączy własny Microsoft 365.

Aplikacja zapisuje:

Firma B

Łączy zupełnie innego tenanta Microsoft 365.

Posiada własne identyfikatory i własną konfigurację.

System musi zachować całkowite rozdzielenie obu organizacji.

To jeden z powodów, dla których nie należy budować integracji na jednym wspólnym koncie Microsoft używanym przez wszystkich klientów.

Czy można pozwolić klientowi wybrać bibliotekę?

Tak.

Dobry proces konfiguracji może wyglądać tak:

1. Połącz konto Microsoft

Administrator wykonuje autoryzację.

2. Wybierz SharePoint

System pokazuje dostępne, dozwolone witryny.

3. Wybierz bibliotekę

Przykład:

4. Wybierz folder

Np.:

/Faktury

5. Ustal strukturę

Przykład:

Rok / miesiąc / kontrahent

6. Przetestuj połączenie

System tworzy próbny dokument albo odczytuje zawartość.

7. Zapisz konfigurację

Od tej chwili operacje wykonywane są automatycznie.

Przykład – automatyczna archiwizacja faktur

System fakturowy wystawia fakturę:

FV/2026/08/0156

Możliwy proces:

Całość może trwać kilka sekund.

Pracownik nie wykonuje żadnej dodatkowej czynności.

Przykład – dokumenty klienta

CRM posiada klienta:

ABC Sp. z o.o.

Przy utworzeniu klienta powstaje katalog:

Klienci/ABC

W nim:

Gdy handlowiec generuje ofertę, trafia ona do:

Klienci/ABC/Oferty

Podpisana umowa trafia do:

Klienci/ABC/Umowy

CRM nie musi przechowywać drugiej kopii wszystkich dokumentów.

Może przechowywać jedynie informacje pozwalające je odnaleźć.

Przykład – obieg dokumentu

Jeszcze bardziej zaawansowany scenariusz:

Wtedy SharePoint staje się częścią procesu biznesowego, a nie tylko katalogiem z plikami.

SharePoint i Power Automate

Nie każda integracja wymaga tworzenia własnego backendu.

W ekosystemie Microsoft wiele prostszych scenariuszy można budować przy pomocy Power Automate.

Przykład:

nowy dokument w bibliotece → wyślij wiadomość → utwórz wpis → rozpocznij akceptację.

Power Automate jest dobrym rozwiązaniem szczególnie wtedy, gdy:

Przy własnym produkcie SaaS, złożonej synchronizacji lub dużej skali bardziej naturalna może być bezpośrednia integracja przez Microsoft Graph.

API czy Power Automate – co wybrać?

Te rozwiązania nie muszą się wykluczać.

Aplikacja może korzystać z Graph API, a wewnątrz organizacji dodatkowe procesy mogą być realizowane przez Power Automate.

Najczęstsze błędy przy integracji z SharePoint

Błąd 1. Przechowywanie loginu i hasła

Nowoczesna integracja powinna wykorzystywać mechanizmy uwierzytelnienia Microsoft Entra ID.

Błąd 2. Nadanie dostępu do całego SharePoint

Jeżeli aplikacja potrzebuje jednej witryny, warto przeanalizować ograniczone uprawnienia, np. Sites.Selected.

Błąd 3. Korzystanie ze starego Azure ACS

Model ACS App-Only dla SharePoint Online przestał działać 2 kwietnia 2026 r.

Błąd 4. Przechowywanie wyłącznie ścieżki pliku

Folder lub nazwa mogą się zmienić.

Warto przechowywać również identyfikatory zasobów.

Błąd 5. Tworzenie duplikatów

Jeżeli CRM i SharePoint przechowują niezależnie edytowalne wersje tego samego dokumentu, szybko pojawia się problem ustalenia wersji aktualnej.

Błąd 6. Synchronizacja całej biblioteki przy każdym uruchomieniu

Przy dużej liczbie dokumentów znacznie lepiej wykorzystać mechanizmy śledzenia zmian, np. delta.

Błąd 7. Brak obsługi usunięcia dokumentu

Integracja powinna wiedzieć, co zrobić, gdy dokument zostanie:

Błąd 8. Brak obsługi konfliktów

Jest to szczególnie niebezpieczne w synchronizacji dwukierunkowej.

Błąd 9. Uzależnienie procesu wyłącznie od webhooka

Dobrze mieć możliwość ponownej synchronizacji i odtworzenia zmian.

Błąd 10. Brak logów integracji

Przy problemie trzeba móc odpowiedzieć:

został przesłany.

Jak powinien wyglądać rejestr operacji?

Przykład:

Administrator od razu widzi, co się wydarzyło.

Bez logów użytkownik zgłasza jedynie:

„Nie ma dokumentu w SharePoint.”

i rozpoczyna się ręczne szukanie problemu.

Co zrobić, gdy SharePoint chwilowo nie działa?

System nie powinien zgubić dokumentu.

Lepszy model:

Dzięki temu chwilowa awaria API nie powoduje utraty danych.

Integracja musi być odporna na duplikaty

Załóżmy:

system wysłał plik.

Nie otrzymał odpowiedzi na czas.

Nie wie, czy operacja się udała.

Ponawia żądanie.

Może powstać:

Umowa.pdf

oraz:

Umowa(1).pdf

Dlatego integrację warto projektować w sposób idempotentny.

System powinien potrafić ustalić:

czy ten dokument został już zapisany.

Pomocne mogą być:

Czy SharePoint jest backupem dokumentów z aplikacji?

Nie należy traktować integracji automatycznie jako pełnego backupu.

Jeżeli aplikacja synchronizuje usunięcia:

plik usunięty w aplikacji → usuń w SharePoint

to SharePoint staje się zsynchronizowanym repozytorium, a nie niezależną kopią bezpieczeństwa.

To ważne rozróżnienie.

Można stworzyć dwa różne scenariusze:

Archiwizacja

Dokument trafia do SharePoint i nie jest automatycznie usuwany razem z dokumentem źródłowym.

Synchronizacja

Zmiany po jednej stronie są odwzorowywane po drugiej.

Obie funkcje są użyteczne.

Ale rozwiązują inne problemy.

Czy wersjonowanie zastępuje backup?

Nie.

Historia wersji bardzo pomaga przy:

Nie powinna jednak zastępować kompletnej strategii tworzenia kopii bezpieczeństwa.

Integracja powinna jasno określać rolę SharePoint:

repozytorium robocze, archiwum czy jedna z warstw bezpieczeństwa?

Jak zabezpieczyć integrację?

Podstawowe zasady to:

Czy połączenie z SharePoint oznacza zgodność z RODO?

Nie automatycznie.

SharePoint jest narzędziem.

O zgodności całego procesu decyduje między innymi:

Integracja może jednak bardzo pomóc w uporządkowaniu dostępu.

Zamiast dokumentów przesyłanych e-mailem i przechowywanych na prywatnych komputerach można stworzyć centralne repozytorium z kontrolowanymi uprawnieniami i historią wersji.

Jak wdrożyć integrację z SharePoint krok po kroku?

Etap 1. Określ cel

Nie zaczynaj od API.

Najpierw odpowiedz:

Po co integrujemy SharePoint?

Przykładowo:

Etap 2. Wskaż źródło prawdy

Ustal:

gdzie znajduje się główna wersja dokumentu?

To jedna z najważniejszych decyzji.

Etap 3. Wybierz kierunek synchronizacji

Etap 4. Zaprojektuj strukturę

Ustal:

Etap 5. Zarejestruj aplikację w Entra ID

Wybierz odpowiedni model uwierzytelniania.

Etap 6. Nadaj minimalne uprawnienia

Nie zaczynaj automatycznie od pełnego dostępu do wszystkich witryn.

Etap 7. Zapisuj identyfikatory

Przechowuj m.in.:

Etap 8. Dodaj obsługę błędów

Uwzględnij:

Etap 9. Dodaj logi

Każda ważna operacja powinna pozostawiać ślad.

Etap 10. Przetestuj nietypowe przypadki

Sprawdź:

Przykładowa architektura integracji

Można ją uprościć do:

użytkownik

↓

system firmowy / SaaS

↓

moduł integracji

↓

Microsoft Entra ID

↓

Microsoft Graph API

↓

SharePoint Online

↓

witryna → biblioteka → dokument

W drugą stronę zmiany mogą wracać przez:

SharePoint → webhook / delta → integracja → system firmowy.

To znacznie lepszy model niż ręczne kopiowanie plików pomiędzy systemami.

Czy integracja z SharePoint jest trudna?

Podstawowe przesłanie jednego pliku nie jest szczególnie skomplikowane.

Trudność rośnie wraz z wymaganiami.

Prosta integracja

system → jeden folder SharePoint

Relatywnie prosta.

Średnia integracja

Wymaga już przemyślanej architektury.

Zaawansowana integracja

To pełnoprawny moduł integracyjny, który powinien być traktowany jak osobny element systemu.

Ściąga – możliwości integracji z SharePoint

FAQ – integracja z Microsoft SharePoint

Co daje integracja z SharePoint?

Pozwala automatycznie wymieniać dokumenty i dane pomiędzy SharePoint a innym systemem. Dzięki temu użytkownicy nie muszą ręcznie pobierać, kopiować i przesyłać plików.

Czy można automatycznie wysyłać dokumenty do SharePoint?

Tak. Microsoft Graph pozwala aplikacjom zapisywać pliki w bibliotekach SharePoint.

Czy można pobierać dokumenty z SharePoint do własnej aplikacji?

Tak. Zawartość pliku można pobierać przez Microsoft Graph, oczywiście pod warunkiem posiadania odpowiednich uprawnień.

Czy można automatycznie tworzyć katalog klienta?

Tak. Po utworzeniu kontrahenta system może stworzyć odpowiednią strukturę folderów w wybranej bibliotece.

Czy można używać SharePoint jako miejsca przechowywania faktur?

Tak. System fakturowy może po wystawieniu dokumentu automatycznie przesłać jego reprezentację do odpowiedniej biblioteki i zapisać link przy fakturze.

Czy SharePoint posiada historię wersji?

Tak. Biblioteki SharePoint obsługują wersjonowanie, które pozwala śledzić i przywracać wcześniejsze wersje dokumentów.

Czy integracja może działać bez zalogowanego pracownika?

Tak. Można zastosować uprawnienia aplikacyjne i uruchamiać zadania automatyczne w tle. W SharePoint Online Microsoft preferuje obecnie model oparty na Microsoft Entra ID.

Czy można ograniczyć aplikację tylko do jednego SharePoint?

Tak. Microsoft Graph udostępnia między innymi Sites.Selected, które pozwala przyznać aplikacji dostęp tylko do wybranych witryn.

Czy warto nadawać Sites.ReadWrite.All?

Tylko jeżeli aplikacja rzeczywiście potrzebuje dostępu do wszystkich witryn objętych tym zakresem. Jeśli ma obsługiwać jedną konkretną witrynę, warto rozważyć bardziej ograniczone uprawnienia.

Czy stare AppRegNew.aspx nadal jest dobrym sposobem integracji?

Nie dla nowych integracji SharePoint Online. Model Azure ACS App-Only został wycofany i zakończył działanie 2 kwietnia 2026 r. Microsoft rekomenduje model Microsoft Entra ID.

Jak wykryć zmianę dokumentu?

Można korzystać z Microsoft Graph delta API, które pozwala pobierać zmiany od ostatniej synchronizacji.

Czy SharePoint może sam powiadomić aplikację o nowym pliku?

Można skonfigurować change notifications i webhook. Microsoft Graph wysyła wtedy powiadomienia do wskazanego endpointu HTTPS.

Czy webhook wystarczy do synchronizacji?

Lepiej nie opierać całego mechanizmu wyłącznie na webhookach. Dobrym rozwiązaniem jest połączenie powiadomień z delta API i okresową kontrolą spójności.

Czy SharePoint może być głównym miejscem przechowywania dokumentów aplikacji?

Tak. W takim modelu zewnętrzny system może przechowywać przede wszystkim identyfikator, metadane i link do dokumentu, natomiast właściwy plik pozostaje w SharePoint.

Czy integracja zastępuje backup?

Nie automatycznie. Synchronizacja i backup to dwa różne procesy. Jeżeli usunięcie dokumentu jest synchronizowane między systemami, druga lokalizacja nie jest niezależną kopią bezpieczeństwa.

Podsumowanie

Integracja z Microsoft SharePoint może być bardzo prosta:

utwórz plik → wyślij go do biblioteki.

Może też stać się rozbudowanym systemem dwukierunkowej wymiany dokumentów i danych.

Nowoczesna architektura najczęściej wygląda następująco:

system → Microsoft Entra ID → Microsoft Graph → SharePoint.

Dla zmian w przeciwnym kierunku można zastosować:

SharePoint → webhook / delta → system.

Największą wartością integracji nie jest jednak samo przesyłanie plików.

Chodzi o stworzenie sytuacji, w której dokument powstaje raz, ma jedno właściwe miejsce przechowywania i jest automatycznie dostępny we wszystkich procesach, które go potrzebują.

Dobrze zaprojektowana integracja powinna więc zapewniać:

Szczególnie ważne w 2026 r. jest również korzystanie z aktualnego modelu autoryzacji Microsoft Entra ID zamiast starych poradników opartych na Azure ACS, który dla SharePoint Online zakończył działanie 2 kwietnia 2026 r.

W dobrze wdrożonym rozwiązaniu użytkownik nie powinien nawet zastanawiać się, gdzie fizycznie znajduje się dokument.

Otwiera klienta, projekt, fakturę albo sprawę w swoim systemie i jednym kliknięciem uzyskuje właściwy plik.

To właśnie jest największa korzyść integracji z SharePoint: dokumenty pozostają uporządkowane w Microsoft 365, ale są dostępne dokładnie tam, gdzie użytkownik wykonuje swoją codzienną pracę.