In a hypothetical CRM, a salesperson must enter a delivery address before the customer has chosen a product. They type “later.” The field is technically complete; in practice, the system has taught someone to bypass a rule.
A requirement helps when the information can already be obtained and is needed for the next action.
Connect the field to a decision
Ask two questions for every field: who uses its value, and what will they do with it? If there is no answer, reconsider making it mandatory.
Some Bitrix24 fields can be required at particular stages, subject to the plan. See the official instructions.
First map when information becomes available. A callback contact is needed when handling an enquiry; a delivery address becomes relevant once the order is clear. This illustrates process logic, rather than a universal rule.
Write a short field specification
Record:
- why the value is needed;
- when it becomes available;
- who enters it and who checks it;
- what happens if the customer does not yet know.
Add a clear hint and a correct example. Consider a controlled list for recurring choices when appropriate. Free text captures nuance but can turn “Astana,” “City of Astana” and a typo into separate neighbours in a report.
Do not require invented information merely to advance a stage. Agree an exception route.
Test a real workflow
Ask a salesperson to process an ordinary enquiry using their own role. Note where they stop, search for information or copy a placeholder. After changes, check forms and integrations too: they have their own data-transfer sequence.
Judge success by whether the information is useful, rather than whether every box contains something.
If the record resembles an astronaut application, discuss a Bitrix24 audit with QQDev. Bring your required-field list and examples of employees filling it in purely for compliance.