Fields classification
1. In terms of data affiliation, fields can refer to either a user, a case, or a company.
In user or company fields, the data is fixed for a specific user or company and does not change from case to case. An example is the "Email address" field.
Case fields, on the contrary, are fixed for a specific case and are not related to the user or company. For example, the checkbox "A task has been set".
The list of fields has a corresponding division into these three types. If necessary, any of the blocks can be collapsed.
2. According to the editing capabilities, fields are divided into standard and custom ones.
Standard fields cannot be disabled or completely removed. You can only edit, although editing is significantly limited. All this is done because the standard fields are an integral part of the platform, and a lot is tied to them.
Custom fields are fully customizable. You decide what type of field to create, in what forms and under what name they are displayed, and whether they are mandatory or not.
3. Depending on the data representation, the fields are divided into five types: text field, text area, checkbox, dropdown list, and date.
In the field list, the field type is displayed immediately below its name. You cannot change the type of standard fields. With custom fields, the type is set only when the field is created and cannot be changed later.
2. Form selection
You can choose where to display a standard or custom field.
Submit an idea (section "Ideas" in the Help Center);
Submitting email request via widget;
User profile (user account, help center);
User page (agent account, "Users" section);
User data (agent account, specific case, right sidebar);
Adding user (agent account, page for adding a case);
Incoming call (agent account, incoming call pop-up window);
Case parameters in agent account (agent account, specific case, left sidebar);
Case parameters in user account (user account, specific case, left sidebar).
When creating/editing fields, there is a tooltip to the right of the name of each form, that helps you understand which form it is.
If a field is added to the "User profile" or "Case parameters in user account" forms, which are located in the user's account in the help center, you can choose whether the user can edit the field or only view it.
3. Editing standard fields
Each standard field displays by default all the forms it can be added to. In most cases, the desired forms are already active and cannot be disabled. However, there is the option to change the field name in any of the forms and, in some cases, specify whether the field is required to be filled in. Additionally, for forms that users can access, you can choose whether to allow or prevent them from editing the field.
4. Creating and editing custom fields
When creating an additional field, you need to select:
the field's affiliation: whether it belongs to a case, user, or company
the field type: text field, text area, checkbox, dropdown list, or date;
the forms where the field will be added.
Let's break it down with a specific example. Suppose you want to create a field called "Request type" so that when a user submits a question via a widget, they can specify the nature of the issue by selecting from a list: question, problem, bug, complaint, or appreciation. After the case is created, the agent should see the specified information in the case parameters on the case page, and the user should see it in their personal account in Deskie.
Step 1: specify the field's affiliation — it would be the case field, as the data it collects pertains to a specific case rather than to the user or the company they represent;
Step 2: choose the field type – "dropdown" – and specify the options for selection in the drop-down list;
Step 3: activate the necessary forms — "Submitting email request via widget", "Case parameters in agent account" and "Case parameters in user account";
Step 4: enter the field name for each form — this will be sufficient to create the field.
5. Data field settings
a) Mandatory filling
Configuring required fields helps agents remember to provide important information that can later be useful for filtering cases, reports, or automated actions.
All fields have a mandatory setting for any action (indicated by an asterisk icon). Case fields have two separate settings:
mandatory for any action (asterisk icon);
mandatory only when setting the status to "closed" (lock icon).
If a field is set as "required for case closing" — meaning the lock icon is activated — an agent will not be able to manually set the status to "Closed" or use a macro to do so until such fields are filled in.
These settings apply only to manual actions in the agent's account, and the fields will still be available for automatic editing through rules and API, including scenarios where the "Closed" status is assigned to a case by Deskie.
b) Restriction on clearing and editing
— For "Text Field", "Text Area", and "Date" field types, you can enable restrictions that prevent clearing or both clearing and editing. Since editing includes the ability to clear, enabling editing automatically allows clearing as well.
— For fields of types "Checkbox" and "List", you can enable a restriction against editing.
These settings apply only to manual actions in the agent's account, and the fields will still be available for automatic editing through rules and API.
c) Field order in forms
You can also change the order of the fields in the forms. To do this, go to the "Sorting fields in forms" tab, find the desired form and arrange the fields in the desired order.
d) Default list values
In custom fields of type "List", a dash is set by default, meaning agents or users must manually select one of the proposed values. However, it can sometimes be useful to set a different default value for the list, such as the most likely option.
To set a default value for the list, simply mark the asterisk icon next to it in the field settings.
The selected default value will be applied only when creating a new case, user, or company in the agent's account interface or via API and when creating new cases through a widget or idea form in the help center.
e) Field visibility
In all forms accessible to agents, you can flexibly configure field visibility. You can select which agents can see a field based on their roles or group access or even specify individual names.
Visibility can be customized for each form individually. For example, you might set it up so agents don’t see certain user information on the case page, but that info is still visible on the user’s profile page.
Besides protecting sensitive data, this setting makes it easier for different teams to focus on what matters to them. For instance, accounting staff can be limited to fields about contracts, invoices, and deadlines, while support teams see details about the purchased product and subscription plan.
You can also hide certain fields in the interface so they don’t distract agents, while still using fields' data for automation rules, reports, or API.
f) Display depending on channel
In the "Case parameters in agent account" form within the agent account, you can specify which channels will display custom case fields, as well as the "Reply By" and "Close By" fields.
For example, if you only track SLA in groups that handle chats, you can choose not to display SLA tracking fields in email-based cases.
g) Company field features
At the bottom of the company field creation form, there is a checkbox labeled "The completed field is displayed in all forms where there is the 'Company' field". This checkbox is ticked by default. If the custom field is filled out, it will appear everywhere the "Company" field does – like on the case page in the user data panel, the user’s profile page, and the incoming call card). This is convenient if you want to see key company information immediately without navigating to the company profile.
Although the company field will be visible in the user’s data, it can only be edited on the company’s profile page.
h) Date field type features
When working with this type of field, a calendar pops up so you don’t have to enter the date manually. By default, the calendar opens to the current month, with today’s date highlighted in blue. You can quickly switch between months and years using the calendar header:
В правилах и шаблонах есть условия и действия, чтобы вы могли учитывать и изменять значения в полях типа «Дата». Подробнее
По каждому созданному полю типа «Дата» появляется возможность сортировки обращений: «новые в начале» или «старые в начале»:
В панели фильтров по каждому полю типа «Дата» появляется отдельный блок с параметрами для фильтрации. Доступны следующие опции:
— дата не выставлена,
— до вчерашнего дня,
— сегодня,
— от завтрашнего дня,
— [дата] меньше,
— [дата] равна,
— [дата] больше,
— от [даты] до [даты].
Благодаря относительным опциям (до вчерашнего дня, сегодня и от завтрашнего дня), фильтры обновляются динамически в зависимости от текущей даты, и вам не нужно каждый день создавать новые фильтры.
6. Зависимые поля
Вы можете создавать древовидные структуры полей, например такие, когда у каждой категории есть только свои определённые подкатегории.
Задача решается с помощью настройки зависимости полей.
а) Зависимость в разных формах
Во всех формах зависимость можно задать только при соблюдении двух условий:
у зависимых полей одинаковая принадлежность — к обращению, пользователю или компании;
оба поля добавлены в одну и ту же форму.
Исключение — формы «Отправка email-запроса через виджет» и «Создание обращения из центра поддержки», в которых зависимость можно задать от полей любой принадлежности, добавленных в эти формы.
Разберем конкретный пример. Добавим кастомное поле пользователя «Номер договора». Так как это именно поле пользователя, зависимость можно выбрать только в формах «Добавление пользователя в аккаунте сотрудника», «Данные пользователя на странице обращения», «Данные пользователя в аккаунте сотрудника», «Данные пользователя в аккаунте пользователя» — и зависеть значение поля может только от других полей пользователя. Укажем, что поле «Номер договора» зависит от поля «Тариф».
В итоге поле «Номер договора» будет отображаться, только если в данных пользователя заполнено поле «Тариф».
При этом в формах «Отправка email-запроса через виджет» и «Создание обращения из центра поддержки» можно задать зависимость от полей любой принадлежности, так как в этих формах они могут соседствовать. Для примера укажем зависимость нашего поля «Номер договора» от поля «Группа» со значением «Вопросы по оплате».
В итоге поле «Номер договора» отобразится в форме, если пользователь выберет в виджете отправки email-запроса группу «Вопросы по оплате».
То же самое касается полей обращения. В формах «Параметры обращения в аккаунте сотрудника» и «Параметры обращения в аккаунте пользователя» можно задать зависимость только от других полей обращения, добавленных в эти формы, а в формах «Отправка email-запроса через виджет» и «Создание обращения из центра поддержки» — выбрать зависимость от любого поля.
б) Зависимость от полей разных типов
Зависимость может быть настроена от поля любого типа и будет работать следующим образом:
Выбор зависимости от полей типов «текстовое поле», «текстовая область», «чекбокс», «дата» означает, что зависимое поле будет появляться в том случае, если родительское поле непустое, то есть добавлен любой текст в текстовом поле или области, отмечен чекбокс или указана дата;
Выбор зависимости от полей типов «Список» и «Метки» позволяет выбрать определённые значения этих полей, при которых будет появляться зависимое поле.
в) Три уровня зависимости
Зависимость ограничивается тремя уровнями вложенности. Например, можно сделать структуру, как в примере выше:
поле «Категория обращения» (первый уровень);
поле «Подкатегория обращения» (второй уровень);
поле «Тип вопроса» (третий уровень).
Добавить зависимость от поля третьего уровня «Тип вопроса» уже не будет возможности, так как это поле уже зависит от двух других полей, поэтому оно даже не будет предлагаться при настройке зависимости в поле «Зависит от».
г) Очистка зависимых полей
Значения в зависимых полях очищаются, если условие зависимости перестаёт соблюдаться.
Например, в обращении были заполнены такие поля:
Категория обращения — Возможности сервиса;
Подкатегория обращения — Общие вопросы;
Тип общего вопроса — Интеграции.
В процессе общения выяснилось, что пользователь обращался не за общей информацией, а с проблемой по работе интеграции. Для этих случаев есть своя категория обращения «Проблемы с сервисом», и когда сотрудник изменит значение поля «Категория обращения» на нее, поля «Подкатегория обращения» и «Тип обращения» очистятся, так как выставленные в них ранее значения больше не соответствуют условиям зависимости.
д) Несоответствие зависимых полей условиям зависимости
В веб-интерфейсе аккаунта сотрудника зависимые поля не отображаются и, соответственно, не могут быть заполнены ни вручную сотрудником, ни через шаблоны и правила, пока не будет соблюдено заданное в настройках условие зависимости, то есть пока родительское поле не будет заполнено или в нём не будут выбраны определённые значения.
При этом во время работы не через веб-интерфейс зависимые поля всё-таки можно заполнить даже без соблюдения условий зависимости, например, при заполнении полей через API или мобильные приложения, в которых пока нет поддержки зависимости полей.
В таком случае зависимые поля будут заполняться и отображаться, несмотря на пустые или несоответствующие родительские. Но такие поля будут задизейблены до момента, пока зависимость не будет соблюдена, а при наведении на них курсора сотрудники будут видеть подсказку о необходимости заполнить родительское поле или выбрать в нём конкретное значение, при котором зависимое поле станет доступным для редактирования.
Если же родительское поле будет отредактировано и в нём будет выбрано несоответствующее значение, то зависимое поле будет очищено по стандартной логике.
е) Зависимые поля в виджетах
Если хотите, чтобы поле можно было добавить в виджет для отправки запроса по почте, отметьте форму «Отправка email-запроса через виджет» в настройках нужного вам поля.
При добавлении родительских полей в виджете будут также добавляться и зависимые поля, но вы можете отключить их отображение с помощью иконки глазика, если в каком-то виджете они не нужны.
При добавлении полей, для которых задана зависимость в форме «Отправка email-запроса через виджет», будет также добавляться и соответствующее родительское поле.
7. Прочие моменты
Для кастомных полей название, которое отображается в списке полей в аккаунте администратора, берётся из первой активной формы.
Если у вас отключён центр поддержки, формы, связанные с ним («Оставить предложение», «Профиль пользователя»), скрываются во всех полях — стандартных и кастомных.
Если для формы «Данные пользователя» у вас включены поля «ВКонтакте», «Facebook», «Телеграм» и другие стандартные поля с контактными данными, которые заполняются сервисом автоматически, в случае если пользователь еще не обращался к вам по этим каналам и поля пустые, мы скрываем их, чтобы не занимать даром место.
В параметрах обращения поля «Отвечать с адреса» и «Получатель» для большего удобства закреплены наверху.
Поддержка дополнительных полей доступна в API, правилах и шаблонах.
Поля можно отобразить в общем списке обращений, чтобы отслеживать нужную информацию прямо из списка, без перехода в сами обращения:
