Добро пожаловать в Microsoft NoLedge на Getas. Я Мо Питерс. Тема сегодняшнего выпуска часто вызывает у людей вопросы. Что именно такое Dataverse? Это база данных, приложение или скрытый сервис Dynamics 365, который нужен только и Т-специалистам. Вот самое простое определение. 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 включает их в систему, так как большинству компаний нужно отслеживать клиентов, людей, задачи и общение. Не нужно создавать новую таблицу для стандартных задач, если готовые уже подходят для этой цели. Но у каждой компании есть и своя специфика работы. Учебной компании может потребоваться отслеживать курсы и сертификаты. Бизнесу в сфере недвижимости могут понадобиться здания, объекты и инспекции. Производитель может отслеживать проверки оборудования или сервисные визиты. В таких случаях можно создать пользовательские таблицы, соответствующие реальной работе вашей компании. Представьте создание такой таблицы, как добавление нового ящика в шкаф с четкой маркировкой. Теперь, каждая таблица состоит из строк. Строка – это один элемент в этом ящике.

Например, одна строка в таблице контактов может представлять Марию Гомес, сотрудника компании-клиента. Ее строка содержит личные данные, отделенные от всех остальных контактов в системе. Столбцы описывают детали, которые вы хотите сохранить для каждой строки. Строка контакта Марии может содержать столбцы – имя, фамилия, адрес электронной почты, номер телефона, должность, компания, владелец записи и статус. Столбец определяет тип информации, которая должна находиться в этом месте. Так, столбец электронной почты ожидает адрес, а столбец статуса может содержать допустимые варианты статуса. Именно так бизнес-информация приобретает надежную структуру. Без столбцов один человек может ввести номер телефона в заметки, другой – в поле имени, а кто-то вовсе его не укажет. Благодаря четкой таблице контактов все работают с одним набором данных в одних и тех же местах. Эта структура также помогает приложениям понимать данные.

Форма может показать нужные поля, отчет – сгруппировать контакты по статусу, а автоматизация – среагировать на смену владельца. Информация не просто где-то хранится. У нее есть метки, которые сообщают связанным инструментом значения каждой части. Начинайте со стандартных таблиц, если они соответствуют вашим бизнес-потребностям. Если вы работаете с компаниями, таблицы учетных записей и контактов уже описывают понятную всем модель. Если вы занимаетесь поддержкой клиентов, обращения станут для вас отправной точкой. И добавляйте пользовательские таблицы только тогда, когда информация не вписывается во встроенные модели. Это позволяет избежать типичной проблемы – создание пяти разных таблиц, которые означают одно и то же «клиент». Одна команда называет это «клиентом», другая – «основным заказчиком», третья – «контактом партнера». Вскоре люди перестают понимать, какую таблицу им следует использовать.

Понятные стандартные таблицы и тщательно названные пользовательские таблицы сохраняют структуру базы данных простой для расширения другими сотрудниками. На следующем этапе эти «ящики» начинают работать сообща. Контакты относятся к определенной организации. Мария работает в компании «Контаса». Вместо того, чтобы снова вводить адрес, телефон и реквизиты «Контаса» в строку «Марии», «Датаверс» позволяет создать связь между таблицей контактов и таблицей организаций. Мария связана с «Контаса», и эта связь важна, поскольку информация о компании остается в самой компании. Если «Контаса» меняет адрес офиса, достаточно один раз обновить запись в таблице организаций. Каждый связанный контакт будет ссылаться на ту же компанию, не храня у себя устаревшие копии данных. Связи также соединяют обращения в поддержку с клиентом, который его создал. Они могут связать торговую сделку со звонками, письмами, встречами и задачами, относящимися к ней.

Когда менеджер по продажам открывает сделку, он видит все связанные с ней действия, они ищут информацию в разрозненных заметках и календарях. Информация обретает контекст. Вы смотрите не просто на номер обращения. Вы видите, какому клиенту оно принадлежит. Вы просматриваете не просто контакт. Вы видите компанию, к которой этот человек относится. Эти связи делают данные полезными, избавляя от необходимости вводить одно и то же в несколько мест. Небольшое замечание по поводу терминологии перед тем, как вы начнете изучать старое руководство или видео. Вы можете встретить слова «сущность», «энтити», «поле», «филд» и «запись», «рекорд». Это старые термины «датаверс». Microsoft теперь использует таблицу вместо «сущности», «столбец», вместо «поле» и «строку», вместо «записи». Суть при этом не изменилась. Если старое руководство велит вам создать «сущность», речь идет о создании таблицы. «Поле» — это «столбец», а «запись» — это «строка».

Знание обоих вариантов терминологии поможет вам не подумать, что вы нашли другой продукт. Итак, таблица систематизирует информацию, а связи соединяют ее. Но даже хорошо организованному архиву нужны правила доступа. Кто-то должен решать, что именно пользователи могут вводить, изменять и к чему имеют безопасный доступ. Это правило и стойка регистрации для ваших данных. Общие данные эффективны лишь тогда, когда нужные люди работают с ними безопасно. Торговому представителю нужны сведения о клиентах, специалисту поддержки, истории обращений, руководителю — общая картина, а внешнему партнеру может потребоваться доступ лишь к небольшой части процесса. И не все из них должны видеть одну и ту же информацию. Представьте запись о клиенте с личной заметкой, согласованной ценой и открытым обращением в поддержку. Предоставление всем пользователям полного доступа быстро создаст риски. Слишком сильные ограничения, мешающие работе, создают другую проблему.

Dataverse предлагает средства контроля для этого. Первый уровень контроля начинается с идентификации. Когда вы входите в систему с учетной записью компании, Microsoft IntraID идентифицирует вас. Представьте IntraID как стойку регистрации на входе в офис. Вы приходите, показываете пропуск, и администратор проверяет, кто вы, прежде чем разрешить вход. 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. Речь идет не просто о перемещении данных из точки А в точку Б важно, что приложения работают с одними и теми же записями, связями, правилами и правами доступа. Начнем с простого процесса продаж. Лид поступает через веб-сайт или мероприятие. Менеджер по продажам работает с лидом, узнает больше о человеке и превращает его в клиента и потенциальную сделку. Звонки, электронные письма, встречи и задачи – все это привязывается к данной работе. Команде не нужно искать разрозненные инструменты, чтобы собрать всю историю целиком. Если клиенту позже потребуется помощь, обращение в поддержку будет привязано к этому же клиенту.

Агент поддержки видит не только имя и адрес электронной почты. Он работает в контексте уже существующей истории отношений с клиентом. Тем временем отдел продаж видит, что у клиента есть открытая заявка и может избежать неловких ситуаций при обсуждении продления договора. Отношения с одним клиентом могут поддерживать разные виды деятельности. Это гораздо полезнее, чем просто хранить одинаковые имена клиентов в двух системах. Вы также можете услышать термин «общая модель данных», «команда и тамодел», иногда сокращенно «CDM». Не стоит думать, что это название звучит загадочнее, чем есть на самом деле. Это означает, что Microsoft предоставляет стандартные шаблоны бизнес-таблиц для данных, которые очлеживают многие компании, аккаунты, контакты, действия и обращения. Эти шаблоны обеспечивают приложением на базе Dynamics 365 и Dataverse единый язык общения. Аккаунт означает компанию. Контакт означает человека.

Действие очлеживает активность в рамках деловых отношений. Вы можете настроить систему под свою компанию и добавить свои таблицы. Но вам не придется каждый раз начинать все с нуля. Если одно приложение распознает таблицу аккаунтов, а другое использует ту же таблицу, оба они ссылаются на один и тот же тип бизнес-информации. Это также расширяет возможности разработки. Предположим, вашим выездным сотрудникам нужно простое приложение, чтобы найти клиента, подтвердить визит и добавить заметку после встречи. Вы можете создать OER-эп, которая будет работать с теми же таблицами Dataverse, что уже использует Dynamics 365. Нет необходимости экспортировать список клиентов специально для этого приложения. Сотрудник открывает приложение, находит клиента и обновляет информацию о визите. Данные остаются привязанными к отношениям с клиентами, которые уже используют отделы продаж или обслуживания, с учетом правил безопасности, рассмотренных ранее.

Для более структурированных бизнес-задач можно создать приложение на основе модели. Работа приложения на основе модели начинается с модели данных. Вы выбираете таблицы Dataverse, определяете их связи, настраиваете формы и представления, а также применяете роли безопасности. Затем PowerApps использует эту структуру для создания рабочего бизнес-приложения. Представьте это как организацию верстака с инструментами и материалами, которые действительно использует ваша команда. Таблицы описывают работу. Связи соединяют элементы воедино. Формы предоставляют сотрудникам место для ввода и просмотра данных. Представления помогают им находить строки, требующие внимания. Система безопасности определяет, что каждый пользователь может открывать или изменять. Приложение на основе модели может работать параллельно с Dynamics 365, поскольку оба решения используют Dataverse. Например, Dynamics 365 Sales отвечает за полный цикл продаж, а небольшое приложение на основе модели дает миниджарам по контрактам удобный инструмент для отслеживания соглашений с клиентами.

Оба решения могут работать с одними и теми же данными клиентов без создания второй базы данных. Разумеется, такой доступ требует контроля. Тот факт, что приложение может работать с таблицей Dataverse, не означает, что каждый пользователь должен редактировать все строки или видеть все столбцы. Ролевой доступ к строкам и бизнес-правила по-прежнему контролируют все действия. Приложение для выездных сотрудников может предоставить только необходимые данные о клиентах и нужные функции, не раскрывая остальные корпоративные данные. Таким образом, интеграция Dynamics 365 секунд Dataverse теперь подобна кабелю, соединяющему две удаленными комнаты. Приложение Dynamics 365, пользовательские приложения и бизнес-процессы могут работать на одной общей базе. Когда вы это понимаете, следующий вопрос становится очевидным. Что еще может использовать то же обновление данных клиента на подключенной платформе Microsoft?

Как подключенная платформа работает в реальных условиях? Обновление данных клиента становится полезным, когда инструменты вокруг него могут на него реагировать. Power Automate берет на себя последующую работу, очлеживая изменения в строках Dataverse и запуская действия при возникновении таких изменений. Например, в Dynamics 365 Sales поступает новый лид. Поток может уведомить назначенного продавца, опубликовать сообщения в Teams или создать задачу по сопровождению. Никому не нужно весь день следить за общим почтовым ящиком. Данные лида меняются, и следующий этап запускается автоматически. Power Automate не нужна отдельная копия лида для выполнения этой работы. Система реагирует на изменения в строке Dataverse, используя те же данные о клиентах и владельцах, что и приложение для продаж, что удерживает автоматизацию в рамках бизнес-процесса вместо того, чтобы полагаться на ручную выгрузку файлов и переписку по почте.

А еще есть Power BI. Менеджеру по продажам может понадобиться увидеть текущую воронку продаж. Менеджеру по обслуживанию клиентов может потребоваться узнать, сколько обращений поступило за неделю, какие из них остаются открытыми или кто из клиентов чаще всего обращается в поддержку. Power BI может формировать отчеты по бизнес-данным Dataverse, чтобы команды видели текущую работу без необходимости каждую пятницу готовить новые выгрузки в таблице. Отчет строится на основе бизнес-данных, которые сотрудники уже используют. Это означает, что диаграмма воронки продаж меняется по мере продвижения сделок. Дашборд по обращениям может показывать текущую нагрузку по мере того, как агенты обновляют данные. Суть в том, что дашборд избавляет людей от необходимости вручную проверять все детали. Он дает им более четкое представление о работе, прежде чем они решат, что требует внимания. Power Apps добавляет еще один путь в тот же самый процесс.

Представьте выездного сотрудника, прибывшего на объект клиента. Ему не нужен полный функционал Dynamics 365 Sales. Возможно, ему нужно лишь найти клиента, просмотреть детали визита, подтвердить результаты и добавить заметку или фото. Специализированное приложение Power App может предоставить им этот упрощенный интерфейс. Команде по работе с клиентами может потребоваться приложение для проверки клиентских соглашений. Менеджеру может понадобиться простое приложение для утверждения запросов. Каждое приложение сосредоточено на одной задаче, при этом работая с одними и теми же защищенными данными Dataverse в фоновом режиме. Сотрудник видит инструмент, который подходит для его ежедневных задач. Компания сохраняет всю информацию связанной. Иногда эта информация изначально находится вне Dataverse. У компании может быть список из онлайн-источника, который должен стать частью ее бизнес-данных. Power Query может импортировать данные из поддерживаемых онлайн-источников, очищать их при импорте и загружать в нужную таблицу Dataverse.

Это полезно, когда сторонний источник содержит информацию, необходимую для работы ваших инструментов Dynamics и Power Platform. Вам все равно нужно решить, что именно относится к Dataverse и как это должно связываться с существующими таблицами. Импорт данных без такой подготовки просто переносит беспорядок в новое место. Давайте соберем все части в единый повседневный рабочий процесс. Новый лид поступает в Dynamics 365. Правило назначения проверяет, кто должен отвечать за лид, например, на основе региона или продукта. Ответственный получает сообщение в Teams через поток Power Automate и понимает, что есть ожидающая работа. По мере того, как продавец обновляет данные и продвигает лид по воронке, дашборд Power BI меняется, отображая текущее состояние для команды. Одно обновление запускает полезную работу сразу в нескольких местах. Power Automate перемещает задачу с одного этапа на следующий.

Power BI помогает сотрудникам видеть результаты работы. Power Apps дает конкретным командам удобный способ участия в процессах. Dataverse сохраняет бизнес-информацию организованной и защищенной, пока эти инструменты выполняют свои задачи. Эта разница имеет значение. Автоматизация — это не система хранения файлов, а дашборд — это не база данных клиентов. У каждого инструмента своя задача, но все они могут работать с общим источником данных. Это понимание помогает выбрать подходящий инструмент, а не пытаться управлять бизнес-процессом с помощью обычной таблицы или списка. Когда стоит использовать Dataverse и что она не заменяет? Суть вот в чем. Выбирайте Dataverse, когда нескольким пользователям и приложениям нужен доступ к взаимосвязанным бизнес-данам. Вам нужны четкие правила доступа и воспроизводимые процессы. Dataverse справляется с этим, но она не заменяет собой все остальное. Excel по-прежнему идеален для личной аналитики и быстрых списков.

Списки SharePoint хорошо подходят для простого отслеживания задач в команде. А если вы разработчик, которому нужен глубокий контроль, SQL остается отличным выбором. Так когда же Dataverse действительно подходит? Когда ваши данные должны быть связаны между Dynamics 365, приложениями, средствами автоматизации и отчетами без создания лишних копий. Вот в чем ее преимущество. Итак, вывод, одна основа, множество бизнес-инструментов. Подведем итог. Dynamics 365 и Dataverse работают лучше всего, когда ваши данные, правила, безопасность, приложения, автоматизация и отчеты опираются на единую основу. Подписывайтесь на Microsoft Knowledge, на Getas, на M365FM, чтобы получать простые руководства по Dynamics 365, Power Platform и Microsoft 365. Затем посмотрите наш выпуск о модельных приложениях, чтобы увидеть, как таблицы Dataverse превращаются в рабочие бизнес-приложения.