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 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.

Checklist

Hide rare fields: configure the card, group fields into sections, save the layout for everyone. 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.