Привет Хабр! В этой статье хотелось бы рассказать о некоторых стандартных возможностях Dynamics CRM (для понимания что это вообще такое), её основных бизнес процессах и средствах расширения функционала прямо из коробки.
Для начала, давайте пробежимся по некоторым фактам о CRM системе от Microsoft:
Для разработчиков полезно знать что:
Также давайте взглянем какое место CRM (Sales) занимает в экосистеме решений Майкрософта.
С точки зрения пользователя — всё просто. Получаем url адрес и переходим туда используя свой любимый браузер.
До недавнего времени Майкрософт рекомендовал использовать только Internet Explorer, но ничто не вечно под луной, и теперь со спокойной совестью можно работать через Chrome.
При переходе по адресу, придётся ввести логин и пароль учетной записи (CRM использует ADFS для аутентификации пользователей), и попадаем на домашнюю страницу.
Давайте представим себя в роли менеджера по продажам.
Наша компания неделю назад провела рекламную кампанию, и директор по маркетингу занёс в систему лидов (Lead или Потенциальный Клиент) и назначила их на нас.
Что такое Лид? Ну, есть какая то компания, которая вроде бы заинтересована в наших услугах, и у нас есть возможность им что то предложить, но они еще не знают чего им точно надо.
Форма Лида выглядит вот так:
Мы им звоним и выясняем что нужно сделать, они вроде бы согласны с предложенным и готовы обсуждать дальше. Отлично! Это значит что мы можем квалифицировать (Qualify) лида, и CRM автоматически создаст из одной записи целых 3: Контакт (Contact), Организацию (Account) и Возможную Сделку (Opportunity).
Следующий этап после Лида — Возможная Сделка. На этом этапе идёт активное уточнение нужд клиента, мы приступаем к заполнению Продуктов Возможной Сделки, которые берутся из каталога Продуктов.
Стандартные поля для Возможной Сделки:
Дополнительно можно заполнить таблицу Конкуренты (Competitors). Помогает для анализа конкуренции в целом, хранит историю выигрышей и проигрышей для каждой компании соперников.
Таблица (Sub-Grid) Команда Продажи (Sales Team) позволяет иметь список людей, работающих над сделкой.
При добавлении Продуктов в Возможную Сделку, происходит автоматический расчет ожидаемой прибыли. У разработчиков есть возможность её переопределить, если необходимо добавить новые поля в формулу расчета. Хотите сразу включить в расчет прибыли возможный откат? Не вопрос.
Важно отметить, что сделку можно закрыть как проигранную. CRM обязательно спросит причину и занесёт её в историю клиента как действие.
Следующим этапом является создание Коммерческого Предложения (Quote).
У Коммерческого Предложения есть свой жизненный цикл. Оно создаётся из Возможной Сделки в статусе Черновик (Draft) с подтягиванием её же продуктов. Пользователь может изменять продукты и их цену. Как только он дошел до того, что готов выслать предложение клиенту, запись переходит в Активный (Active) статус и запись становится нередактируемой.
Если клиент согласен с предложением, то оно закрывается со статусом Выигрыш (Won) и мы переходим на этап Заказ (Order). Если необходимо что либо поменять, то мы выбираем Пересмотр (Revise), при этом будет создано новое Коммерческое Предложение, с опять же подтянутыми продуктами.
Заказ — это по сути утвержденное Коммерческое Предложение. В нём содержится информация про продукты или услуги которые заказал клиент. Из него можно создать Счет-Фактуру (Invoice), которая может быть закрыта со статусом Оплачена (Paid) или Отменена (Canceled).
Дальше в ход должны вступать интеграции с другими системами. Например, MS NAV. Майкрософт предоставляет для этого готовое решение коннектор.
Имея такую историю по клиентам можно построить самый важный график в CRM — Воронку Продаж:
Она позволяет анализировать динамику продаж по различным стадиям, начиная с лида и заканчивая заказом. Например, можно находить узкие места, в которых теряется больше всего клиентов, и постараться их исправить. Также директор по продажам может оценить будущую прибыль, в зависимости от количества лидов на текущий момент.
Содержит Инциденты (Cases), которые создаются службой поддержки, автоматически через имейлы или с помощью интеграций со сторонними системами. Инциденты хранят в себе информацию о возникшей проблеме клиента. Они могут быть добавлены в специальные очереди, что позволяет более эффективно распределять нагрузку на службу поддержки.
Dynamics CRM имеет функционал Базы Знаний (Knowledge Base), для помощи в решении проблем. База содержит статьи, которые сгруппированы по темам.
Также есть возможность следить за KPI (Ключевой Индикатор Производительности) с помощью настраиваемых SLA (Соглашение об уровне обслуживания). SLA настраиваются в зависимости от часов работы, дней работы, и графика в выходные дни. При создании Инцидента берутся эти SLA и высчитывается время, за которое необходимо решить проблему.
Для пользователя это видно в виде таймера на главное форме Инцидента. Обратный ход можно остановить, если, к примеру, пользователь ждёт ответа от клиента.
Маркетинговые списки — удобный способ сгруппировать Контакты, Организации и Лиды в группы по какому либо критерию или вручную. Они могут быть как статические так и динамические (очевидно, что для создаваемых по заранее заданному критерию). В конечном счёте, эти списки используются для каких либо маркетинговых действий: рассылка сообщений с новостями, промо материалами итд.
Кампании в Dynamics CRM представлены обычными кампаниями (Campaings) и быстрыми кампаниями (Quick Campaigns). В целом, они создаются для контроля действий по каждой из них, в также для удобного просчета ROI (Return on investemnts / Окупаемость Инвестиций).
У кампаний есть список откликов (Campaign Responses), который создаётся для понимания её успешности. Отклики можно вносить как вручную, так и автоматически, используя входящие электронные сообщения.
В чем различия Кампании и Быстрой Кампании?
Быстрая кампания может иметь только один тип активности, один список клиентов, не имеет встроенных метрик, не может создаваться из шаблонов кампаний, предполагает быстрое исполнение. Как пример, кампания по отправке электронных сообщений перед распродажей на день Благодарения. Сгенерировали список для рассылки, произвели её, получили отзывы, посчитали количество сгенерированных лидов и ROI на основе конверсии Лида в Возможную Сделку, закрыли кампанию.
Наконец то можно перейти к тому, для чего я всё это затеял.
Существует много способов для расширения функционала CRM. В этой статье я опишу элементарные вещи, такие как создание новых Сущностей (Entities), Полей (Fields), Форм (Forms), Представлений (Views).
Solutions
Для начала, необходимо рассказать про Решения (Solutions). Это такие пакеты, содержащие в себе полное или частичное состояние любого объекта, добавленного туда. Они используются для переноса компонентов из одной системы в другую, а также для разработки новых компонентов. Добраться до списка Решений можно пройдя в меню через Settings/Solutions.
Перед нами форма только что созданного Решения.
Обратите внимание на поле Издатель (Publisher). Оно хранит в себе Название и Префикс Разработчика компонентов. В зависимости от того, в каком Решении будет создан компонент, такой префикс он и будет иметь. Например, Издатель имеет префикс habr, соответственно новая сущность User будет иметь системное имя вида habr_user.
Решения можно Экспортировать или Импортировать. При экспорте можно выбрать каким оно должно быть. Управляемое (Managed) или неуправляемое (Unmanaged).
Solutions делятся на 3 вида.
Для того, чтобы изменения вступили в силу, их необходимо опубликовать (Publish). Для этого достаточно нажать на необходимую кнопку выбрав необходимое Решение.
Entities
Или Сущности. С их помощью можно определить типы записей. Самая близкая аналогия — таблица БД.
Давайте создадим нашу первую Сущность. Переходим в раздел Entities и нажимаем New.
Откроется новая форма для создания сущности.
Тип Собственности (Ownership) — позволяет выбрать владельца записи. По умолчанию это Организация, т.е владельца нет как такового. Если выбрать Пользователь или Группа — то сущность будет иметь поле Owner. В дальнейшем, в зависимости от типа собственности, можно гибко настроить доступ пользователей к записям и их видимость в подразделениях.
Если выбрать пункт Define as an activity entity, то сущность станет действием. Действия — это записи, которые могут отображаться в календаре. Для такой сущности будут автоматически добавлены поля Времени Начала, Времени Конца, Продолжительность. Действие можно будет Отменить или Выполнить. Быть владельцем такой сущности может только Пользователь или Группа.
Во вкладке Primary Field можно задать параметры Основного поля, которое будет обязательным для заполнения.
При желании, можно поменять имя или тип на что то другое. В таком случае рекомендую позаботиться о том, чтобы оно заполнялось для каждой записи, и являлось уникальным. Значение этого поля используется как обозначение Lookup поля. Как пример, lookup поле Publisher на форме Решения. (PS типы полей будет ниже)
Также есть довольно большой список настроек, которые можно задать. Пройдёмся по самым часто использующимся.
Зоны видимости сущности (Areas that display this entity) — можно задать вкладки главного меню, в которых будет доступна сущность.
Разрешить быстрое создание (Allow quick create) — по умолчанию новая запись создаётся в новом окне. При активации данной функции появляется возможность создавать запись из активного окна, с вводом только необходимых полей.
Определение дубликатов (Duplicate detection) — позволяет запретить создание одинаковых записей с помощью правил.
Аудит (Auditing) — можно выбрать поля сущности, для которых будет храниться вся история изменений. С этой настройкой нужно быть осторожным, можно получить значительное увеличение объема БД.
Fields
Или Поля. Используются для определения отдельных элементов данных.
После создания сущности CRM автоматически создаст базовые поля
Давайте дополним сущность своими. Нажимаем New и видим форму созданию нового поля.
Display Name — имя, которое будет отображаться на форме записи.
Field Requirement — устанавливает обязательность поля. Всего есть 3 вида. Optional — позволяет создать запись без заполнения поля; Business recommended — аналогичен опциональному, но возле поля будет стоять звездочка как рекомендация о заполнении; Required — нельзя создать запись без заполнения этого поля.
Name — системное имя поля.
Searchable — позволяет использовать поле для поиска записей по его значению.
Field Security — позволяет дополнительно настраивать кому показывается данное поле.
Auditing — позволяет включить аудит поля. (Будет сохраняться история изменения)
Data Type — тип данных поля. Всего существует 12 типов данных.
Single Line of Text — строка текста. Может содержать до 4000 символов, но можно ограничить на меньшее число.
Option Set — список Имя-Значение
Two Options — обычный Boolean
Image — картинка
Whole Number — Целое число в границах от -2,147,483,648 до 2,147,483,647.
Floating Point Number — число в границах от -100 000 000 000 до 100 000 000 000, которое может содержать до 5 знаков после запятой
Decimal Number — число в границах от -100 000 000 000 до 100 000 000 000, которое может содержать до 10 знаков после запятой
Currency — денежные значения в границах от -922 337 203 685 477 до 922 337 203 685 477
Multiple Lines of Text — несколько строк текста. Может содержать до 1 048 576 символов, но можно ограничить на меньшее число.
Date and Time — дата и время. В БД данное поле хранится в UTC, поле можно настроить для показа UTC или локального времени пользователя. Также можно показывать дату и время либо только дату.
Lookup — представляет из себя ссылку на запись любой сущности. Хранит в себе сразу 3 значения (Имя записи, GUID и тип сущности). По правилу хорошего тона в конце имени пишется 'id', как обозначение поля lookup. Небольшое отступление: справочник от Майкрософта переводит название этого поля как Поиск. Однако все называют его просто Лукап.
Customer — по факту это мульти Lookup, который может ссылаться только на 2 сущности — Contact или Account.
Еще есть 3 типа полей. Не каждый тип данных может иметь все 3 типа полей.
Forms
Каждая сущность содержит свои Формы. Они позволяют настроить отображение полей для разных случаев.
Всего есть 4 типа форм:
Main — форма, которая будет показываться при открытии записи через браузер.
Mobile — эта форма будет открываться на мобильном устройстве.
Quick View — позволяет встраивать данную форму в формы других сущностей. Например, Main форма сущности Post содержит поле Author (которое ссылается на сущность User), и мы показываем дополнительные данные User через его Quick View форму.
Quick Create — форма для быстрого создания записи (Без открытия нового окна браузера)
Настройка Форм
Dynamics CRM позволяет гибко настраивать вид и функционал Форм.
Основные возможности редактора форм:
Вот так будет выглядеть редактор формы для нашей сущности Post.
В нашем случае у нас имеется всего 1 Tab именованный General (обведён синей рамкой), внутри которого имеется один Section также с именем General.
Вкладка Home
Вообще, Main формы состоят из 4 частей: Header, Body, Footer, а также Navigation слева.
Для того, чтобы выбрать что вы в данный момент хотите редактировать придётся воспользоваться группой Select на риббон ленте.
Поля добавляются двойным нажатием или перетягиванием.
Удаляются же кнопкой Remove. Required поля (которые с красной звездочкой), так просто удалить с формы не получится. Придётся сначала изменить их тип на Optional.
Кнопка Form Properties позволяет добавлять JS файлы на форму, и регистрировать их функции для событий форм и полей.
Вкладка Insert
Во вкладке Insert мы работаем только с телом формы. Здесь мы изменяем её разметку.
Команды риббон ленты в данном случае:
Section — добавляет секцию в выбранный tab. Может содержать 1-4 столбца.
Tabs (Вкладки) — множество вариантов добавляют вкладку с количеством секций 1-3 разной ширины.
Вот пример вкладки с тремя секциями. Одна секция имеет три столбца, две другие по одному. Каждый столбец это потенциальное месторасположение поля.
Sub-Grid — добавляет список записей связанной (или нет) сущности на форму.
Коротко про то, что это такое.
Например, Хабр добавил функцию пожертвований для статей. Создаём сущность Donations которая содержит в себе lookup на Post. При этом, при создании поля создаётся связь N:1.
Всё, теперь мы можем добавить Sub-Grid показывающий пожертвования. Окно настройки Sub-Grid выглядит так:
А наша форма будет иметь такой вид:
Spacer — создаёт пустое место
Quick View Form — добавляет форму быстрого вида. Мы уже такую делали для автора.
Web Resource — добавляет веб ресурс на форму. Например, интерактивная html страница или Silverlight приложение.
IFrame — можно добавлять и их тоже
Notes — добавляет панель для создания заметок
Views
Или Представления, используются для отображения списков записей.
Можно задать отображаемые поля, их ширину, а также фильтры и сортировку.
Вот пример, на котором показываются только активные посты.
Представления бывают:
Общие — представления, доступные всем пользователям. При создании новой сущности автоматически создаются Активные и Неактивные представления.
Личные — принадлежат отдельным пользователям. Могут быть созданы администратором, и затем отдельно назначены на другого.
Системные — недоступны напрямую для выбора из списка представлений, а существуют как дополнения, расширяющие функциональность отдельных элементов интерфейса. Например, быстрый поиск, расширенный поиск
Создадим своё личное представление?
Жмём на список представлений и выбираем Create Personal View.
Открывается новое окно для настройки представления. Можно взять за основу существующее представление выбрав его в Use Saved View.
Edit Columns позволяет выбрать отображаемые поля
Results позволяет проверить какие записи будут выведены после наложения фильтра.
Фильтр строится добавлением условий с помощью Select и их группировкой через AND/OR.
Вот так выглядит готовый фильтр. Сохраняем его попутно дав название, и получаем готовое личное представление.
В данной статье я дал информацию для отличного старта в разработке для Dynamics CRM. В следующих статьях будем разбираться с остальными доступными кастомизациями, официальным SDK, must have приложениями, писать плагины (Plugins) и рабочие процессы (Workflows).
Буду благодарен за отзывы и спасибо, что прочитали статью.
Для начала, давайте пробежимся по некоторым фактам о CRM системе от Microsoft:
- На данный момент входит в ТОП 5 CRM систем в мире. Количество клиентов постепенно растёт из года в год.
- Новые клиенты могут начать работать только в виде облака — версия online. До этого была доступна версия на личном сервере — on-premise, старые клиенты продолжают и дальше ей пользоваться.
- Доступна для работы через браузер, плагин Outlook, мобильные приложения, и через специальное приложение Unified Interface.
- В последнем переосмыслении маркетологами стала известна под новыми названиями Dynamics 365 for Sales и Dynamics 365 for Customer Engagement. В народе продолжает именоваться Dynamics CRM.
- Из коробки клиент получает управление продажами, каталог продуктов и услуг, отслеживание действий. Также доступно управление маркетинговыми кампаниями, и управление инцидентами.
Для разработчиков полезно знать что:
- Средняя зп на рынке США: Junior — $87163, Middle — $127614, Senior — $151321
- Для подбора консультантов и программистов существуют целые агентства, например Nigel Frank.
Также давайте взглянем какое место CRM (Sales) занимает в экосистеме решений Майкрософта.
Начало использования
С точки зрения пользователя — всё просто. Получаем url адрес и переходим туда используя свой любимый браузер.
До недавнего времени Майкрософт рекомендовал использовать только Internet Explorer, но ничто не вечно под луной, и теперь со спокойной совестью можно работать через Chrome.
При переходе по адресу, придётся ввести логин и пароль учетной записи (CRM использует ADFS для аутентификации пользователей), и попадаем на домашнюю страницу.
Модуль Продаж
Давайте представим себя в роли менеджера по продажам.
Наша компания неделю назад провела рекламную кампанию, и директор по маркетингу занёс в систему лидов (Lead или Потенциальный Клиент) и назначила их на нас.
Что такое Лид? Ну, есть какая то компания, которая вроде бы заинтересована в наших услугах, и у нас есть возможность им что то предложить, но они еще не знают чего им точно надо.
Форма Лида выглядит вот так:
Мы им звоним и выясняем что нужно сделать, они вроде бы согласны с предложенным и готовы обсуждать дальше. Отлично! Это значит что мы можем квалифицировать (Qualify) лида, и CRM автоматически создаст из одной записи целых 3: Контакт (Contact), Организацию (Account) и Возможную Сделку (Opportunity).
Следующий этап после Лида — Возможная Сделка. На этом этапе идёт активное уточнение нужд клиента, мы приступаем к заполнению Продуктов Возможной Сделки, которые берутся из каталога Продуктов.
Стандартные поля для Возможной Сделки:
- Потенциальный Клиент — может быть как Контакт, так и Организация. Эта связь позволяет отследить всю историю работы с клиентом.
- Ожидаемая дата закрытия — показывает время завершения заказа. Может использоваться для примерного расчета получения денежных средств или для подготовки рабочей силы под проект.
Дополнительно можно заполнить таблицу Конкуренты (Competitors). Помогает для анализа конкуренции в целом, хранит историю выигрышей и проигрышей для каждой компании соперников.
Таблица (Sub-Grid) Команда Продажи (Sales Team) позволяет иметь список людей, работающих над сделкой.
При добавлении Продуктов в Возможную Сделку, происходит автоматический расчет ожидаемой прибыли. У разработчиков есть возможность её переопределить, если необходимо добавить новые поля в формулу расчета. Хотите сразу включить в расчет прибыли возможный откат? Не вопрос.
Важно отметить, что сделку можно закрыть как проигранную. CRM обязательно спросит причину и занесёт её в историю клиента как действие.
Следующим этапом является создание Коммерческого Предложения (Quote).
У Коммерческого Предложения есть свой жизненный цикл. Оно создаётся из Возможной Сделки в статусе Черновик (Draft) с подтягиванием её же продуктов. Пользователь может изменять продукты и их цену. Как только он дошел до того, что готов выслать предложение клиенту, запись переходит в Активный (Active) статус и запись становится нередактируемой.
Если клиент согласен с предложением, то оно закрывается со статусом Выигрыш (Won) и мы переходим на этап Заказ (Order). Если необходимо что либо поменять, то мы выбираем Пересмотр (Revise), при этом будет создано новое Коммерческое Предложение, с опять же подтянутыми продуктами.
Заказ — это по сути утвержденное Коммерческое Предложение. В нём содержится информация про продукты или услуги которые заказал клиент. Из него можно создать Счет-Фактуру (Invoice), которая может быть закрыта со статусом Оплачена (Paid) или Отменена (Canceled).
Дальше в ход должны вступать интеграции с другими системами. Например, MS NAV. Майкрософт предоставляет для этого готовое решение коннектор.
Имея такую историю по клиентам можно построить самый важный график в CRM — Воронку Продаж:
Она позволяет анализировать динамику продаж по различным стадиям, начиная с лида и заканчивая заказом. Например, можно находить узкие места, в которых теряется больше всего клиентов, и постараться их исправить. Также директор по продажам может оценить будущую прибыль, в зависимости от количества лидов на текущий момент.
Модуль Управления Обслуживания Клиентов
Содержит Инциденты (Cases), которые создаются службой поддержки, автоматически через имейлы или с помощью интеграций со сторонними системами. Инциденты хранят в себе информацию о возникшей проблеме клиента. Они могут быть добавлены в специальные очереди, что позволяет более эффективно распределять нагрузку на службу поддержки.
Dynamics CRM имеет функционал Базы Знаний (Knowledge Base), для помощи в решении проблем. База содержит статьи, которые сгруппированы по темам.
Также есть возможность следить за KPI (Ключевой Индикатор Производительности) с помощью настраиваемых SLA (Соглашение об уровне обслуживания). SLA настраиваются в зависимости от часов работы, дней работы, и графика в выходные дни. При создании Инцидента берутся эти SLA и высчитывается время, за которое необходимо решить проблему.
Для пользователя это видно в виде таймера на главное форме Инцидента. Обратный ход можно остановить, если, к примеру, пользователь ждёт ответа от клиента.
Модуль Маркетинга
Маркетинговые списки — удобный способ сгруппировать Контакты, Организации и Лиды в группы по какому либо критерию или вручную. Они могут быть как статические так и динамические (очевидно, что для создаваемых по заранее заданному критерию). В конечном счёте, эти списки используются для каких либо маркетинговых действий: рассылка сообщений с новостями, промо материалами итд.
Кампании в Dynamics CRM представлены обычными кампаниями (Campaings) и быстрыми кампаниями (Quick Campaigns). В целом, они создаются для контроля действий по каждой из них, в также для удобного просчета ROI (Return on investemnts / Окупаемость Инвестиций).
У кампаний есть список откликов (Campaign Responses), который создаётся для понимания её успешности. Отклики можно вносить как вручную, так и автоматически, используя входящие электронные сообщения.
В чем различия Кампании и Быстрой Кампании?
Быстрая кампания может иметь только один тип активности, один список клиентов, не имеет встроенных метрик, не может создаваться из шаблонов кампаний, предполагает быстрое исполнение. Как пример, кампания по отправке электронных сообщений перед распродажей на день Благодарения. Сгенерировали список для рассылки, произвели её, получили отзывы, посчитали количество сгенерированных лидов и ROI на основе конверсии Лида в Возможную Сделку, закрыли кампанию.
Средства расширения функционала
Наконец то можно перейти к тому, для чего я всё это затеял.
Существует много способов для расширения функционала CRM. В этой статье я опишу элементарные вещи, такие как создание новых Сущностей (Entities), Полей (Fields), Форм (Forms), Представлений (Views).
Solutions
Для начала, необходимо рассказать про Решения (Solutions). Это такие пакеты, содержащие в себе полное или частичное состояние любого объекта, добавленного туда. Они используются для переноса компонентов из одной системы в другую, а также для разработки новых компонентов. Добраться до списка Решений можно пройдя в меню через Settings/Solutions.
Перед нами форма только что созданного Решения.
Обратите внимание на поле Издатель (Publisher). Оно хранит в себе Название и Префикс Разработчика компонентов. В зависимости от того, в каком Решении будет создан компонент, такой префикс он и будет иметь. Например, Издатель имеет префикс habr, соответственно новая сущность User будет иметь системное имя вида habr_user.
Решения можно Экспортировать или Импортировать. При экспорте можно выбрать каким оно должно быть. Управляемое (Managed) или неуправляемое (Unmanaged).
Solutions делятся на 3 вида.
- Default Solution — Решение по умолчанию или глобальное решение. Каждая CRM система имеет одно Решение по умолчанию. Оно содержит в себе вообще всё, что есть в текущей системе.
- Managed Solution — можно создать во время экспорта неуправляемого решения с помощью выбора соответствующего параметра. Всё, что находится внутри этого решения не может быть в дальнейшем изменено. Обычно такой вид используется для распространения готового продукта для CRM систем нескольких клиентов.
- Unmanaged Solution — всё, что находится внутри такого решения может быть удалено или изменено, также в него можно добавлять новые кастомизации. Если вы кастомизируете CRM индивидуально (для каждого клиента — свои изменения), то вы, скорее всего, будете использовать только этот тип решений.
Для того, чтобы изменения вступили в силу, их необходимо опубликовать (Publish). Для этого достаточно нажать на необходимую кнопку выбрав необходимое Решение.
Entities
Или Сущности. С их помощью можно определить типы записей. Самая близкая аналогия — таблица БД.
Давайте создадим нашу первую Сущность. Переходим в раздел Entities и нажимаем New.
Откроется новая форма для создания сущности.
Тип Собственности (Ownership) — позволяет выбрать владельца записи. По умолчанию это Организация, т.е владельца нет как такового. Если выбрать Пользователь или Группа — то сущность будет иметь поле Owner. В дальнейшем, в зависимости от типа собственности, можно гибко настроить доступ пользователей к записям и их видимость в подразделениях.
Если выбрать пункт Define as an activity entity, то сущность станет действием. Действия — это записи, которые могут отображаться в календаре. Для такой сущности будут автоматически добавлены поля Времени Начала, Времени Конца, Продолжительность. Действие можно будет Отменить или Выполнить. Быть владельцем такой сущности может только Пользователь или Группа.
Во вкладке Primary Field можно задать параметры Основного поля, которое будет обязательным для заполнения.
При желании, можно поменять имя или тип на что то другое. В таком случае рекомендую позаботиться о том, чтобы оно заполнялось для каждой записи, и являлось уникальным. Значение этого поля используется как обозначение Lookup поля. Как пример, lookup поле Publisher на форме Решения. (PS типы полей будет ниже)
Также есть довольно большой список настроек, которые можно задать. Пройдёмся по самым часто использующимся.
Зоны видимости сущности (Areas that display this entity) — можно задать вкладки главного меню, в которых будет доступна сущность.
Разрешить быстрое создание (Allow quick create) — по умолчанию новая запись создаётся в новом окне. При активации данной функции появляется возможность создавать запись из активного окна, с вводом только необходимых полей.
Определение дубликатов (Duplicate detection) — позволяет запретить создание одинаковых записей с помощью правил.
Аудит (Auditing) — можно выбрать поля сущности, для которых будет храниться вся история изменений. С этой настройкой нужно быть осторожным, можно получить значительное увеличение объема БД.
Fields
Или Поля. Используются для определения отдельных элементов данных.
После создания сущности CRM автоматически создаст базовые поля
Давайте дополним сущность своими. Нажимаем New и видим форму созданию нового поля.
Display Name — имя, которое будет отображаться на форме записи.
Field Requirement — устанавливает обязательность поля. Всего есть 3 вида. Optional — позволяет создать запись без заполнения поля; Business recommended — аналогичен опциональному, но возле поля будет стоять звездочка как рекомендация о заполнении; Required — нельзя создать запись без заполнения этого поля.
Name — системное имя поля.
Searchable — позволяет использовать поле для поиска записей по его значению.
Field Security — позволяет дополнительно настраивать кому показывается данное поле.
Auditing — позволяет включить аудит поля. (Будет сохраняться история изменения)
Data Type — тип данных поля. Всего существует 12 типов данных.
Single Line of Text — строка текста. Может содержать до 4000 символов, но можно ограничить на меньшее число.
Option Set — список Имя-Значение
Two Options — обычный Boolean
Image — картинка
Whole Number — Целое число в границах от -2,147,483,648 до 2,147,483,647.
Floating Point Number — число в границах от -100 000 000 000 до 100 000 000 000, которое может содержать до 5 знаков после запятой
Decimal Number — число в границах от -100 000 000 000 до 100 000 000 000, которое может содержать до 10 знаков после запятой
Currency — денежные значения в границах от -922 337 203 685 477 до 922 337 203 685 477
Multiple Lines of Text — несколько строк текста. Может содержать до 1 048 576 символов, но можно ограничить на меньшее число.
Date and Time — дата и время. В БД данное поле хранится в UTC, поле можно настроить для показа UTC или локального времени пользователя. Также можно показывать дату и время либо только дату.
Lookup — представляет из себя ссылку на запись любой сущности. Хранит в себе сразу 3 значения (Имя записи, GUID и тип сущности). По правилу хорошего тона в конце имени пишется 'id', как обозначение поля lookup. Небольшое отступление: справочник от Майкрософта переводит название этого поля как Поиск. Однако все называют его просто Лукап.
Customer — по факту это мульти Lookup, который может ссылаться только на 2 сущности — Contact или Account.
Еще есть 3 типа полей. Не каждый тип данных может иметь все 3 типа полей.
- Simple — обычное поле
- — Calculated — содержание может быть настроено с помощью редактора. Пример:
- Rollup — содержит агрегированное значение, вычисленное по дочерним записям. Настраивается с помощью редактора. Примером такого поля может служить общая сумма всех сделок для менеджера.
Forms
Каждая сущность содержит свои Формы. Они позволяют настроить отображение полей для разных случаев.
Всего есть 4 типа форм:
Main — форма, которая будет показываться при открытии записи через браузер.
Mobile — эта форма будет открываться на мобильном устройстве.
Quick View — позволяет встраивать данную форму в формы других сущностей. Например, Main форма сущности Post содержит поле Author (которое ссылается на сущность User), и мы показываем дополнительные данные User через его Quick View форму.
Quick Create — форма для быстрого создания записи (Без открытия нового окна браузера)
Настройка Форм
Dynamics CRM позволяет гибко настраивать вид и функционал Форм.
Основные возможности редактора форм:
- Добавление поля
- Удаление поля
- Скрытие поля
- Добавление Бизнес Правил
- Изменение разметки формы
- Добавление JS скриптов и их регистрация на события формы
Вот так будет выглядеть редактор формы для нашей сущности Post.
В нашем случае у нас имеется всего 1 Tab именованный General (обведён синей рамкой), внутри которого имеется один Section также с именем General.
Вкладка Home
Вообще, Main формы состоят из 4 частей: Header, Body, Footer, а также Navigation слева.
Для того, чтобы выбрать что вы в данный момент хотите редактировать придётся воспользоваться группой Select на риббон ленте.
Поля добавляются двойным нажатием или перетягиванием.
Удаляются же кнопкой Remove. Required поля (которые с красной звездочкой), так просто удалить с формы не получится. Придётся сначала изменить их тип на Optional.
Кнопка Form Properties позволяет добавлять JS файлы на форму, и регистрировать их функции для событий форм и полей.
Вкладка Insert
Во вкладке Insert мы работаем только с телом формы. Здесь мы изменяем её разметку.
Команды риббон ленты в данном случае:
Section — добавляет секцию в выбранный tab. Может содержать 1-4 столбца.
Tabs (Вкладки) — множество вариантов добавляют вкладку с количеством секций 1-3 разной ширины.
Вот пример вкладки с тремя секциями. Одна секция имеет три столбца, две другие по одному. Каждый столбец это потенциальное месторасположение поля.
Sub-Grid — добавляет список записей связанной (или нет) сущности на форму.
Коротко про то, что это такое.
Например, Хабр добавил функцию пожертвований для статей. Создаём сущность Donations которая содержит в себе lookup на Post. При этом, при создании поля создаётся связь N:1.
Всё, теперь мы можем добавить Sub-Grid показывающий пожертвования. Окно настройки Sub-Grid выглядит так:
А наша форма будет иметь такой вид:
Spacer — создаёт пустое место
Quick View Form — добавляет форму быстрого вида. Мы уже такую делали для автора.
Web Resource — добавляет веб ресурс на форму. Например, интерактивная html страница или Silverlight приложение.
IFrame — можно добавлять и их тоже
Notes — добавляет панель для создания заметок
Views
Или Представления, используются для отображения списков записей.
Можно задать отображаемые поля, их ширину, а также фильтры и сортировку.
Вот пример, на котором показываются только активные посты.
Представления бывают:
Общие — представления, доступные всем пользователям. При создании новой сущности автоматически создаются Активные и Неактивные представления.
Личные — принадлежат отдельным пользователям. Могут быть созданы администратором, и затем отдельно назначены на другого.
Системные — недоступны напрямую для выбора из списка представлений, а существуют как дополнения, расширяющие функциональность отдельных элементов интерфейса. Например, быстрый поиск, расширенный поиск
Создадим своё личное представление?
Жмём на список представлений и выбираем Create Personal View.
Открывается новое окно для настройки представления. Можно взять за основу существующее представление выбрав его в Use Saved View.
Edit Columns позволяет выбрать отображаемые поля
Results позволяет проверить какие записи будут выведены после наложения фильтра.
Фильтр строится добавлением условий с помощью Select и их группировкой через AND/OR.
Вот так выглядит готовый фильтр. Сохраняем его попутно дав название, и получаем готовое личное представление.
Заключение
В данной статье я дал информацию для отличного старта в разработке для Dynamics CRM. В следующих статьях будем разбираться с остальными доступными кастомизациями, официальным SDK, must have приложениями, писать плагины (Plugins) и рабочие процессы (Workflows).
Буду благодарен за отзывы и спасибо, что прочитали статью.
