Witamy w Microsoft Knowledge Nugget. Nazywam się Mopeters. Dzisiejszy temat często wprawia 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 zasady ukryte za ścianami. Pod koniec tego odcinka dowiesz się, gdzie przechowywane są dane Dynamics i jak jedna aktualizacja danych klienta może wpłynąć na sprzedaż, automatyzację i raporty. Ale zanim przejdziemy do nazw produktów, zacznijmy od biznesowego bałaganu. To rozwiązuje problem jednego wspólnego miejsca. Zamiast oddzielnych kopii, wyobraź sobie firmy z zespołem sprzedaży, wsparcia technicznego i działem finansów.

Dział sprzedaży przechowuje dane klientów w arkuszu kalkulacyjnym. Wsparcie pracuje w osobnym narzędziu do obsługi zgłoszeń. Dział finansów ma nazwiska klientów we własnym systemie. Ktoś jeszcze zapisuje wątki mailowe w udostępnionej skrzynce, a inna osoba trzyma notatki w folderze, którego nikt inny nie potrafi znaleźć. Ten sam klient istnieje teraz w pięciu miejscach. Taki układ początkowo wydaje się normalny, ponieważ każdy zespół widzi tylko tę część pracy, która jest przed nim. Ale jest pewien haczyk. Gdy tylko klient zmieni numer telefonu, adres, nazwę firmy lub głównego kontaktu, zaczynają się problemy. Sprzedaż aktualizuje arkusz kalkulacyjny. Wsparcie tego nie widzi. Dział finansów wciąż wysyła dokumenty na stary adres. Następnie ktoś eksportuje listę, ręcznie ją czyści, rozsyła mailem i nagle trzy osoby wierzą, że to 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, choć są nieco inne. Nikt nie chce tworzyć bałaganu. Bałagan wynika z powielania danych. 20 lat temu oddzielne systemy oznaczały oddzielne serwery, bazy danych i zespoły prowadzące własną ewidencję. Ich połączenie wymagało niestandardowych prac, planowanych importów i mnóstwa ręcznego sprawdzania. Zmiana w jednym miejscu mogła dotrzeć do innego systemu jutro, w przyszłym tygodniu albo nigdy. Dataverse zapewnia aplikacjom biznesowym wspólne miejsce dla tego typu informacji. Mówiąc prościej, Dataverse to chmurowa platforma danych Microsoft dla informacji biznesowych. Przechowuje te informacje w ustrukturyzowanych tabelach, dzięki czemu dane mają jasną formę, zamiast być przypadkowymi notatkami, luźnymi plikami czy rozproszonymi arkuszami.

Można o tym myśleć jak o firmowej kartotece, z której może korzystać jednocześnie kilka zatwierdzonych narzędzi. Klient pojawia się w Dataverse tylko raz. Ten klient może wyświetlić się w Dynamics 365 Sales, gdy handlowiec pracuje nad transakcją. Te same dane klienta mogą pojawić się w Dynamics 365 Customer Service, gdy agent obsługuje zgłoszenie serwisowe. Aplikacja PowerApp może wykorzystać te same informacje o kliencie dla pracownika terenowego lub opiekuna klienta, bez konieczności wcześniejszego 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 czego 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 Sales czy Customer Service, używają Dataverse do przechowywania i zabezpieczania danych, na których pracują.

Ale jest pewien haczyk. Gdy ktoś mówi o integracji Dynamics 365 z Dataverse, często wyobraża sobie dwa osobne produkty wymagające łącznika. W przypadku wielu aplikacji Dynamics 365 tak nie jest. Dane już znajdują się w Dataverse. Nie pobierasz listy klientów z Dynamics 365, nie kopiujesz jej do innej bazy danych i nie liczysz na to, że obie strony pozostaną aktualne. Możesz budować na tym samym fundamencie, używając tych samych informacji biznesowych, z których korzysta już Dynamics 365. To zmienia podejście do dyskusji. Zamiast pytać, jak zsynchronizować te dwie listy klientów, możesz zapytać, które osoby i aplikacje muszą pracować z tym rekordem klienta i co każdemu z nich powinno być wolno robić. Dataverse nie zastępuje oczywiście każdego systemu, który posiada firma. Przedsiębiorstwo może nadal używać oprogramowania finansowego, narzędzi branżowych, systemów magazynowych, stron internetowych czy starszych aplikacji przechowujących własne dane.

Dataverse to niemagiczny klej, który z dnia na dzień usunie każdy zewnętrzny system. Daje Ci wspólne miejsce na dane biznesowe, które połączone aplikacje muszą współdzielić. Dane klientów, praca sprzedażowa, obsługa zgłoszeń, 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ę kartotekę. Gdy zobaczysz, jak Dataverse organizuje informacje, zrozumienie całości połączeń w Dynamics 365 stanie się znacznie łatwiejsze dzięki tabelom, wierszom, kolumnom i relacjom. Otwórzmy tę kartotekę. Wewnątrz Dataverse informacje znajdują się w tabelach. Pomyśl o tym, jak o prawdziwej szafce z oddzielnymi szufladami. Jedna szuflada mieści firmy, druga osoby, a trzecia zgłoszenia serwisowe. Nie wrzucasz każdej kartki do jednej wielkiej szuflady, mając nadzieję, że ktoś później to posortuje. Każda szuflada ma swoje zadanie.

W Dataverse tabela przechowuje jeden rodzaj informacji biznesowych. Tabela kontrahentów zazwyczaj przechowuje firmy, z którymi współpracujesz. Tabela kontaktów przechowuje poszczególne osoby. Tabela potencjalnych klientów przechowuje osoby zainteresowane przed przekształceniem ich w klientów. Tabela zgłoszeń przechowuje prośby o wsparcie, a tabela działań pozwala śledzić pracę, taką jak telefony i maile, spotkania i zadania. To są tabele standardowe. Microsoft uwzględnia je, ponieważ większość firm musi śledzić klientów, ludzi, pracę i konwersacje. Nie musisz zaczynać od tworzenia nowej tabeli dla czegoś powszechnego, jeśli standardowa tabela już spełnia to zadanie. Ale każda firma ma też swoją własną specyfikę pracy. Firma szkoleniowa może potrzebować śledzenia kursów i certyfikatów. Firma z branży nieruchomości może potrzebować budynków, lokali i inspekcji. Producent może śledzić kontrolę sprzętu lub wizyty serwisowe.

W takich przypadkach możesz tworzyć tabele niestandardowe, które pasują do pracy, jaką faktycznie wykonuje Twoja firma. Pomyśl o tabeli niestandardowej jak o dodaniu nowej szuflady do szafki, a następnie o patrzeniu jej wyraźną etykietą. Teraz każda tabela zawiera wiersze. Wiersz to jeden element w tej szufladzie. Na przykład jeden wiersz w tabeli kontaktów może reprezentować Marię Gome, osobę w firmie klienta. Jej wiersz zawiera jej własne dane, oddzielone od każdego innego kontaktu w systemie. Kolumny opisują szczegóły, które chcesz przechowywać dla każdego wiersza. Wiersz kontaktu Marii może mieć kolumny na jej imię, nazwisko, adres e-mail, numer telefonu, stanowisko, firmę, właściciela rekordu i status. Kolumna określa rodzaj informacji, który powinien znajdować się w danym miejscu. Dlatego kolumna e-mail oczekuje adresu e-mail, a kolumna statusu może przechowywać zatwierdzone opcje statusu.

W ten sposób informacje biznesowe zyskują niezawodny kształt. Bez kolumn jedna osoba może wpisać numer telefonu do pola notatek, inna dodać go do pola nazwiska, a jeszcze ktoś inny może go w ogóle nie wpisać. Dzięki przejrzystej tabeli kontaktów każdy pracuje z tym samym zestawem szczegółów w tych samych miejscach. Ta 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ć, gdy zmieni się właściciel. Informacje nie są tylko składowane bez ładu. Mają etykiety, które informują połączone narzędzia, co oznacza każda część. Zacznij od tabel standardowych, kiedy tylko pasują one do Twoich potrzeb biznesowych. Jeśli sprzedajesz firmom, konta i kontakty opisują już schemat, który większość ludzi rozumie. Jeśli zajmujesz się wsparciem klienta, zgłoszenia dają Ci punkt wyjścia. Następnie dodawaj tabele niestandardowe tylko tam, gdzie Twoja firma posiada informacje, które nie pasują do wbudowanych schematów.

Pozwala to uniknąć częstego problemu, czyli tworzenia pięciu różnych tabel, które w praktyce oznaczają to samo klienta. Jeden zespół nazywa to klientem, inny główną bazą klientów, a trzeci partnerem kontaktowym. Wkrótce nikt już nie wie, z której tabeli powinien korzystać. Przejrzyste tabele standardowe i starannie nazwane tabele niestandardowe sprawiają, że system pozostaje zrozumiały dla kolejnych użytkowników. Kolejny etap polega na tym, by te szuflady zaczęły ze sobą współpracować. Kontakt przynależy do konta. Maria pracuje dla firmy Contozo. Zamiast ponownie wpisywać adres, numer telefonu i dane firmy Contozo w wierszu Marii, Dataverse tworzy relacje między tabelą kontaktów a tabelą kont. Maria jest powiązana z Contozo i to powiązanie jest kluczowe, ponieważ informacje o firmie pozostają przypisane do firmy. Jeśli Contozo zmieni adres biura, wystarczy raz zaktualizować wiersz konta.

Każdy powiązany kontakt nadal wskazuje na tę samą firmę, bez konieczności przechowywania własnej, przestarzałej kopii danych. Relacje łączą również zgłoszenie do pomocy technicznej z klientem, który je zgłosił. Mogą też łączyć szansę sprzedaży z rozmowami, e-mailami, spotkaniami i zadaniami dotyczącymi tej transakcji. Gdy sprzedawca otwiera szansę sprzedaży, widzi powiązane z nią działania, zamiast przeszukiwać niepowiązane notatki i kalendarze. Informacje zyskują kontekst. Nie patrzysz tylko na numer zgłoszenia. Widzisz, do którego klienta ono należy. Nie wyświetlasz tylko kontaktu. Widzisz firmę powiązaną z tą osobą. Dzięki tym powiązaniom dane są użyteczne, bez konieczności wielokrotnego wpisywania tych samych faktów w różnych miejscach. Jedna mała uwaga dotycząca nazewnictwa, zanim zaczniesz czytać starsze przewodniki lub oglądać starsze filmy. Możesz usłyszeć określenia encja, pole i rekord.

To starsze terminy używane w Dataverse. Microsoft używa teraz określenia tabela zamiast encja, kolumna zamiast pole oraz wiersz zamiast rekord. Ich znaczenie się nie zmieniło. Jeśli starszy przewodnik zaleca utworzenie encji, chodzi po prostu o utworzenie tabeli. Pole to kolumna, a rekord to wiersz. Znajomość obu zestawów terminów uchroni Cię przed błędnym przekonaniem, że to inny produkt. Zatem tabele porządkują informacje, a relacje łączą je ze sobą. Jednak dobrze zorganizowana szafka nadal wymaga odpowiedniej kontroli. Ktoś musi zdecydować, co użytkownicy mogą wprowadzać, zmieniać i do czego mają bezpieczny dostęp. To zasady i recepcja zarządzające danymi. Współdzielenie danych działa tylko wtedy, gdy odpowiednie osoby mogą z nich bezpiecznie korzystać. Przedstawiciel handlowy potrzebuje szczegółów dotyczących klienta. Agent wsparcia potrzebuje historii zgłoszeń. Manager potrzebuje 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 zawierającym prywatną notatkę, wynegocjowaną cenę i otwarte zgłoszenie do pomocy technicznej. Przyznanie każdemu użytkownikowi pełnego dostępu wiąże się z dużym ryzykiem. Zbyt duże ograniczenia utrudniające pracę stwarzają inny problem. Dataverse oferuje narzędzia kontroli w tym zakresie. Pierwszym elementem kontroli jest tożsamość. Kiedy logujesz się kontem firmowym, Microsoft EntraID potwierdza Twoją tożsamość. Potraktuj 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, by wiedzieć, który użytkownik pracuje z danymi. Nie kończy się to tylko na pytaniu, czy ta osoba ma prawo wstępu. System sprawdza też, co dana osoba może robić po wejściu. Właśnie tutaj wkraczają role zabezpieczeń. Rola zabezpieczeń to zestaw uprawnień powiązanych ze stanowiskiem lub obowiązkami.

Możesz utworzyć rolę dla zespołu sprzedaży, inną dla obsługi klienta i kolejną dla menedżerów. Każda rola pozwala kontrolować dostęp do tabeli. Na przykład handlowiec 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. Agent wsparcia może tworzyć i aktualizować zgłoszenia, ale nie zmieniać szansy sprzedaży. Uprawnienia mogą obejmować odczyt, tworzenie, modyfikowanie i usuwanie wierszy. Oznacza to, że dostęp nie zależy od tego, czy ktoś pamięta, 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 zawęzić jeszcze bardziej. Zabezpieczenia na poziomie wiersza określają, z którymi konkretnymi wierszami może pracować użytkownik. Handlowiec może widzieć tylko swoich klientów, podczas gdy kierownik sprzedaży widzi wiersze wszystkich członków swojego zespołu.

Obie osoby korzystają z tej samej tabeli kont. Po prostu nie widzą tego samego wycinka danych. Taka konfiguracja pomaga skupić się na pracy, zapewniając menedżerom niezbędny wgląd. Zmniejsza to również ryzyko, że ktoś uzyska dostęp do informacji 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 dla potrzeb wykonywanej pracy. 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 filie pracujące z różnymi grupami klientów. Jednostki biznesowe pomagają określić zasady dostępu w obrębie tych granic.

Nie oznacza to, że każda firma potrzebuje skomplikowanej mapy zabezpieczeń. Mały zespół może potrzebować jedynie kilku jasnych ról. Większa firma może potrzebować więcej warstw, ponieważ jej zespoły, regiony i zakresy odpowiedzialności są różne. Chodzi o to, że Dataverse może dopasować dostęp do tego, jak faktycznie działa firma. Kontrola dostępu chroni dane przed niepowołanymi osobami, ale reguły chronią również samą jakość tych danych. Reguła biznesowa może wymagać od kogoś podania numeru telefonu przed zapisaniem nowego kontaktu. Może sprawdzać warunek, na przykład wymagając podania przyczyny przy zamykaniu sprawy. Może również 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, podczas gdy inna je odrzuca.

Reguła jest przypisana do informacji biznesowych, a nie do jednego ekranu, który akurat je wyświetla. Dataverse może również uruchamiać logikę w tle, aby pomóc w zachowaniu spójności procesów biznesowych. Szczegół, który musisz zapamiętać, jest prosty. Dane wiążą się z regułami, a nie tylko z miejscem przechowywania. Fundament obejmuje więc informacje osoby uprawnione do pracy z nimi oraz reguły, które utrzymują ich użyteczność. Gdy Dynamics 365 opiera się na tym samym fundamencie, nie potrzebuje tradycyjnego mostu, aby uzyskać dostęp do własnych danych biznesowych. Co tak naprawdę oznacza integracja Dynamics 365? Większość ludzi słyszy integracja Dynamics 365 z Dataverse i wyobraża sobie dwa oddzielne systemy połączone konektorem. Jeden system przechowuje dane klienta, drugi potrzebuje kopii, więc ktoś konfiguruje synchronizację, czeka na jej uruchomienie i ma nadzieję, że nic nie zawiedzie po drodze.

Ten obraz ma sens w przypadku wielu narzędzi biznesowych, ale tu chodzi o to, że w przypadku Dynamics 365 Sales i Dynamics 365 Customer Service połączenie jest znacznie głębsze. Te aplikacje używają Dataverse jako wspólnego fundamentu danych. Nie są to oddzielne bazy danych przesyłające rekordy klientów w te i z powrotem, aby się zrozumieć. Od początku pracują na tych samych informacjach biznesowych. Wyobraźmy sobie to.

Jesteś sprzedawcą i tworzysz nową firmę w Dynamics 365 Sales. Dodajesz główny kontakt i zaczynasz pracować nad potencjalną transakcją. Te szczegóły natychmiast stają się częścią współdzielonych danych, z których korzysta aplikacja. Później ten klient kontaktuje się z pomocą techniczną. Pracownik wsparcia może pracować z dokładnie tymi samymi danymi firmy i kontaktu. Nikt nie musi eksportować listy ze sprzedaży ani tworzyć klienta ponownie w osobnym narzędziu wsparcia. Agent po prostu łączy sprawę wsparcia z tym klientem i widzi historię, która pomaga mu zrozumieć, co się dzieje. Dział sprzedaży widzi transakcję. Dział wsparcia widzi sprawę, a oba zespoły pracują wokół tego samego klienta. To nie oznacza, że każdy ekran wygląda identycznie albo że każdy zespół stosuje ten sam proces. Dział sprzedaży potrzebuje leadów, szans sprzedaży, rozmów i spotkań. Obsługa klienta wymaga zgłoszeń, wskazówek i historii usług.

Każda aplikacja Dynamics 365 daje ludziom narzędzia stworzone do ich pracy, podczas gdy leżące u podstaw dane biznesowe mogą łączyć się wszędzie, gdzie to konieczne. Ten wspólny fundament jest tym, co 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 aplikacje pracujące na tych samych wierszach, relacjach, regułach i kontroli dostępu. Na początek przeprowadźmy biura przez prostą ścieżkę sprzedaży. Potencjalny klient pojawia się na stronie internetowej lub wydarzeniu. Sprzedawca pracuje z tym klientem, dowiaduje się więcej o osobie i przekształca potencjalnego klienta w relację biznesową i szansę sprzedaży. Rozmowy i maile, spotkania i zadania mogą być połączone 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 nie widzi tylko imienia, nazwiska i adresu e-mail. Może pracować w kontekście już zidentyfikowanej relacji z klientem. W międzyczasie zespół sprzedaży widzi, że klient ma otwarty problem serwisowy i unika wchodzenia w rozmowę o odnowieniu umowy bez wiedzy o jego problemach. Jedna relacja z klientem może wspierać różne rodzaje pracy. To znacznie bardziej użyteczne niż tylko utrzymywanie pasującej nazwy klienta w dwóch systemach. Możesz również usłyszeć określenie Common Data Model, czasem skracane do CDM. Nie pozwól, aby ta nazwa brzmiała bardziej tajemniczo niż jest w rzeczywistości. Oznacza to po prostu, że Microsoft dostarcza wspólne wzorce tabel biznesowych dla rzeczy, które śledzi wiele firm, takich jak konta, kontakty, aktywności i zgłoszenia. Te wzorce dają aplikacjom opartym na Dynamics 365 i Dataverse wspólny język początkowy. Konto oznacza firmę. Kontakt oznacza osobę.

Aktywność śledzi pracę wokół relacji biznesowej. Możesz dostosować konfigurację do swojej firmy i dodawać własne tabele w razie potrzeby, ale nie musisz za każdym razem zaczynać od zera. Gdy jedna aplikacja rozumie tabelę konta, a druga używa tej samej tabeli, obie odnoszą się do tego samego typu informacji biznesowych. To zmienia również możliwości budowania rozwiązań. Załóżmy, że Twój zespół terenowy potrzebuje prostej aplikacji do wyszukania klienta, potwierdzenia wizyty i dodania notatki po spotkaniu. Możesz zbudować PowerApp, która współpracuje z tymi samymi tabelami Dataverse używanymi już przez 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ż dział sprzedaży lub obsługi klienta, zgodnie z omówionymi wcześniej zasadami bezpieczeństwa.

Do bardziej ustrukturyzowanych zadań biznesowych można zbudować aplikację opartą na modelu Model Driven App. Aplikacja oparta na modelu rozpoczyna się od modelu danych. Wybierasz tabelę usługi Dataverse, definiujesz ich relacje, konfigurujesz formularze i widoki oraz przypisujesz rolę zabezpieczeń. Następnie PowerApps wykorzystuje tę strukturę, aby stworzyć działające środowisko aplikacji biznesowej. Wyobraź sobie to jako organizowanie stołu warsztatowego wokół narzędzi i materiałów, których faktycznie używa Twój zespół. Tabele opisują wykonywaną pracę, relacje łączą poszczególne elementy, formularze zapewniają miejsce do wprowadzania i przeglądania szczegółów, widoki pomagają odnaleźć wiersze wymagające 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 pełny proces sprzedaży, podczas gdy mniejsza aplikacja oparta na modelu daje kierownikom kontraktów dedykowane miejsce do śledzenia umów z klientami.

Oczywiście taki dostęp nadal wymaga odpowiedniej kontroli. 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ę. Dostęp do wierszy na podstawie ról oraz reguły biznesowe nadal kontrolują to, co się dzieje. Aplikacja terenowa może zapewnić komuś dokładnie te dane klienta i działania, których potrzebuje bez ujawniania reszty danych firmy. Integracja Dynamics 365 z Dataverse jest teraz jak kabel łączący dwa odległe pomieszczenia. Aplikacje Dynamics 365, aplikacje niestandardowe i procesy biznesowe mogą działać w oparciu o ten sam wspólny fundament. Gdy już to dostrzeżesz, kolejne pytanie staje się oczywiste. Co jeszcze może wykorzystać tę samą aktualizację klienta w ramach połączonej platformy Microsoft? Jak połączona platforma sprawdza się w rzeczywistej pracy? Wspólna aktualizacja danych klienta staje się przydatna, gdy otaczające ją narzędzia mogą na nią zareagować.

Power Automate zajmuje się pracą następczą, obserwując zmiany w wierszu Dataverse i uruchamiając odpowiednie działanie, gdy taka zmiana nastąpi. Na przykład nowy potencjalny klient trafia do Dynamics 365 Sales. Przepływ Flow może powiadomić przypisanego sprzedawcę, wysłać wiadomość w Teams lub utworzyć zadanie kontrolne. Nikt nie musi przez cały dzień sprawdzać współdzielonej skrzynki odbiorczej. Status klienta zmienia się, a kolejny krok uruchamia się automatycznie. Power Automate nie potrzebuje oddzielnej kopii danych klienta, aby wykonać tę pracę. Może reagować na wiersz w Dataverse, używając tych samych danych klienta i właściciela, z których korzysta aplikacja sprzedażowa. Dzięki temu automatyzacja pozostaje blisko procesu biznesowego, zamiast polegać na ręcznym eksporcie plików i wymianie e-maili. Następnie mamy Power B. Manager sprzedaży może chcieć zobaczyć aktualny lejek sprzedaży.

Kierownik działu obsługi klienta może chcieć sprawdzić, ile zgłoszeń wpłynęło w tym tygodniu, które z nich są nadal otwarte lub którzy klienci najczęściej kontaktują się z pomocą techniczną. Power B może tworzyć raporty na podstawie danych biznesowych z Dataverse, dzięki czemu zespoły widzą postępy prac bez konieczności tworzenia nowych arkuszy kalkulacyjnych w każdy piątek. Raport korzysta z danych biznesowych, których pracownicy już używają. Oznacza to, że wykres lejka sprzedaży zmienia się wraz z postępami w realizacji szans sprzedaży. Pulpit nawigacyjny zgłoszeń pokazuje bieżące obciążenie pracą w miarę aktualizacji spraw przez agentów. Chodzi o to, że pulpit nawigacyjny zastępuje ręczne sprawdzanie szczegółów przez pracowników. Daje im to 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 siedziby klienta.

Nie potrzebuje on pełnego środowiska Dynamics 365 Sales. Być może musi tylko znaleźć klienta, przejrzeć szczegóły wizyty, potwierdzić przebieg prac i dodać notatkę lub zdjęcie. Skoncentrowana aplikacja Power App może zapewnić mu takie ograniczone środowisko. Zespół do spraw. Kluczowych klientów może potrzebować aplikacji do przeglądania umów z klientami. Kierownik 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 widzi narzędzie dopasowane do jego codziennych zadań. Firma zachowuje połączone informacje. Czasami te informacje pochodzą spoza Dataverse. Firma może posiadać listę z zewnętrznego źródła online, która powinna stać się częścią jej danych biznesowych. Power Query potrafi pobrać dane ze wspieranych źródeł online, oczyścić je podczas importu i załadować do odpowiedniej tabeli w Dataverse.

Jest to przydatne, gdy zewnętrzne źródło zawiera informacje potrzebne narzędziom Dynamics i Power Platform. Nadal musisz zdecydować, co powinno znaleźć się w Dataverse i jak powinno łączyć się z istniejącymi tabelami. Importowanie danych bez takiego przemyślenia po prostu przenosi chaos w nowe miejsce. Złóżmy te elementy w jeden codzienny przepływ pracy. Nowy potencjalny klient trafia do Dynamics 365. Reguła przypisywania sprawdza, kto powinien zająć się tym potencjalnym klientem, być może na podstawie regionu lub produktu. Właściciel otrzymuje wiadomość w usłudze Teams za pośrednictwem przepływu Power Automate, dzięki czemu wie, że czeka na niego praca. Gdy handlowiec aktualizuje status i prowadzi potencjalnego klienta przez proces sprzedaży, pulpit nawigacyjny Power B zmienia się, pokazując zespołowi aktualny lejek sprzedaży. Jedna aktualizacja uruchamia użyteczne działania w kilku miejscach.

Power Automate przesuwa pracę z jednego etapu do kolejnego. Power B pomaga pracownikom monitorować postępy. Power Apps daje konkretnym zespołom ukierunkowany sposób na uczestnictwo w procesie. Dataverse dba o to, by dane biznesowe były uporządkowane i bezpieczne, podczas gdy te narzędzia wykonują swoją pracę. Ta różnica ma znaczenie. Automatyzacja nie jest systemem archiwizacji, a pulpit nawigacyjny nie jest bazą danych klientów. Każde narzędzie ma swoje zadanie, ale wszystkie mogą korzystać z tego samego źródła. Ta wiedza pomaga wybrać właściwe narzędzie, zamiast traktować każdy arkusz czy listę jak fundament procesu biznesowego.

Oto w czym rzecz. Wybierz Dataverse, gdy wiele osób i aplikacji musi pracować na powiązanych 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 sprawdzają się w prostym śledzeniu zadań zespołowych. A jeśli jesteś programistą wymagającym pełnej kontroli, SQL pozostaje silnym wyborem. Kiedy więc Dataverse naprawdę pasuje? Gdy dane muszą łączyć się między Dynamics 365, aplikacjami, automatyzacją i raportami bez tworzenia kopii. Właśnie w tym błyszczy podsumowanie jedna podstawa wiele narzędzi biznesowych. Oto najważniejszy wniosek. Dynamics 365 i Dataverse działają najlepiej, gdy dane, reguły, zabezpieczenia, aplikacje, automatyzacja i raporty dzielą wspólny fundament. Subskrybuj Microsoft Knowledge Nugget na M365FM, aby uzyskać więcej prostych przewodników po Dynamics 365, Power Platform i Microsoft 365.

Obejrzyj odcinek o aplikacjach modelowych, aby zobaczyć jak tabele Dataverse zmieniają się w działającą aplikację biznesową.