Dependent fields are when a field appears or becomes required depending on the value of another field; hidden fields are when unnecessary fields are removed from the form so they don't get in the manager's way. Bitrix24 (Alaio) has no full-blown dependency builder along the lines of "show field B when field A has this value", but the same effect is achieved with a combination of stock settings and robots: card configuration, required-by-stage rules, checks in a business process, and auto-clearing of stale values. Let's walk through the approach step by step.
Why do you need dependent and hidden fields?
A deal card accumulates fields: legal entities need a tax ID and a registered address, individuals need passport data, delivery needs an address and a time slot. If you show everything to everyone, the manager faces a wall of dozens of fields, fills in every other one, and skips what matters. Dependent and hidden fields solve this: the form shows only what's relevant to the current customer and stage of work. The direct payoff is filling speed and data cleanliness: the fewer irrelevant fields on the screen, the fewer "just to save it" values land in the CRM, and the more accurate the filters, reports, and documents built on those fields.
What can the stock card configuration do?
A CRM card can be configured without code: hide fields, change the order, group fields into sections, and save a common layout for all employees. This is static hiding: a field is either visible or not — visibility doesn't depend on other fields' values. The second stock mechanism is required-by-stage: a field becomes required when a deal moves to a particular stage (for more on requiredness and field types, see the article on fields in Bitrix24). The stock interface doesn't offer dynamic dependency along the lines of "you chose 'Legal entity' — a requisites block appeared", so the dependency is emulated with a combination of card sections, required-by-stage rules, and check robots — that's what the next two sections cover.
How do you emulate a dependency through stages and requiredness?
The idea: instead of "show a field when there's a value" — "require a field at the stage where it becomes needed". A delivery example: while the deal is in "Negotiation", the delivery fields aren't required and sit in a collapsed section at the end of the card; on the move to the "Delivery" stage, the address and time slot become required — the card itself demands they be filled in at the stage change. A collapsed section with rare fields visually works like hiding, and required-by-stage works like a dependency on the stage. The limitation of this approach: the check fires only on manual moves — changes via the API, by import, or by robots bypass it. That gap is closed by checking field combinations in a business process.
How do you check a field combination with a robot?
The dependency "if A, then B is required" is two conditions at once: "Customer type = Legal entity" AND "Tax ID is empty". The stock Condition block in the workflow designer expresses this with a chain of nested blocks that quickly becomes unreadable. The Compound condition (AND / OR / NOT) robot checks up to four conditions with AND or OR logic in a single action, and in JSON mode it accepts a condition tree of arbitrary nesting — returning a single Y/N flag. Among the operators are equal, not equal, greater than, less than, contains, empty, not empty; strings are compared case-insensitively by default. On N, the process returns the deal to the previous stage or gives the manager a task with a list of the unfilled fields.
How do you substitute and clear dependent values?
Two robots cover the flip side of the dependency. Ternary choice (if-then-else) compares two values and returns one of two preset results plus a "condition met" Y/N flag: for instance, by the "Customer type" field it inserts the right form of address into an email — without a chain of conditions in the designer. And Clear a field sets an empty value in any field of a deal, contact, company, or lead: if the manager changes the customer type from "Legal entity" to "Individual", the robot clears the tax ID and the registered address so the previous variant's data doesn't slip into documents and reports. For how to attach robots to stages, see the article on setting up robots.
How to group fields into card sections?
Fields on a deal, lead, contact or company card can be grouped into sections out of the box. On the card, click "Create section", give it a name — "Delivery", "Payment", "Documents" — and drag the fields you need into it by their left edge. A section can be collapsed, renamed or deleted, and the fields inside it reordered. While you rearrange the card, only you see the changes. To make the layout shared, an administrator saves it for all employees in the card settings: after that everyone has the same sections, and personal tweaks stop drifting apart.
A section is a block with a heading, which makes a long card easy to scroll. If you need a heading right between fields of one section, without a separate block, use the Section divider custom field: a thin line with a caption that stores nothing and only splits fields into groups. It is how a long "About the deal" section gets structure without being chopped into five small ones.
Why does a hidden field still show up in the filter?
Hiding a field on the card changes only the card. The filter, list columns, Excel export, reports, the REST API and workflows all see the field as before. So a field you removed from a sales rep's view can still be found in the filter and shown as a list column.
The opposite case is common too: the field is on the card, but you cannot find it in the filter. There are two reasons. First, every employee sets up the filter for themselves — the field has to be added via "Add field" in the filter itself. Second, a custom field has a "Show in filter" checkbox in its settings. If the checkbox is off, the field will not appear in the filter's field list no matter how hard you look. A similar checkbox controls whether the field is shown in the list.
The practical takeaway: hiding is interface tidiness, not data protection. CRM role permissions do not help here either: they are granted for the whole record, not for a single field. If a value on the card should be editable only by administrators and selected employees, use the Locked value field: everyone else sees it as read-only. This is interface protection too: imports, REST and workflows can still change the value, which is exactly what automation needs.
Checklist
Hide rare fields: configure the card, group fields into sections, save the layout for everyone. Check which fields are needed in the filter and turn on Show in filter for them. Turn on required-by-stage for the fields of specific stages. Add a check robot for field combinations on stage moves. Set up auto-clearing of fields when the defining value changes. The robots for this scheme are in the Roboteka catalog; don't have the one you need? Describe the task — we'll build the robot for free.