Let’s take a closer look at the updates:

• considering mandatory field requirements in case parameters only when setting the status to "closed";
• default values for dropdown lists;
• additional fields for companies;
• field visibility settings;
• configuring field dependencies.

Setting up mandatory fields helps your team remember to include important information that can later be used for filtering cases, generating reports, or triggering automated actions.
You could make case fields mandatory before, but the validation was applied whenever any action was performed on the case. That meant agents couldn’t send responses or update case details until all required fields were completed. While this setup can be useful, it didn't work well in situations where agents needed to first ask the user for more information to fill out those fields accurately.

Now, case fields have two separate settings:

• mandatory to fill for any action (star icon);
• mandatory to fill only when setting the status to "Closed" (lock icon).

If a field is set as "required for closing" – meaning the lock icon is activated – agents won’t be able to manually set the status to "Closed" or use a macro to do so until those fields are filled out.

• At the same time, it's still possible to set the status to "Closed" through rules or the API without filling out these fields – just like with fields that are mandatory for any action.

Usually, custom fields of the "list" type have a dash set as the default, meaning agents or users must actively choose one of the available options. But sometimes it's helpful to set a different default value – like the most likely choice.

To set a default value for a list, simply tick the star next to it in the field settings.

The selected default value will be applied only when creating a new case / user / company through the agent’s account interface or via the API, as well as when new cases are created through the widget or ideas form in the help center.

A company's data can contain a lot of useful information essential for rule processing or for agents – for example, the paid tariff, number of enabled agents, contract expiration date, and so on.

To create an additional field for a company, go to: Administrator account → Channels section → Data fields subsection → click "Add field" → select "Company fields" as the affiliation.

When creating a field, pay attention to the checkbox at the bottom of the form – "The completed field is displayed in all forms where there is the "Company" field". This checkbox is ticked by default. That means if this custom field is filled out, it will show up in the same forms where the "Company" field appears (on the case page in the user data panel, on the user's page, and in the incoming call card). This is handy if you want to see key company details right away 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.

Company fields can also be used in automation rules: you can check their data through conditions and fill them in using actions.

Previously, it was only possible to set field visibility for all agents at once. This setting allowed data to be hidden in the interface while still using it in automation rules, reports, or via the API.

Now, in all forms available to agents, there's a flexible option to customize field visibility. You can select which agents see a field based on their roles, group access, or even specify individual names.

Field visibility can be customized separately for each form. For example, you can set it up so that certain information isn't visible to agents on the user data panel within a case, but is still accessible on the user’s profile page.

Besides hiding sensitive information, this setting helps simplify work for employees across different departments. For instance, you can make sure that accounting staff only see fields related to contracts, invoices, and deadlines, while support agents see information about the purchased product and subscription plan.

Note: for existing fields in forms where visibility was enabled, the option was set to "all agents". In forms where visibility was disabled, the option was set to "no one".

Previously, Deskie did not support creating hierarchical field structures, such as those where each category has only its specific subcategories.

As a result, you had to either create the entire structure within a single field, which was difficult to manage due to a large number of options or create separate fields that were always visible, even when they weren't needed for a specific category of issues.

Now, this can be easily resolved by configuring field dependencies.

For more details on all the nuances of setting up dependent fields, see the Deskie knowledge base.