Ласкаво просимо до Microsoft Knowledge Nuggets. Я Мо Пітерс. Сьогоднішня тема часто викликає запитання. Що саме таке Dataverse? Це база даних, додаток чи якась прихована служба Dynamics 365, яку мають розуміти лише IT-фахівці. Ось найпростіше визначення. Dataverse – це спільна основа даних для багатьох можливостей Dynamics 365. Уявіть Dynamics 365 як офісну будівлю. Продажі, обслуговування клієнтів та інші додатки – це кабінети, де працюють люди, а Dataverse – це система архівування та правила за стінами. Наприкінці цього епізоду ви дізнаєтеся, де зберігаються дані Dynamics і як оновлення інформації про клієнта з'являється в продажах, автоматизації та звітності. Але перш ніж перейти до назв продуктів, почнімо з робочого безладу. Це вирішується одним спільним місцем. Замість окремих копій уявіть компанію з відділом продажів, службою підтримки та фінансовим відділом. Відділ продажів тримає дані клієнтів у електронній таблиці.

Підтримка працює в окремій системі тікетів. Фінанси мають імена клієнтів у своїй власній системі. Хтось інший зберігає листування у спільній поштовій скринці, а ще хтось веде нотатки в папці, яку ніхто не може знайти. Один і той самий клієнт тепер існує у п'яти місцях. Спочатку така організація здається нормальною, бо кожен відділ бачить лише ту частину роботи, яка перед ними. Але ось у чому річ. Як тільки клієнт змінює номер телефону, адресу, назву компанії або головний контакт, починаються проблеми. Відділ продажів оновлює таблицю. Підтримка цього не бачить. Фінанси продовжують надсилати документи на стару адресу. Тоді хтось експортує список, вручну його виправляє, розсилає електронною поштою і раптом троє людей вважають, що саме їхня копія правильна. Якому списку вірити? Це питання забирає більше часу, ніж ви могли б подумати. Персонал зупиняється, щоб звірити записи. Менеджери запитують, чому звіт не збігається з системою продажів.

Агент підтримки відкриває справу для клієнта, чиї дані вже лежать де-інде, просто з невеликими відмінностями. Ніхто не намагається створити хаос. Хаос виникає через копії. 20-ть років тому окремі системи означали окремі сервери, окремі бази даних і окремі команди, що зберігали власну інформацію. Для їхнього з'єднання потрібна була індивідуальна розробка, запланований імпорт і багаторучної перевірки. Зміна в одному місці могла дійти до іншої системи завтра, наступного тижня або ніколи. Dataverse надає бізнес-додаткам спільне місце для такого типу інформації. Простими словами, Dataverse – це хмарна платформа даних Microsoft для бізнес-інформації. Вона зберігає цю інформацію в структурованих таблицях, тому дані мають чітку форму, а не існують як випадкові нотатки, окремі файли чи розрізнені вкладки в електронних таблицях. Можна уявити це як корпоративну картотеку, якою можуть одночасно користуватися кілька схвалених інструментів.

Клієнт з'являється в Dataverse лише один раз. Цей клієнт може відображатися в Dynamics 365 Sales, коли менеджер працює над угодою. Ті самі дані клієнта можуть з'явитися в Dynamics 365 Customer Service, коли агент опрацьовує запит у службу підтримки. Pava App може використовувати ту саму інформацію про клієнта для виїзного працівника або менеджера облікового запису без необхідності попереднього копіювання даних у новий застосунок. Один рядок клієнта – одна спільна точка відліку. Це не означає, що кожна команда раптом бачить усе. Доступ все одно потребує правил, і невдовзі ми до цього перейдемо. Це означає, що схвалені застосунки можуть працювати з однією бізнес-інформацією замість створення власних конкурентних версій. Ось чому Dynamics 365 і Dataverse так природно поєднуються. Застосунки Dynamics 365, такі як Sales і Customer Service, використовують Dataverse для зберігання та захисту даних, з якими вони працюють.

Але ось у чому річ. Коли хтось говорить про інтеграцію Dynamics 365 з Dataverse, вони часто уявляють два окремі продукти, яким потрібен конектор між ними. Для багатьох застосунків Dynamics 365 це не так. Дані вже знаходяться в Dataverse. Ви не витягуєте список клієнтів з Dynamics 365, щоб скопіювати його в іншу базу даних і сподіватися, що обидві сторони залишаться актуальними. Ви можете будувати на тому самому фундаменті, використовуючи ту саму бізнес-інформацію, яку вже використовує Dynamics 365. Це змінює предмет розмови. Замість питання, як нам синхронізувати ці два списки клієнтів. Ви можете запитати, які люди та застосунки мають працювати з цим записом клієнта і що дозволено робити кожному з них. Звісно, Dataverse не замінює кожну систему, якою володіє компанія. Бізнес може і надалі використовувати фінансове програмне забезпечення, галузеві інструменти, складські системи, веб-сайти чи старі застосунки, що зберігають власні дані.

Dataverse – це немагічний клей, який миттєво усуває всі зовнішні системи. Він надає спільне місце для бізнес-даних, які мають використовувати підключені застосунки. Дані клієнтів – робота з продажами, підтримка, завдання та подальші дії. Ці записи можуть співіснувати в одному джерелі, яке схвалені інструменти можуть вчитувати та оновлювати. Отже, відкрийте зі мною цю картотеку. Щойно ви побачите, як Dataverse впорядковує інформацію всередині, весь зв'язок з Dynamics 365 стане набагато легше зрозуміти. Таблиці, рядки, стовпці та зв'язки. Давайте відкриємо цю картотеку. У середині Dataverse інформація розміщується в таблицях. Уявіть це як справжню шафу з окремими висувними шухлядами. В одній шухляді зберігаються компанії, в іншій – люди, а в третій – запити до служби підтримки. Ви ж не кидаєте всі папери в одну величезну шухляду в надії, що хтось потім їх розсортує. У кожної шухляди є своє призначення.

Отже, у Dataverse таблиця містить один тип бізнес-інформації. Таблиця облікових записів зазвичай містить компанії, з якими ви працюєте. Таблиця контактів містить окремих людей. Таблиця потенційних клієнтів Ліди зберігає дані про них до того, як вони стануть реальними покупцями. Таблиця звернень містить запити на підтримку, а таблиця дій може відстежувати роботу, як-от дзвінки, листи, зустрічі та завдання. Це стандартні таблиці. Microsoft включає їх, оскільки більшості компаній потрібно відстежувати клієнтів, людей, роботу та спілкування. Вам не потрібно починати зі створення нової таблиці для чогось типового, якщо стандартна вже підходить для цього. Але кожна компанія також має свою специфічну роботу. Тренінговій компанії може знадобитися відстеження курсів і сертифікатів. Компанії з нерухомості можуть знадобитися будівлі, об'єкти та перевірки. Виробник може відстежувати перевірки обладнання або сервісні візити.

У таких випадках ви можете створити власні таблиці, які відповідають реальній роботі вашої компанії. Уявіть власну таблицю, як додавання нової шухляди до шафи з чітким маркуванням. Тепер кожна таблиця містить рядки. Рядок – це один елемент у цій шухляді. Наприклад, один рядок у таблиці контактів може представляти Марію Гомес, людину з компанії-клієнта. Її рядок містить її власні дані, відокремлені від усіх інших контактів у системі. Стовпці описують деталі, які ви хочете зберегти для кожного рядка. Рядок контакту Марії може мати стовпці для її імені, прізвища, адреси електронної пошти, номера телефону, посади, компанії, власника запису та статусу. Стовпець визначає тип інформації, яка має бути в цьому місці. Отже, стовпець електронної пошти очікує адресу, а стовпець статусу може містити затверджені варіанти статусу. Саме так бізнес-інформація набуває надійної структури. Без стовпців один працівник може ввести номер телефону в поле приміток, інший – у поле імені, а хтось інший може взагалі його не ввести.

З чіткою таблицею контактів усі працюють з однаковим набором даних у тих самих місцях. Ця структура також допомагає програмам розуміти дані. Форма може показувати потрібні поля, звіт може групувати контакти за статусом, а автоматизація може реагувати на зміну власника. Інформація не просто зберігається десь. Вона має мітки, які повідомляють підключеним інструментам, що означає кожна частина. Починайте зі стандартних таблиць, коли вони відповідають потребам вашого бізнесу. Якщо ви продаєте компаніям, облікові записи та контакти вже описують модель, зрозуміло, більшості людей. Якщо ви займаєтеся підтримкою клієнтів, звернення стануть для вас відправною точкою. Потім додавайте власні таблиці лише тоді, коли у вашому бізнесі є інформація, що не вписується у вбудовані моделі. Це дозволяє уникнути поширеної проблеми, коли створюється п'ять різних таблиць, що означають одне й те саме клієнта. Одна команда називається «Клієнт», інша – «Основні дані клієнта», третя – «Контакт партнера».

Невдовзі люди вже не можуть розібратися, яку таблицю слід використовувати. Зрозумілі стандартні таблиці та ретельно названі власні таблиці роблять структуру зрозумілою для інших під час розширення системи. Наступний етап – це коли ці «шухляди» починають працювати разом. Контакт належить до облікового запису. Марія працює в компанії «Контосо». Замість того, щоб знову вводити адресу, основний номер телефону та реквізити компанії «Контосо» у запис Марії, Dataverse може створити зв'язок між таблицею контактів і таблицею облікових записів. Марія пов'язана з «Контосо», і цей зв'язок важливий, оскільки інформація про компанію залишається прикріпленою до неї. Якщо в «Контосо» змінюється адреса офісу, хтось один раз оновлює рядок облікового запису. Усі пов'язані контакти продовжують вказувати на одну і ту саму компанію, не зберігаючи власну застарілу копію. Зв'язки також з'єднують запит на підтримку з клієнтом, який його подав.

Вони можуть пов'язати торговельну можливість із дзвінками, електронними листами, зустрічами та завданнями щодо цієї угоди. Коли продавець відкриває можливість, він бачить пов'язану з нею активність, замість того, щоб шукати її в непов'язаних нотатках і календарях. Інформація має контекст. Ви дивитеся не просто на номер справи. Ви бачите, до якого клієнта вона належить. Ви не просто переглядаєте контакт. Ви бачите компанію, пов'язану з цією особою. Ці зв'язки роблять дані корисними без необхідності багаторазового введення одних і тих самих фактів у різних місцях. Одна невелика примітка щодо термінології перед тим, як ви читатимете старі посібники або дивитиметеся старі відео. Ви можете почути слова «сутність поле» та «запис». Це старі терміни Dataverse. Microsoft тепер використовує таблиця «замість сутність стовпець», «замість поле» та «рядок», «замість запис». Значення не змінилося. Тож, якщо в старому посібнику сказано «створити сутність», це означає створення таблиці.

Поле – це стовпець, а запис – це рядок. Розуміння обох варіантів термінів береже вас від думки, що ви знайшли інший продукт. Отже, таблиці впорядковують інформацію та зв'язки між нею. Але добре впорядкована шафа все одно потребує контролю. Хтось має вирішувати, що користувачі можуть вводити, змінювати та до чого мають безпечний доступ. Це правила та стіл реєстрації для даних. Спільні дані ефективні лише тоді, коли потрібні люди можуть безпечно з ними працювати. Торговому представнику потрібні дані клієнта. Агенту підтримки потрібна історія запитів. Керівнику потрібен ширший огляд. А зовнішньому партнеру може знадобитися доступ лише до невеликої частини процесу. Вони не повинні бачити одну і ту саму інформацію. Уявіть запис клієнта з приватною нотаткою, узгодженою ціною та відкритим запитом на підтримку. Надання всім користувачам повного доступу швидко створило бризики. Надто жорсткі обмеження, через які люди не можуть виконувати свою роботу, створюють іншу проблему.

Dataverse надає вам засоби контролю для цього. Перший засіб контролю починається з ідентифікації. Коли ви входите у систему зі своїм корпоративним обліковим записом, Microsoft EntraID ідентифікує вас. Уявіть EntraID як стійку реєстрації на вході в офіс. Ви приходите, показуєте свій бейдж, і реєстратор перевіряє, хто ви, перш ніж ви зможете увійти. Dataverse використовує цю ідентифікацію, щоб знати, який саме користувач працює з даними. Це не обмежується лише питанням, чи дозволено цій людині вхід. Це також запитує, що цій людині дозволено робити після входу. Саме тут у гру вступають ролі безпеки. Роль безпеки – це набір дозволів, пов'язаних із роботою або обов'язками. Ви можете створити одну роль для торгового персоналу, іншу для агентів служби підтримки, а третю для менеджерів. Кожна роль може контролювати доступ до таблиці. Наприклад, торговому представнику може бути дозволено читати, створювати й оновлювати облікові записи, контакти, ліди та можливості.

Їм може бути заборонено видаляти важливу інформацію про клієнтів. Агент підтримки може створювати та оновлювати звернення, але не може змінювати торгову можливість. Дозволи можуть охоплювати читання, створення, зміну та видалення рядків. Це означає, що доступ не залежить від того, чи пам'ятає хтось, які кнопки слід приховати в кожному додатку. Дозволи зберігаються разом із самими даними. Отже, однакові правила діють всюди, де відображаються дані Dataverse. Потім ви можете ще більше звузити доступ. Безпека на рівні рядків визначає, з якими окремими рядками може працювати людина. Торговий представник може бачити лише власних клієнтів, тоді як менеджер з продажу може бачити рядки клієнтів усієї своєї команди. Обидві особи використовують одну і ту саму таблицю облікових записів. Вони просто не бачать одну і ту саму її частину. Таке налаштування допомагає людям зосередитися на власній роботі, надаючи менеджерам потрібний огляд.

Це також зменшує ймовірність того, що хтось відкриє інформацію про клієнта, до якої немає жодного стосунку. Деяка інформація потребує ще суворішого захисту. Безпека на рівні стовпців може захистити окремі стовпці всередині таблиці. Можливо, користувач може відкрити рядок клієнта, але не повинен бачити персональний ідентифікатор, зарплату, банківські реквізити чи приватну фінансову примітку. Рядок клієнта залишається доступним для виконання необхідної роботи. Захищений стовпець залишається обмеженим для перегляду. Для великих компаній бізнес-одиниці можуть створювати межі між частинами організації. Компанія може розділяти регіони, підрозділи або дочірні компанії, що працюють з різними групами клієнтів. Бізнес-одиниці допомагають формувати спосіб доступу через ці межі. Це не означає, що кожному бізнесу потрібна складна карта безпеки. Невеликій команді може знадобитися лише кілька чітких ролей.

Великій компанії може знадобитися більше рівнів через відмінності в командах, регіонах та обов'язках. Суть у тому, що Dataverse може адаптувати доступ до того, як насправді працює бізнес. Контроль доступу захищає від того, хто може отримати дані, але правила також захищають якість самих даних. Бізнес-правило може вимагати від когось введення номера телефону перед збереженням нового контакту. Воно може перевірити умову, наприклад, вимагати причину при закритті звернення. Воно також може змінювати те, що бачать користувачі на основі введеної ними інформації. Це саме правило діє в усіх програмах, що використовують цю таблицю. Це важливо, оскільки ви не хочете, щоб одна програма приймала неповні дані, а інша відхиляла їх. Правило належить до бізнес-інформації, а не до одного екрана, на якому вона відображається. Dataverse також може виконувати логіку у фоновому режимі, щоб забезпечити послідовність бізнес-процесів.

Деталь, яку варто запам'ятати, проста. Дані надходять разом із правилами, а не просто як сховище. Отже, фундамент включає інформацію, людей, яким дозволено з нею працювати, і правила, що підтримують її придатність до використання. Коли Dynamics 365 працює на тому самому фундаменті, їй не потрібен традиційний міст лише для доступу до власних бізнес-даних. Що насправді означає інтеграція Dynamics 365, більшість людей чують, інтеграція Dynamics 365 з Dataverse, і уявляють дві окремі системи, з'єднані конектором. Одна система зберігає дані клієнта, іншій потрібна копія, тому хтось налаштовує синхронізацію, чекає її виконання і сподівається, що нічого не зламається. Ця картина має сенс для багатьох бізнес-інструментів. Але ось у чому справа. Для Dynamics 365 Sales та Dynamics 365 Customer Service зв'язок набагато тісніший. Ці програми використовують Dataverse як свій спільний фундамент даних.

Це не окремі бази даних, що передають записи клієнтів туди-сюди, лише щоб порозумітися. Вони працюють з однією і тією ж бізнес-інформацією від самого початку. Ось приклад. Ви – менеджер із продажів і створюєте нову компанію в Dynamics 365 Sales. Ви додаєте головний контакт і починаєте працювати над потенційною угодою. Ці деталі миттєво стають частиною спільних даних, які використовує програма. Пізніше цей клієнт звертається до служби підтримки. Агент підтримки може працювати з тими ж даними компанії та контакту. Нікому не потрібно експортувати список із продажів або створювати клієнта знову в окремому інструменті підтримки. Агент просто підключає звернення до цього клієнта і бачить історію, яка допомагає зрозуміти, що відбувається. Відділ продажів бачить угоду. Відділ підтримки бачить звернення і обидві команди працюють з одним клієнтом. Це не означає, що кожен екран виглядає ідентично або кожна команда дотримується одного і того самого процесу.

Відділу продажів потрібні ліди, можливості, дзвінки та зустрічі. Служба підтримки клієнтів потребує звернень, черг та історії обслуговування. Кожен додаток Dynamics 365 надає людям інструменти, створені для їхньої роботи. При цьому бізнес-інформація в основі може підключатися всюди, де це необхідно. Ця спільна основа – це те, що люди часто мають на увазі, коли говорять про інтеграцію Dynamics 365 та Dataverse. Це не лише перенесення даних з точки А в точку будинок, це про те, як додатки працюють з одними і тими самими рядками, зв'язками, правилами та контролем доступу. Для початку дозвольте офісам пройти через простий шлях продажу. Лід надходить з вебсайту або заходу. Продавець працює з цим лідом, дізнається більше про людину та перетворює лід на клієнтські відносини та можливість. Дзвінки, електронні листи, зустрічі та завдання можуть бути пов'язані з цією роботою. Отже, команді не потрібно шукати в окремих інструментах, щоб зібрати історію докупи.

Якщо клієнту пізніше знадобиться допомога, звернення до підтримки може бути пов'язане з тим самим клієнтом. Агент підтримки не просто бачить ім'я та адресу електронної пошти. Він може працювати в контексті вже визначених клієнтських відносин. Тим часом відділ продажів бачить, що у клієнта є відкрита проблема і може уникнути розмови про поновлення, не знаючи про минулі труднощі. Одні клієнтські відносини можуть підтримувати різні види роботи. Це набагато корисніше, ніж просто мати однакове ім'я клієнта у двох системах. Ви також можете почути термін «Спільна модель даних – Command Data Model», іноді скорочену CDM. Не дозволяйте назві звучати таємничіше, ніж є насправді. Це просто означає, що Microsoft надає загальні шаблони бізнес-таблиць для речей, які відстежують багато компаній, як-от облікові записи, контакти, дії та звернення. Ці шаблони дають додаткам на базі Dynamics 365 та Dataverse спільну мову для старту.

Обліковий запис означає компанію. Контакт означає людину. Дія відстежує роботу навколо ділових відносин. Ви можете налаштувати систему для своєї компанії та додавати власні таблиці, де потрібно, але вам не обов'язково щоразу починати з чистого аркуша. Коли один додаток розуміє таблицю облікових записів, а інший використовує ту саму таблицю, обидва звертаються до одного типу бізнес-даних. Це також змінює можливості розробки. Припустимо, вашій виїздній команді потрібен простий додаток, щоб знайти клієнта, підтвердити візит і додати нотатку після зустрічі. Ви можете створити Pava App, який працює з тими самими таблицями Dataverse, що вже використовується в Dynamics 365. Немає потреби експортувати клієнтів у новий список лише для цього додатка. Працівник на виїзді відкриває додаток, знаходить клієнта та оновлює інформацію про візит. Дані залишаються пов'язаними з клієнтськими відносинами, які вже використовує відділ продажів або обслуговування, згідно з правилами безпеки, про які ми говорили раніше.

Для більш структурованих бізнес-завдань ви можете створити модельний додаток. Модельний додаток починається з моделі даних. Ви обираєте таблиці Dataverse, визначаєте їхні зв'язки, налаштовуєте форми і представлення та призначаєте ролі безпеки. PowerApps потім використовує цю структуру для створення робочого бізнес-додатку. Уявіться як організацію робочого місця відповідно до інструментів і матеріалів, які реально використовує ваша команда. Таблиці описують роботу. Зв'язки поєднують окремі елементи. Форми дають людям місце для введення та перегляду деталей. Представлення допомагають їм знаходити рядки, що потребують уваги. Безпека вирішує, що кожна людина може відкривати чи змінювати. Модельний додаток може працювати паралельно з Dynamics 365, оскільки обидва використовують Dataverse. Можливо, Dynamics 365 Sales керує повним процесом продажу, тоді як менший модельний додаток дає менеджерам із контрактів зосереджене місце для відстеження угод.

Обидва можуть працювати з пов'язаними даними клієнтів, не створюючи другу базу даних клієнтів. Звісно, такий доступ все одно потребує уваги. Те, що додаток може працювати з таблицею Dataverse, не означає, що кожен користувач повинен редагувати кожен рядок або бачити кожен стовпець. Рольовий доступ до рядків та бізнес-правила все ще контролюють те, що відбувається. Польовий додаток може надати комусь саме ті деталі клієнта та дії, які їм потрібні, не відкриваючи решту даних компанії. Отже, інтеграція Dynamics 365 з Dataverse – це тепер не кабель, що з'єднує дві віддалені кімнати. Додатки Dynamics 365 – спеціалізовані додатки та бізнес-процеси можуть працювати на одній спільній основі. Коли ви це бачите, наступне питання стає зрозумілим. Що ще може використовувати це ж оновлення клієнта на підключеній платформі Microsoft? Як підключена платформа працює в реальних умовах? Спільне оновлення клієнта стає корисним, коли інструменти навколо нього можуть реагувати.

Pava Otamite виконує подальшу роботу, відстежуючи зміни в рядку Dataverse і запускаючи дію, коли така зміна відбувається. Наприклад, новий лід потрапляє в Dynamics 365 Sales. Потік може сповістити призначеного продавця, надіслати повідомлення в Teams або створити завдання для подальшої роботи. Нікому не потрібно цілий день стежити за спільною поштовою скринькою. Лід змінюється і наступний крок запускається автоматично. Pava Otamite не потребує окремої копії ліда, щоб виконати цю роботу. Він може реагувати на рядок у Dataverse, використовуючи ті самі дані про клієнта та власника, який використовує додаток для продажів, і це наближає автоматизацію до бізнес-процесу, замість того, щоб покладатися на когось, хто має експортувати файл і запускати ланцюжок ручних листів. Крім того, існує Pava BI. Менеджеру з продажів може знадобитися побачити поточний стан воронки продажів. Менеджеру з обслуговування клієнтів може знадобитися побачити, скільки звернень надійшло цього тижня, які з них залишаються відкритими або які клієнти звертаються до служби підтримки найчастіше.

Pava BI може створювати звіти на основі бізнес-даних Dataverse, щоб команди бачили стан справ без створення нових експортів у таблиці щоп'ятниці. Звіт базується на бізнес-даних, які люди вже використовують. Це означає, що діаграма воронки продажів змінюється в міру просування можливостей. Інформаційна панель звернень може відображати поточне навантаження, поки агенти оновлюють справи. Суть у тому, що інформаційна панель замінює ручну перевірку деталей людьми. Вона дає їм чіткіше уявлення про роботу, перш ніж вони вирішать, що потребує уваги. Pava Apps додає ще один шлях до того самого процесу. Уявіть працівника, який прибуває на об'єкт до клієнта. Їм не потрібен повний досвід Dynamics 365 Sales. Можливо, їм потрібно лише знайти клієнта, переглянути деталі візиту, підтвердити, що сталося, і додати нотатку чи фото. Спеціалізований додаток Pava App може надати їм такий спрощений досвід. Команді з роботи з клієнтами може знадобитися додаток для перегляду клієнтських угод.

Керівнику може знадобитися простий додаток для затвердження запиту. Кожен додаток зосереджується на одній задачі, працюючи з тими самими контрольованими даними Dataverse у фоновому режимі. Людина бачить інструмент, який підходить для її щоденної роботи. Бізнес зберігає всю пов'язану інформацію. Іноді ця інформація спочатку знаходиться поза межами Dataverse. Компанія може мати список з онлайн-джерела, який має стати частиною її бізнес-даних. Pava Query може імпортувати дані з підтримуваних онлайн-джерел, очищати їх під час імпорту та завантажувати у відповідну таблицю Dataverse. Це корисно, коли зовнішнє джерело містить інформацію, необхідну для ваших інструментів Dynamics та Pava Platform. Вам все одно потрібно вирішити, що саме належить до Dataverse і як це має підключатися до існуючих таблиць. Імпорт даних без попереднього планування лише переносить плутанину в нове місце. Давайте об'єднаємо ці частини в один повсякденний робочий процес.

Новий потенційний клієнт потрапляє в Dynamics 365. Правило призначення визначає, хто має відповідати за цього клієнта, можливо, на основі регіону чи продукту. Власник отримує повідомлення в Teams через потік Pava Automate, щоб знати, що на нього чекає робота. Коли менеджер з продажу оновлює дані та просуває клієнта за процесом продажу, інформаційна панель Pava BI змінюється, показуючи команді поточний стан воронки. Одне оновлення запускає корисну роботу в кількох місцях одночасно. Pava Automate переміщує роботу з одного етапу на наступний. Pava BI допомагає людям бачити результати роботи. Pava Apps дає конкретним командам цілеспрямований спосіб долучитися до процесу. Dataverse зберігає бізнес-інформацію впорядкованою та захищеною, поки ці інструменти виконують свої завдання. Ця різниця має значення. Автоматизація – це не система архівування, а інформаційна панель – це не база даних клієнтів.

Кожен інструмент має свою окрему функцію, але всі вони можуть працювати з одним джерелом даних. Розуміння цього допомагає обрати правильний інструмент, замість того, щоб намагатися керувати бізнес-процесами за допомогою звичайних таблиць чи списків. Коли Dataverse підходить, найкраще і що він не замінює. Ось у чому справа. Обирайте Dataverse, коли декільком користувачам і додаткам потрібно працювати з пов'язаними бізнес-даними. Вам потрібні чіткі правила доступу та повторювані процеси. Dataverse впорається з цим, але він не замінює все інше. Excel залишається найкращим вибором для особистого аналізу та швидких списків. Списки SharePoint добре підходять для простого командного відстеження. А якщо ви розробник і потребуєте повного контролю, SQL залишається надійним вибором. Тож, коли Dataverse дійсно доречний. Коли ваші дані мають бути пов'язані між Dynamics 365, додатками, автоматизацією та звітами без створення копій.

Ось де він проявляє себе найкраще. Отже, висновок «Одна основа, багато бізнес-інструментів». Ось головний висновок. Dynamics 365 та Dataverse працюють найефективніше, коли всі ваші дані, правила, безпека, додатки, автоматизація та звіти мають спільну основу. Підписуйтесь на Microsoft Knowledge Nuggets на M365FM, щоб отримати більше зрозумілих інструкцій щодо Dynamics 365, Pava Platform та Microsoft 365. Потім подивіться наш випуск про модельні додатки, щоб побачити, як таблиці Dataverse перетворюються на робочий бізнес-додаток.