Ласкаво просимо до 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, коли агент опрацьовує запит у службу підтримки. PowerApp може використовувати ту саму інформацію про клієнта для виїзного працівника чи менеджера аккаунта без необхідності попереднього копіювання даних у новий застосунок. Один рядок клієнта – один спільний орієнтир. Це не означає, що кожна команда раптом бачить усе. Доступ все одно потребує правил, і ми невдовзі до цього перейдемо. Це означає, що схвалені застосунки можуть працювати з тією ж бізнес-інформацією, замість того, щоб створювати власні конкуруючі версії. Ось чому 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 працюють ефективно лише тоді, коли потрібні люди мають до них безпечний доступ. Менеджеру з продажу потрібні дані клієнта, агенту підтримки, історія звернень, керівнику – ширший огляд, а зовнішньому партнеру може бути потрібен лише обмежений доступ. Вони не повинні бачити однакову інформацію. Уявіть запис клієнта з приватною нотаткою, узгодженою ціною та відкритим запитом у службу підтримки.

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

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

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

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

Деталь, яку варто запам'ятати, проста. Дані надходять разом із правилами, а не просто як сховище. Отже, фундамент включає інформацію людей, які мають право працювати з нею, і правила, що роблять її придатною до використання. Коли Dynamics 365 працює на тій самій основі, їй не потрібен традиційний міст лише для доступу до власних бізнес-даних. Що насправді означає інтеграція Dynamics 365, більшість людей чують інтеграція Dynamics 365 з Dataverse і уявляють дві окремі системи, з'єднані конектором. Одна система зберігає дані клієнтів, іншій потрібна копія, тому хтось налаштовує синхронізацію, чекає її завершення і сподівається, що нічого не зламається. Така картина має сенс для багатьох бізнес-інструментів. Але тут TMS для 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 Otomite бере на себе подальшу роботу, відстежуючи зміни в рядку Dataverse і запускаючи дію, коли така зміна відбувається. Наприклад, новий лід потрапляє в Dynamics 365 Sales. Потік може сповістити призначеного продавця, опублікувати повідомлення в Teams або створити завдання для подальшої дії. Нікому не потрібно весь день стежити за спільною поштовою скринькою. Лід змінюється і наступний крок запускається автоматично. Pava Otomite не потребує окремої копії ліда лише для виконання цієї роботи. Він може реагувати на рядок у 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 на m365.fm, щоб отримувати більше зрозумілих інструкцій щодо Dynamics 365, Pava Platform та Microsoft 365. Потім подивіться наш епізод про керовані моделью додатки, щоб побачити, як таблиці Dataverse перетворюються на робочий бізнес-додату.