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

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

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

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

В відділу продажу потрібні ці факти в додатку, де вони працюють. Фінансовому та операційному відділам вони потрібні в додатку, де вони керують замовленнями, грошима та доставкою. Мета полягає не в тому, щоб змусити кожну команду працювати в одному гігантському інтерфейсі. Мета – забезпечити, щоб спільні записи проходили чіткий узгоджений шлях. Саме тут на сцену виходить Dual-Ride – подвійний запис. Що ж таке насправді Dual-Ride? Ось найпростіше визначення. Dual-Ride – це вбудоване з'єднання від Microsoft, яке підтримує вибрані дані в синхронізації між додатками Dynamics 365 Finance & Operations та Dataverse. Dataverse – це спільна основа даних для багатьох бізнес-додатків Microsoft. Її використовують Dynamics 365 Sales, Customer Service, Field Service та частини Project Operations. PowerApps та PowerAutomate також можуть її використовувати. Вам не потрібно знати, як Dataverse зберігає кожен окремий запис, щоб зрозуміти Dual-Ride.

Просто сприймайте це як спільну область даних на боці клієнтських додатків Dynamics 365. Уявіть офісну будівлю з фронт-офісом та бек-офісом. Фронт-офіс займається спілкуванням із клієнтами – продавці, сервісні агенти, виїзні працівники. Їм усім потрібні екрани, які допомагають спілкуватися з людьми, відстежувати запити та керувати роботою. Бек-офіс займається роботою, яка підтримує функціонування компанії. Наші фінансові записи – склад, замовлення, закупівлі, доставка. Обидва офіси працюють на одну компанію, але без належного зв'язку між ними хтось має переносити інформацію з одного боку на інший. Вони носять роздруковані форми, надсилають електронні листи або копіюють дані в іншу систему. Робота все одно виконується, але це займає більше часу, а деталі можуть змінюватися в процесі. Dual-Ride – це як внутрішні двері з персоналом між цими двома офісами. Коли підтримуваний запис змінюється з одного боку, Dual-Ride передає відповідну зміну через ці двері на інший бік.

Це не об'єднує всі програми в одну величезну програму. Відділ продажів може продовжувати працювати в продажах. Фінансовий відділ може продовжувати працювати у фінансах. Кожна команда зберігає екрани, створені для її роботи, тоді як обрана спільна інформація залишається пов'язаною з алаштунками. Це слово «підтримуваний» має значення. Dual-Ride не копіює сліпо кожен фрагмент даних в обох системах. Це працює через визначені зв'язки між записами, які належать один одному. Microsoft називає ці зв'язки відображеннями таблиць Table Maps. Таблиця – це просто місце, де програма зберігає один тип запису. Таблиця клієнтів зберігає записи про клієнтів. Таблиця продуктів зберігає записи про продукти. Таблиця адрес зберігає відомості про адреси. Відображення таблиць вказує Dual-Ride, яка таблиця на боці Finance and Operations з'єднується з якою таблицею в Dataverse. Уявіть відображення таблиць, яку згоджений лист перекладу.

Один стовпиць ідентифікує запис з одного боку. Інший стовпиць ідентифікує відповідний запис з іншого боку. Решта листа пояснює, які поля належать одне до одного. Наше ім'я, номер телефону, рядок адреси. Ця угода надає правила з'єднання. Без неї дві програми можуть використовувати різні мітки або зберігати однакові дані в різних місцях. Відображення вказує Dual-Ride, як ці деталі співвідносяться. Отже, програмам не потрібна людина, щоб інтерпретувати їх щоразу. Часто люди чують назву Dual-Ride і припускають, що це означає, ніби кожна зміна завжди рухається в обидва боки. Іноді це так. Для підтримуваного двостороннього відображення зміна в Dataverse може оновити відповідний запис у Finance & Operations. Підтримувана зміна у Finance & Operations також може оновити відповідний запис у Dataverse. Обидві сторони можуть брати участь у тому самому спільному записі. Це і є частина, дуал, подвійний.

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

Перш ніж дозволити запису рухатися в обох напрямках, потрібно знати, звідки цей запис має починатися, хто може його змінювати і яка сторона має бути головною, коли дві програми не згодні, які дані можуть переміщуватися і яка система ними володіє. Отже, які записи Dual-Right може підтримувати в синхронізованому стані. Найпоширеніші приклади починаються із записів, які багато відділів використовують щодня. Записи про клієнтів, адреси, контакти, продукти, постачальники, реквізити компанії та довідкова інформація для фінансів і податків. Подумайте на мить про запис клієнта. Відділу продажів потрібні назва клієнта, основний контакт, номер телефону та адреса доставки. Фінансовому відділу потрібні юридичний запис клієнта, платіжні реквізити та інформація для замовлень і рахунків. Якщо кожен відділ веде свій окремий список клієнтів, компанія витрачає час на порівняння записів замість обслуговування клієнта.

Завдяки правильним картам Dual-Right ці команди можуть працювати з пов'язаними даними клієнтів. Це не означає, що користувачам продажів раптово потрібно вивчати фінансовий додаток.

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

Ці відповіді зазвичай надходять з операційної сторони бізнесу, оскільки саме там керують продуктами, запасами, закупівлями та виконанням замовлень. Ось чому інформація про продукт часто з'являється у Finance & Operations. Операційна команда створює та готує продукт там. Коли продукт готовий до роботи з клієнтами, Dual Right може передати відповідні дані про нього в Dataverse. Користувачі продажів можуть вибирати та обговорювати продукт у власному додатку без потреби вносити список продуктів в друге. Це допомагає будувати розмови з клієнтами на основі того, що бізнес дійсно може надати. Дані про ціни та запаси також можуть надходити у відділ продажів через пов'язані додатки. Замість того, щоб гадати, чи існує товар, чи змінилася ціна або чи є запас для виконання обіцянки, відділ продажів може працювати з інформацією, прив'язаною до операційної системи. Це не скасовує потреби в хорошому досвіді продажів.

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

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

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

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

Жодних файлів експорту, що лежать у спільній папці в очікуванні, поки хтось їх забере. Нікому не потрібно надсилати електронний лист у відділ фінансів із повідомленням «Гей, будь ласка, оновіть цю адресу». Карта вже знає, які поля пов'язані, і надсилає підтримувану зміну прямо до відповідного запису клієнта у Finance & Operations. Отже, фінансовий користувач може пізніше відкрити запис клієнта, побачити оновлену адресу та опрацювати замовлення або підготувати рахунок без жодної затримки. Це практичний результат, просто і зрозуміло. Дві людини продовжують працювати в різних додатках, але жодному з них не потрібно переписувати одні й ті самі дані клієнта. Торговий представник працює на екрані, розробленому для спілкування з клієнтами. Фінансовий користувач працює на екрані, створеному для фінансової роботи. Кожна людина бачить інформацію про клієнта, яка їй дійсно потрібна саме там, де вона потрібна.

І цей шлях працює і в іншому напрямку також. Уявіть, що фінанси оновлюють підтримувану інформацію про клієнта у Finance & Operations. Скажімо, фінансовий користувач виправляє деталь, яка належить до операційного запису клієнта. DualWrite використовує відповідну карту у зворотному напрямку та надсилає це оновлення в Dataverse. Тоді Sales, Customer або будь-який інший додаток на базі Dataverse зможе його отримати. Це з'єднання є синхронним для звичайної повсякденної роботи. Синхронний означає, що додатки намагаються завершити відповідне оновлення як частину того самого моменту роботи, а не відкладати його у фонове завдання, яке може запуститися через 20 хвилин. Якщо з'єднання не може завершити оновлення, ця проблема потребує негайної уваги, а не має тихо ховатися, поки хтось не помітить невідповідність. Така поведінка є логічною для спільних бізнес-записів. Ви ж не хочете, щоб адреса клієнта, деталі продукту чи інша спільна інформація розходилися годинами через те, що пакетне завдання ще не запустилися.

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

Початкова синхронізація зводить наявні записи з обох сторон до спільної точки відліку. Уявіть компанію, яка вже має клієнтів у Finance and Operations і записи про клієнтів у Dataverse. З'єднання не може просто вімкнутися і припустити, що кожен наявний запис уже ідеально збігається. Потрібна точка старту. Початкова синхронізація допомагає перенести наявні дані, перш ніж користувачі покладатимуться на оновлення в реальному часі. Ця робота потребує уваги, оскільки дублікати записів, неповні адреси та старі тестові дані не очищаються магічним чином лише через запуск синхронізації. Навпаки, вони можуть швидше створювати проблеми, якщо записи не відповідають узгодженим правилам. Коли карти запущені відповідальним за подвійний запис, потрібне чітке місце для перевірки стану системи. Подвійний запис надає об'єднані журнали активності та помилок, щоб адміністратори могли бачити, що обробило з'єднання і де виникли проблеми.

Вони також можуть налаштовувати сповіщення та порогові значення. Це означає, що потрібні люди дізнаються про проблеми до того, як користувачі виявлять їх через відсутні або невдалі оновлення. Такий погляд на підтримку важливий, оскільки кожна помилка має причину. Можливо, відсутнє обов'язкове поле. Можливо, пов'язаний запис ще не надійшов. Можливо, хтось змінив дані у спосіб, що не відповідає карті. Повторна спроба обробити помилковий запис без усунення причини зазвичай призводить до такої ж помилки знову. Добре налаштована система подвійного запису стежить за з'єднанням, усуває причини помилок і зосереджує карти на записах, які дійсно мають бути пов'язані. Де подвійний запис підходить найкраще. Подвійний запис найкраще підходить, коли ваш бізнес використовує Dynamics 365 Finance або Supply Chain Management разом із клієнтськими програмами, такими як продажі, обслуговування клієнтів, виїзне обслуговування або управління проектами.

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

DualWrite допомагає цим двом частинам залишатися пов'язаними. Продавці можуть працювати в додатку, який відповідає їхнім завданням, тоді як фінансовий та операційний відділи керують транзакцією в додатку, створеному для їхньої роботи. Клієнт не перетворюється на дві окремі історії, одну розказану відділом продажів і іншу – фінансовим відділом. Field Service – ще один гарний приклад. Уявіть компанію, яка відправляє техніків для встановлення, ремонту або обслуговування обладнання на об'єктах клієнтів. Працівнику на виїзді потрібні дані про клієнта, деталі роботи та інформація про актив клієнта, який компанія встановила або обслуговує. За лаштунками компанія також має відстежувати запчастини, витрати, закупівлі та кошти, пов'язані з цією роботою. Field Service зосереджується на плануванні та завершенні візиту. Фінансовий та операційний відділи зосереджуються на пов'язаних з цим операційних та фінансових записах.

Коли ці записи належним чином пов'язані, робота техніка не відокремлена від використаних запчастин, вартості робіт або запису клієнта. Project Operations відповідає тій самій моделі, особливо для компаній, що продають роботу за проектами. Команда проекту може керувати роботою з клієнтом, часом працівників, запланованими витратами та етапами проекту. Фінансовому відділу потрібно бачити фінансовий аспект закупівель, витрат, виставлення рахунків та звітності. Без зв'язку менеджери проектів можуть витрачати за багато часу на запити до фінансового відділу, тоді як фінансисти чекають на підтвердження результатів від команд проекту. Пов'язані записи проектів дають обом групам чіткіше бачення роботи в міру її переходу від обіцянки клієнту до фінансової активності. Тут також є ширша перевага Pava Platform, оскільки сторона клієнтського додатка використовує Dataverse, то затверджені дані в Dataverse можуть підтримувати Pava Apps та Pava Otamate.

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

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

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

DualRide забезпечує переміщення підтримуваних спільних записів між фінансами і операціями та вашими клієнтськими програмами на базі Dataverse. Таким чином, команди можуть працювати з пов'язаними бізнес-даними. Підписуйтесь на улюбленій платформі подкастів, щоб отримати більше знань зі мною, Мірко Пітерсон на m365.fm і поділіться цим епізодом з тим, хто все ще з'єднує продажі, сервіс та фінанси через чергову таблицю.