Witamy w Microsoft Knowledge Nugget. Nazywam się Mirko Peters. Dzisiejszy temat często wprowadza ludzi w zakłopotanie. Czym dokładniej jest Dataverse? Czy to baza danych, aplikacja, czy może ukryta usługa Dynamics 365, którą rozumieją tylko informatycy? Oto najprostsza definicja. Dataverse to wspólny fundament danych, na którym opiera się wiele rozwiązań Dynamics 365. Wyobraź sobie Dynamics 365 jako biurowiec. Sprzedaż obsługa klienta i inne aplikacje to pokoje, w których pracują ludzie, a Dataverse to system archiwizacji i reguły kryjące się za ścianami. Pod koniec tego odcinka dowiesz się, gdzie przechowywane są dane Dynamics i jak jedna aktualizacja klienta może wpłynąć na sprzedaż, automatyzację i raportowanie. Zanim jednak przejdziemy do nazw produktów, zacznijmy od biznesowego bałaganu, który to rozwiązuje. Jedno wspólne miejsce. Zamiast oddzielnych kopii, wyobraź sobie firmy z zespołem sprzedaży, wsparcia oraz działem finansowym. Sprzedaż przechowuje dane klientów w arkuszu kalkulacyjnym. Wsparcie pracuje w oddzielnym narzędziu do obsługi zgłoszeń. Finanse mają nazwiska klientów w swoim własnym systemie. Ktoś inny zapisuje wątki e-mail w udostępnionej skrzynce, a jeszcze inna osoba trzyma notatki w folderze, którego nikt inny nie potrafi znaleźć. Ten sam klient istnieje teraz w pięciu miejscach. Początkowo taka konfiguracja wydaje się normalna, ponieważ każdy zespół widzi tylko wycinek pracy, który ma przed sobą. Ale jest pewien problem, gdy tylko klient zmieni numer telefonu, adres, nazwę firmy lub głównego kontaktu, zaczynają się kłopoty. Sprzedaż aktualizuje arkusz, wsparcie tego nie widzi, a finanse wciąż wysyłają dokumenty na stary adres. Wtedy ktoś eksportuje listę, ręcznie ją czyści, rozsyła e-mailem i nagle trzy osoby wierzą, że to właśnie ich kopia jest właściwa. Której liście należy ufać? To pytanie marnuje więcej czasu niż mogłoby się wydawać. Pracownicy przerywają pracę, by porównywać rekordy. Menedżerowie pytają, dlaczego raport nie zgadza się z systemem sprzedaży. Agent wsparcia otwiera zgłoszenie dla klienta, którego dane już istnieją gdzie indziej, ale w nieco innej formie. Nikt nie próbuje robić bałaganu. Bałagan powstaje przez kopię. Dwadzieścia lat temu oddzielne systemy oznaczały osobne serwery, bazy danych i zespoły zarządzające własnymi informacjami. Ich połączenie wymagało pracy programistycznej, zaplanowanego importu i wieluręcznych kontroli. Zmiana w jednym miejscu mogła dotrzeć do drugiego systemu jutro, w przyszłym tygodniu albo nigdy. Dataverse daje aplikacjom biznesowym wspólne miejsce dla tego typu informacji. Mówiąc prościej, Dataverse to chmurowa platforma danych Microsoftu dla informacji biznesowych. Przechowuje te informacje w ustrukturyzowanych tabelach, dzięki czemu dane mają przejrzysty kształt, zamiast być rozproszonymi notatkami, luźnymi plikami i niespójnymi arkuszami. Możesz myśleć o tym jak o firmowej szafce na dokumenty, z której może jednocześnie korzystać kilka zatwierdzonych narzędzi. Klient pojawia się w Dataverse tylko raz. Ten sam klient może pojawić się w Dynamics 365 Sales, gdy sprzedawca pracuje nad transakcją. Te same dane klienta mogą wyświetlić się w Dynamics 365 Customer Service, gdy agent obsługuje zgłoszenie serwisowe. Aplikacja PowerApp może korzystać z tych samych informacji o kliencie dla pracownika terenowego lub opiekuna klienta bez konieczności kopiowania danych. Jeden wiersz klienta, jeden wspólny punkt odniesienia. Nie oznacza to, że każdy zespół nagle widzi wszystko. Dostęp nadal wymaga zasad, do których wkrótce przejdziemy. Oznacza to, że zatwierdzone aplikacje mogą korzystać z tych samych informacji biznesowych, zamiast tworzyć własne, konkurencyjne wersje. Dlatego Dynamics 365 i Dataverse tak naturalnie do siebie pasują. Aplikacje Dynamics 365, takie jak sprzedaż czy obsługa klienta, wykorzystują Dataverse do przechowywania i zabezpieczania swoich danych. Ale rzecz w tym, że gdy mówi się o integracji Dynamics 365 z Dataverse, często wyobrażamy sobie dwa osobne produkty wymagające łącznika. W przypadku wielu aplikacji Dynamics 365 tak nie jest. Dane znajdują się już w Dataverse. Nie musisz wyciągać listy klientów z Dynamics 365, kopiować jej do innej bazy i liczyć, że obie strony będą aktualne. Możesz budować na tym samym fundamencie, używając tych samych informacji biznesowych, z których już korzysta Dynamics 365. To zmienia podejście do rozmowy. Zamiast pytać, jak zsynchronizować te dwie listy klientów, możesz zapytać, którzy pracownicy i aplikacje muszą korzystać z tego rekordu klienta i co każdy z nich powinien móc robić. Dataverse nie zastępuje wszystkich systemów posiadanych przez firmę. Firma może nadal korzystać z oprogramowania finansowego, narzędzi branżowych, systemów magazynowych, stron internetowych czy starszych aplikacji z własnymi danymi. Dataverse nie jest magicznym klejem, który z dnia na dzień usunie każdy zewnętrzny system. Daje Ci wspólne miejsce na dane biznesowe, które muszą być współdzielone przez połączone aplikacje, dane klientów, praca sprzedażowa, obsługa wsparcia, zadania i działania następcze. Te rekordy mogą współistnieć w jednym źródle, które zatwierdzone narzędzia mogą odczytywać i aktualizować. Otwórzmy więc razem tę szafkę na dokumenty. Gdy zobaczysz, jak Dataverse organizuje informacje wewnątrz, połączenie z Dynamics 365 stanie się znacznie łatwiejsze do zrozumienia. Szafka na dokumenty, tabele, wiersze, kolumny i relacje. Otwórzmy tę szafkę. Wewnątrz Dataverse informacje znajdują się w tabelach. Pomyśl o tym, jak o prawdziwej szafce z oddzielnymi szufladami. Auć! Jedna szuflada mieści firmy, druga ludzi, a trzecia zgłoszenia serwisowe. Nie wrzucasz każdego papierka do jednej wielkiej szuflady, mając nadzieję, że ktoś to później posortuje. Każda szuflada ma swoje zadanie. W Dataverse tabela przechowuje jeden rodzaj informacji biznesowych. Tabela firm zazwyczaj zawiera dane podmiotów, z którymi współpracujesz. Tabela kontaktów przechowuje informacje o poszczególnych osobach. Tabela potencjalnych klientów zawiera osoby, które mogą stać się realnymi klientami. Tabela zgłoszeń przechowuje prośby o wsparcie, a tabela działań pozwala śledzić pracę, taką jak połączenia, e-maile, spotkania i zadania. To są tabele standardowe. Microsoft udostępnia je, ponieważ większość firm musi śledzić klientów, ludzi, pracę oraz konwersacje. Nie musisz tworzyć nowej tabeli dla typowych zadań, jeśli standardowa tabela już do nich pasuje. Jednak każda firma ma również własną specyfikę pracy. Firma szkoleniowa może potrzebować śledzenia kursów i certyfikatów. Firma z branży nieruchomości może potrzebować danych o budynkach, lokalach i inspekcjach. Producent może śledzić przeglądy sprzętu lub wizyty serwisowe. W takich przypadkach możesz utworzyć tabele niestandardowe, dopasowane do rzeczywistych działań Twojej firmy. Pomyśl o tabeli niestandardowej jak o dodaniu nowej szuflady do szafki i nadaniu jej wyraźnej etykiety. Każda tabela zawiera wiersze. Wiersz to pojedynczy element w danej szufladzie. Na przykład jeden wiersz w tabeli kontaktów może reprezentować Marię Gome, osobę z firmy klienta. Jej wiersz zawiera jej własne dane, odrębne od każdego innego kontaktu w systemie. Kolumny opisują szczegóły, które chcesz zachować dla każdego wiersza. Wiersz kontaktu Marii może mieć kolumny na imię, nazwisko, adres e-mail, numer telefonu, stanowisko, firmę, właściciela rekordu i status. Kolumna określa rodzaj informacji, które powinny się w niej znajdować, więc kolumna e-mail oczekuje adresu e-mail, a kolumna statusu może przechowywać wybrane opcje statusu. W ten sposób informacje biznesowe zyskują niezawodną strukturę. Bez kolumn jedna osoba mogłaby wpisać numer telefonu w polu notatek, inna dodałaby go do pola nazwiska, a ktoś jeszcze mógłby go w ogóle nie wpisać. Dzięki przejrzystej tabeli kontaktów wszyscy pracują z tym samym zestawem szczegółów w tych samych miejscach. Taka struktura pomaga również aplikacjom zrozumieć dane. Formularz może wyświetlić odpowiednie pola, raport może pogrupować kontakty według statusu, a automatyzacja może zareagować na zmianę właściciela. Informacje nie są tylko przechowywane, mają etykiety, które informują połączone narzędzia, co oznacza każda część danych. Zacznij od tabel standardowych, zawsze gdy pasują one do Twoich potrzeb biznesowych. Jeśli sprzedajesz firmom, tabele firm i kontaktów opisują wzorce, które większość ludzi już rozumie. Jeśli zajmujesz się wsparciem klienta, zgłoszenia dają Ci dobry punkt wyjścia. Następnie dodawaj tabele niestandardowe tylko wtedy, gdy Twoja firma posiada informacje, które nie pasują do wbudowanych wzorców. Pozwala to uniknąć częstego problemu, czyli tworzenia pięciu różnych tabel oznaczających to samo klienta. Jeden zespół nazywa to klientem, inny główną bazą klientów, a trzeci kontaktami partnerskimi. Wkrótce nikt nie wie, której tabeli powinien użyć. Przejrzyste tabele standardowe i starannie nazwane tabele niestandardowe sprawiają, że szafka pozostaje zrozumiała, gdy pracuje na niej coraz więcej osób. Kolejna część pokazuje, jak te szuflady zaczynają ze sobą współpracować. Kontakt przypisany jest do konta. Maria pracuje w Contozo Ltd. Zamiast ponownie wpisywać adres, główny numer telefonu i dane firmy Contozo w wierszu Marii, Dataverse może utworzyć relację między tabelą kontaktów a tabelą kont. Maria jest powiązana z Contozo i to powiązanie jest ważne, ponieważ informacje o firmie pozostają przypisane do firmy. Jeśli Contozo zmieni adres biura, wystarczy raz zaktualizować wiersz konta, a każdy powiązany kontakt nadal będzie wskazywał na tę samą firmę bez konieczności przechowywania własnej, przestarzałej kopii. Relacje łączą również zgłoszenie serwisowe z klientem, który je zgłosił. Mogą one łączyć szansę sprzedaży z rozmowami, e-mailami, spotkaniami i zadaniami dotyczącymi danej transakcji. Gdy sprzedawca otwiera szansę sprzedaży, widzi powiązane z nią działania, zamiast przeszukiwać niepowiązane notatki i kalendarze. Informacje mają kontekst. Nie patrzysz tylko na numer zgłoszenia, widzisz, do którego klienta ono należy. Nie przeglądasz tylko kontaktu, widzisz firmę powiązaną z tą osobą. Te powiązania sprawiają, że dane są przydatne bez konieczności wielokrotnego wpisywania tych samych faktów w kilku miejscach. Mała uwaga dotycząca nazewnictwa, zanim przeczytasz starsze poradniki lub obejrzysz starsze filmy. Możesz usłyszeć słowa ENCIA, pole i rekord. To starsze terminy z Dataverse. Firma Microsoft używa teraz określenia tabela zamiast ENCIA, kolumna zamiast pole i wiersz zamiast rekord. Znaczenie pozostało bez zmian. Starszy poradnik, który zaleca utworzenie ENCII, mówi o tworzeniu tabeli, pole to kolumna, a rekord to wiersz. Znajomość obu zestawów terminów uchroni Cię przed mylnym wrażeniem, że natrafiłeś na inny produkt. Zatem tabele porządkują informacje, a relacje je łączą. Jednak dobrze zorganizowana szafka nadal wymaga kontroli. Ktoś musi zdecydować, co użytkownicy mogą wprowadzać, zmieniać i do czego mają bezpieczny dostęp. Zasady i recepcja. Dane w Dataverse działają tylko wtedy, gdy odpowiednie osoby mogą z nimi bezpiecznie pracować. Przedstawiciel handlowy potrzebuje danych klienta, agent wsparcia historii zgłoszeń, menedżer szerszego wglądu, a partner zewnętrzny może potrzebować dostępu tylko do niewielkiej części procesu. Nie wszyscy powinni widzieć te same informacje. Pomyśl o rekordzie klienta z prywatną notatką, wynegocjowaną ceną i otwartym zgłoszeniem serwisowym. Przyznanie każdemu użytkownikowi pełnego dostępu wiąże się z dużym ryzykiem. Zbyt sztywne ograniczenia, uniemożliwiające pracę, to z kolei inny problem. Dataverse oferuje narzędzia do zarządzania tymi kwestiami. Pierwszym z nich jest tożsamość. Logując się na konto firmowe, zostajesz zidentyfikowany przez Microsoft EntraID. Traktuj EntraID jak recepcję przy wejściu do biura. Przychodzisz, pokazujesz identyfikator, a recepcjonista sprawdza, kim jesteś, zanim wejdziesz. Dataverse używa tej tożsamości, aby wiedzieć, kto pracuje z danymi. Nie kończy się to na pytaniu, czy ta osoba może wejść. Pytanie brzmi też, co ta osoba może robić po wejściu. Tutaj wchodzą role zabezpieczeń. Rola zabezpieczeń to zestaw uprawnień powiązany ze stanowiskiem lub zakresem obowiązków. Możesz utworzyć rolę dla zespołu sprzedaży, inną dla obsługi klienta, a jeszcze inną dla menedżerów. Każda rola pozwala kontrolować dostęp do tabeli. Przedstawiciel handlowy może mieć prawo do odczytu, tworzenia i aktualizacji kont, kontaktów, lidów i szans sprzedaży. Może natomiast nie mieć uprawnień do usuwania ważnych informacji o klientach. Pracownik wsparcia może tworzyć i aktualizować zgłoszenia, ale nie zmieniać szans sprzedaży. Uprawnienia mogą obejmować odczyt, tworzenie, zmianę oraz usuwanie wierszy. Oznacza to, że dostęp nie zależy od pamiętania, które przyciski ukryć w każdej aplikacji. Uprawnienia są przypisane do samych danych. Dzięki temu te same zasady ochrony obowiązują wszędzie tam, gdzie pojawiają się dane z Dataverse. Dostęp można jeszcze bardziej zawęzić. Zabezpieczenia na poziomie wiersza określają, z którymi konkretnymi wierszami może pracować użytkownik. Przedstawiciel widzi tylko swoich klientów, podczas gdy menedżer sprzedaży widzi klientów przypisanych do całego zespołu. Obaj korzystają z tej samej tabeli kont. Po prostu nie widzą tego samego wycinka danych. Taki układ pomaga skupić się na własnej pracy, zapewniając menedżerom niezbędny wgląd. Zmniejsza to również ryzyko, że ktoś otworzy informacje o kliencie, do których nie powinien mieć wglądu. Niektóre informacje wymagają jeszcze ściślejszej ochrony. Zabezpieczenia na poziomie kolumn pozwalają chronić poszczególne kolumny wewnątrz tabeli. Użytkownik może otworzyć wiersz klienta, ale nie powinien widzieć numeru identyfikacyjnego, wynagrodzenia czy danych bankowych. Wiersz klienta pozostaje dostępny do pracy, którą trzeba wykonać. Chroniona kolumna pozostaje jednak niedostępna. W większych firmach jednostki biznesowe mogą tworzyć granice między częściami organizacji. Firma może oddzielać regiony, działy lub spółki zależne pracujące z różnymi grupami klientów. Jednostki biznesowe pomagają określić, jak działa dostęp w obrębie tych granic. Nie oznacza to jednak, że każda firma potrzebuje skomplikowanej struktury zabezpieczeń. Mały zespół może potrzebować tylko kilku jasnych ról. Większa firma może wymagać więcej warstw, ponieważ jej zespoły, regiony i obowiązki różnią się. Chodzi o to, że Dataverse potrafi dostosować dostęp do tego, jak faktycznie działa firma. Kontrola dostępu chroni przed tym, kto może sięgnąć do danych, ale zasady chronią też jakość samych danych. Reguła biznesowa może wymagać od kogoś podania numeru telefonu przed zapisaniem nowego kontaktu. Może sprawdzać warunek, np. wymagając podania powodu przy zamykaniu zgłoszenia. Może też zmieniać to, co widzą użytkownicy, w oparciu o wprowadzane przez nich informacje. Ta sama reguła ma zastosowanie we wszystkich aplikacjach korzystających z tej tabeli. Ma to znaczenie, ponieważ nie chcesz, aby jedna aplikacja akceptowała niekompletne dane, a druga je odrzucała. Reguła jest przypisana do informacji biznesowych, a nie do konkretnego ekranu, który je wyświetla. Dataverse może również uruchamiać logikę w tle, aby pomóc w utrzymaniu spójności procesów biznesowych. Szczegół, który musisz zapamiętać, jest prosty. Dane mają swoje zasady, to nie tylko magazyn. Fundament obejmuje więc informacje, osoby uprawnione do pracy z nimi oraz zasady, które utrzymują ich użyteczność. Gdy Dynamics 365 działa na tym samym fundamencie, nie potrzebuje tradycyjnego mostu, by dotrzeć do własnych danych biznesowych, co faktycznie oznacza integracja Dynamics 365. Większość słysząc integracja Dynamics 365 z Dataverse wyobraża sobie dwa oddzielne systemy połączone łącznikiem. Jeden system przechowuje dane klienta, inny potrzebuje ich kopii, więc ktoś konfiguruje synchronizację, czeka na jej wykonanie i ma nadzieję, że nic się nie zepsuje. Ten obraz ma sens w przypadku wielu narzędzi biznesowych, ale tutaj, w przypadku Dynamics 365 Sales i Dynamics 365 Customer Service, połączenie jest o wiele ściślejsze. Te aplikacje używają Dataverse jako wspólnego fundamentu danych. To nie są dwie oddzielne bazy danych przesyłające wiersze klientów w obie strony, tylko po to, by się zrozumieć. One pracują na tych samych informacjach biznesowych od samego początku. Uczyńmy to konkretnym przykładem. Wyobraź sobie, że jesteś sprzedawcą i tworzysz nową firmę w Dynamics 365 Sales. Dodajesz głównego kontaktu i zaczynasz pracować nad potencjalną transakcją. Te szczegóły natychmiast stają się częścią wspólnych danych, z których korzysta aplikacja. Później ten klient kontaktuje się z pomocą techniczną. Agent wsparcia może pracować z dokładnie tymi samymi danymi firmy i kontaktu. Nikt nie musi eksportować listy ze sprzedaży, ani ponownie tworzyć klienta w oddzielnym narzędziu wsparcia. Agent po prostu łączy zgłoszenie wsparcia z tym klientem i widzi historię, która pomaga mu zrozumieć, co się dzieje. Dział sprzedaży widzi transakcję, obsługa klienta widzi zgłoszenie, a oba zespoły pracują dla tego samego klienta. Oczywiście nie oznacza to automatycznie, że każdy ekran wygląda identycznie lub że każdy zespół stosuje ten sam proces. Dział sprzedaży potrzebuje leadów, szans sprzedaży, rozmów telefonicznych i spotkań. Dział obsługi klienta potrzebuje zgłoszeń, kolejek i historii serwisowej. Każda aplikacja Dynamics 365 zapewnia ludziom narzędzia stworzone do ich pracy. Chociaż podstawowe informacje biznesowe mogą łączyć się tam, gdzie jest to potrzebne, To właśnie ten wspólny fundament ludzie często mają na myśli, mówiąc o integracji Dynamics 365 i Dataverse. Nie chodzi głównie o przenoszenie danych z punktu A do punktu B. Chodzi o to, że aplikacje od początku pracują na tych samych wierszach, relacjach, regułach i kontroli dostępu. Przeanalizujmy prostą ścieżkę sprzedaży. Lead pojawia się na stronie internetowej lub podczas wydarzenia. Sprzedawca pracuje z tym leadem, dowiaduje się więcej o danej osobie i przekształca lead w relacje z klientem oraz szansę sprzedaży. Rozmowy i maile, spotkania i zadania mogą być powiązane z tą pracą. Dzięki temu zespół nie musi przeszukiwać oddzielnych narzędzi, aby połączyć fakty w całość. Jeśli klient później potrzebuje pomocy, zgłoszenie serwisowe może zostać połączone z tym samym klientem. Agent wsparcia widzi nie tylko imię, nazwisko i adres e-mail. Może pracować w kontekście już zidentyfikowanej relacji z klientem. Tymczasem zespół sprzedaży widzi, że klient ma otwarty problem serwisowy i może uniknąć rozmowy o przedłużeniu umowy bez wiedzy o zaistniałym kłopocie. Jedna relacja z klientem może wspierać różne rodzaje pracy, co jest znacznie bardziej użyteczne niż tylko utrzymywanie pasującego nazwiska klienta w dwóch systemach. Możesz również usłyszeć określenie Common Data Model, czasami skracane do CDM. Niech nazwa nie sprawia wrażenia, że to coś bardziej tajemniczego niż jest w rzeczywistości. Oznacza to po prostu, że Microsoft dostarcza typowe wzorce tabel biznesowych dla elementów śledzonych przez wiele firm, takich jak konta, kontakty, działania i zgłoszenia. Te wzorce nadają aplikacjom opartym na Dynamics 365 i Dataverse wspólny język początkowy. Konto oznacza firmę. Kontakt oznacza osobę. Działanie śledzi pracę wokół relacji biznesowej. Możesz dostosować konfigurację do swojej firmy i dodawać własne tabele, gdy jest to potrzebne, ale nie musisz za każdym razem zaczynać od zera. Kiedy jedna aplikacja rozumie tabelę kont, a druga korzysta z tej samej tabeli, obie aplikacje odnoszą się do tego samego typu informacji biznesowych. To zmienia również możliwości tworzenia rozwiązań. Załóżmy, że Twój zespół terenowy potrzebuje prostej aplikacji, aby sprawdzić klienta, potwierdzić wizytę i dodać notatkę po spotkaniu. Możesz stworzyć aplikację PowerApp, która współpracuje z tymi samymi tabelami Dataverse, z których korzysta już Dynamics 365. Nie ma potrzeby eksportowania klientów do nowej listy tylko dla tej aplikacji. Pracownik terenowy otwiera aplikację, znajduje klienta i aktualizuje informacje o wizycie. Dane pozostają powiązane z relacją z klientem, z której korzysta już sprzedaż lub obsługa klienta, zgodnie z omówionymi wcześniej zasadami bezpieczeństwa. Do bardziej ustrukturyzowanych zadań biznesowych można stworzyć aplikację opartą na modelu. Aplikacja oparta na modelu zaczyna się od modelu danych. Wybierasz tabelę Dataverse, definiujesz ich relacje, konfigurujesz formularze i widoki oraz przypisujesz rolę zabezpieczeń. Następnie Power Apps wykorzystuje tę strukturę, aby stworzyć działające środowisko aplikacji biznesowej. Pomyśl o tym jak o uporządkowaniu stołu warsztatowego wokół narzędzi i materiałów, których faktycznie używa Twój zespół. Tabele opisują pracę, a relacje łączą poszczególne elementy. Formularze pozwalają użytkownikom wprowadzać i przeglądać szczegóły. Widoki pomagają im znaleźć wiersze, które wymagają uwagi. Zabezpieczenia decydują o tym, co każda osoba może otworzyć lub zmienić. Aplikacja oparta na modelu może działać obok Dynamics 365, ponieważ obie korzystają z Dataverse. Może Dynamics 365 Sales obsługuje cały proces sprzedaży, podczas gdy mniejsza aplikacja oparta na modelu zapewnia menedżerom umów dedykowane miejsce do śledzenia porozumień z klientami. Obie mogą pracować z tymi samymi danymi klientów bez tworzenia drugiej bazy danych. Oczywiście taki dostęp nadal wymaga ostrożności. To, że aplikacja może pracować z tabelą Dataverse, nie oznacza, że każdy użytkownik powinien edytować każdy wiersz lub widzieć każdą kolumnę. Role, dostęp do wierszy i reguły biznesowe nadal kontrolują to, co się dzieje. Aplikacja terenowa może zapewnić użytkownikowi dokładnie te szczegóły klienta i funkcje, których potrzebuje bez ujawniania reszty danych firmy. Więc integracja Dynamics 365 z Dataverse jest teraz jak kabel łączący dwa odległe pokoje. Aplikacje Dynamics 365, aplikacje niestandardowe i procesy biznesowe mogą działać na tym samym wspólnym fundamencie. Gdy już to dostrzeżesz, kolejne pytanie staje się jasne. Do czego jeszcze możesz wykorzystać tę samą aktualizację klienta w ramach połączonej platformy Microsoft? Jak połączona platforma sprawdza się w rzeczywistej pracy? Udostępniona aktualizacja klienta staje się użyteczna, gdy narzędzia wokół niej mogą zareagować. Power Automate zajmuje się pracą następczą, monitorując zmiany w wierszu Dataverse i uruchamiając akcje, gdy taka zmiana nastąpi. Na przykład nowy lead trafia do Dynamics 365 Sales. Przepływ może powiadomić przypisanego sprzedawcę, wysłać wiadomość w Teams lub utworzyć zadanie do wykonania. Nikt nie musi cały dzień pilnować współdzielonej skrzynki odbiorczej. Lead zmienia się, a kolejny krok uruchamia się automatycznie. Power Automate nie potrzebuje oddzielnej kopii Leada tylko po to, by wykonać tę pracę. Może reagować na wiersz w Dataverse używając tych samych danych klienta i informacji o właścicielu, których używa aplikacja sprzedażowa. Dzięki temu automatyzacja pozostaje blisko procesów biznesowych, zamiast polegać na ręcznym eksporcie plików i uruchamianiu łańcucha wiadomości e-mail. Potem jest Power B. Kierownik sprzedaży może chcieć sprawdzić bieżące szanse sprzedaży. Kierownik obsługi klienta może potrzebować informacji o liczbie spraw z tego tygodnia, otwartych zgłoszeniach lub klientach najczęściej kontaktujących się ze wsparciem. Power B może raportować dane biznesowe z Dataverse, dzięki czemu zespoły widzą postępy pracy bez konieczności przygotowywania arkuszy co piątek. Raport korzysta z danych biznesowych, z których ludzie już korzystają. Oznacza to, że wykres sprzedaży może się zmieniać w miarę postępów w ofertach. Pulpit zgłoszeń pokazuje bieżące obciążenie pracą w miarę aktualizacji spraw przez agentów. Chodzi o to, że pulpit zastępuje ręczne sprawdzanie szczegółów przez pracowników. Zapewnia im wyraźniejszy wgląd w pracę, zanim zdecydują, co wymaga uwagi. Power Apps dodaje kolejną ścieżkę do tego samego procesu. Wyobraźmy sobie pracownika terenowego, przybywającego do klienta. Nie potrzebuje on pełnego środowiska Dynamics 365 Sales. Może potrzebować tylko znaleźć klienta, przejrzeć szczegóły wizyty, potwierdzić przebieg spotkania i dodać notatkę lub zdjęcie. Skupiona aplikacja Power App może zapewnić mu to prostsze rozwiązanie. Zespół obsługi konta może potrzebować aplikacji do przeglądania umów z klientami. Manager może potrzebować prostej aplikacji do zatwierdzania wniosków. Każda aplikacja może skupiać się na jednym zadaniu, pracując w tle na tych samych kontrolowanych danych z Dataverse. Pracownik otrzymuje narzędzie dostosowane do swoich codziennych zadań. Firma zachowuje spójność połączonych informacji. Czasami te informacje pochodzą spoza Dataverse. Firma może mieć listę z zewnętrznego źródła online, która powinna stać się częścią jej danych biznesowych. Power Query może pobrać dane ze wspieranych źródeł online, oczyścić je podczas importu i załadować do odpowiedniej tabeli Dataverse. Jest to przydatne, gdy zewnętrzne źródło zawiera informacje potrzebne narzędziom Dynamics i Power Platform. Nadal trzeba zdecydować, co powinno trafić do Dataverse i jak połączyć to z istniejącymi tabelami. Import danych bez tego planu po prostu przenosi chaos w nowe miejsce. Pozwólmy o tym połączyć te elementy w jeden codzienny przepływ pracy. Nowy lead trafia do Dynamics 365, a reguła przypisania sprawdza, kto powinien nim zarządzać, np. na podstawie regionu lub produktu. Właściciel otrzymuje wiadomość w Teams poprzez przepływ Power Automate, więc wie, że czeka na niego praca. Gdy sprzedawca aktualizuje lead i przeprowadza go przez proces sprzedaży, pulpit Power B aktualizuje się, pokazując zespołowi stan bieżącego lejka sprzedaży. Jedna aktualizacja uruchamia użyteczne działania w kilku miejscach. Power Automate przesuwa pracę z jednego etapu do kolejnego. Power B pomaga ludziom widzieć wykonywaną pracę. Power Apps zapewniają konkretnym zespołom ukierunkowany sposób działania. Dataverse dba o to, by informacje biznesowe były uporządkowane i bezpieczne, podczas gdy te narzędzia wykonują swoją pracę. Ta różnica ma znaczenie. Automatyzacja to nie system archiwizacji, a pulpit nawigacyjny to nie baza danych klientów. Każde narzędzie ma osobne zadanie, ale wszystkie mogą pracować w oparciu o to samo źródło. Wiedza ta pomaga wybrać odpowiednie narzędzie, zamiast traktować każdy arkusz kalkulacyjny lub prostą listę jak system do obsługi całego procesu biznesowego. Kiedy Dataverse pasuje i czego nie zastępuje? Oto w czym rzecz. Wybierz Dataverse, gdy wiele osób i aplikacji musi pracować na połączonych danych biznesowych. Potrzebujesz jasnych zasad dostępu i powtarzalnych procesów. Dataverse to zapewnia, ale nie zastępuje wszystkiego innego. Excel pozostaje najlepszym wyborem do osobistych analiz i szybkich list. Listy SharePoint dobrze sprawdzają się w prostym śledzeniu zadań zespołu. A jeśli jesteś programistą wymagającym pełnej kontroli SQL, pozostaje silnym wyborem. Kiedy więc Dataverse naprawdę pasuje? Gdy Twoje dane muszą łączyć się między aplikacjami Dynamics 365, automatyzacją i raportami bez tworzenia kolejnych kopii. Właśnie w tym błyszczy. Wniosek końcowy. Jeden fundament. Wiele narzędzi biznesowych. Oto podsumowanie. Dynamics 365 i Dataverse działają najlepiej, gdy wszystkie dane, zasady, zabezpieczenia, aplikacje, automatyzacja i raporty współdzielą jeden wspólny fundament. Subskrybuj Microsoft Knowledge Nugget na m365.fm, aby uzyskać więcej prostych przewodników po Dynamics 365, Power Platform i Microsoft 365. Zobacz nasz odcinek o aplikacjach opartych na modelach, aby przekonać się, jak tabele Dataverse zmieniają się w działającą aplikację biznesową. Zobacz nasz odcinek w tamtym.