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

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

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

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

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

Безопасность на уровне столбцов позволяет защитить отдельные столбцы внутри таблицы. Возможно, пользователю нужно открыть строку клиента, но нельзя видеть личный идентификатор, зарплату, банковские реквизиты или частные финансовые заметки. Строка клиента остается доступной для выполнения необходимых задач. При этом защищенный столбец остается ограниченным для доступа. Для крупных компаний бизнес-единицы помогают создавать границы между подразделениями организации. Компания может разделять регионы, отделы или дочерние предприятия, работающие с разными группами клиентов. Бизнес-единицы помогают настроить доступ с учетом этих границ. Это не значит, что каждому бизнесу нужна сложная схема безопасности. Небольшой команде может потребоваться лишь несколько четко определенных ролей. Крупной компании нужно больше уровней, так как ее команды, регионы и обязанности различаются. Суть в том, что 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 общий язык для старта. Организация означает компанию. Контакт означает человека. Действие очлеживает работу в рамках деловых отношений. Вы можете настроить систему под свою компанию и добавлять свои таблицы при необходимости, но вам не нужно каждый раз начинать с чистого листа.

Когда одно приложение понимает таблицу организации, а другое использует ту же таблицу, оба приложения обращаются к одному и тому же типу бизнес-информации. Это также меняет возможности разработки. Допустим, вашей выездной команде нужно простое приложение, чтобы найти клиента, подтвердить визит и добавить заметку после встречи. Вы можете создать PowerApp, которая будет работать с теми же таблицами 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 и как это связано с существующими таблицами. Импорт данных без такого анализа просто переносит хаос в новое место. Пусть OTOM объединит эти части в один повседневный процесс. Новый лид попадает в Dynamics 365, а правило назначения определяет, кто должен стать ответственным за него, например, на основе региона или продукта. Ответственный получает сообщение в Teams через поток Power Automate, поэтому он знает, что его ждет работа. По мере того, как продавец обновляет данные по лиду и продвигает его по воронке продаж, панель мониторинга Power BI меняется, показывая команде OTOM текущую воронку. Одно обновление запускает полезную работу сразу в нескольких местах. Power Automate перемещает работу с одного этапа на следующий. Power BI помогает людям видеть ход этой работы. Power Apps предоставляет конкретным группам узкоспециализированные инструменты для работы. Dataverse обеспечивает организованность и безопасность бизнес-данных, пока эти инструменты выполняют свои задачи.

Эта разница важна. Автоматизация — это не система хранения файлов, а информационная панель — не база данных клиентов. У каждого инструмента своя задача, но все они могут работать с одним источником данных. Понимание этого помогает выбрать правильный инструмент, а не пытаться управлять всем бизнес-процессом с помощью таблицы или простого списка. Где Dataverse уместно и что она не заменяет? Все просто. Выбирайте Dataverse, когда нескольким сотрудникам и приложениям нужен доступ к взаимосвязанным бизнес-данным. Вам нужны четкие правила доступа и повторяемые процессы. Dataverse справляется с этим, но не заменяет все остальное. Excel остается лучшим выбором для личного анализа и быстрых списков. Списки SharePoint хорошо подходят для простого отслеживания задач команды. А если вы разработчик, которому нужен глубокий контроль, SQL остается отличным выбором. Итак, когда же Dataverse действительно подходит? Когда ваши данные должны быть связаны между приложениями Dynamics 365, автоматизацией и отчетами без создания лишних копий. Именно в этом ее преимущество. В заключение. Одна основа – множество бизнес-инструментов. Итак, главный вывод.

Dynamics 365 и Dataverse работают лучше всего, когда данные, правила, безопасность, приложения, автоматизация и отчеты объединены общей основой. Подписывайтесь на Microsoft NoLedge на Gettos на M365.fm, чтобы получать простые руководства по Dynamics 365, Power Platform и Microsoft 365. Затем посмотрите наш выпуск о модельных приложениях, чтобы узнать, как таблицы Dataverse превращаются в работающие бизнес-приложения.