Task fields in Bitrix24 are the attributes a task is made of: title, responsible person, deadline, project, status, CRM link. Custom fields are added on top of the system ones — tailored to a company's specifics. This article covers what fields a task has, how to set up your own, and how automation works with fields: finding tasks by their values, updating deadlines and responsible people, validating data before a task is created.
What fields do Bitrix24 tasks have?
The system set: title and description, creator, responsible person, participants and observers, deadline, project (group), priority, status, tags, time estimate, and a link to CRM items — a lead, deal, contact or company. The CRM link is the key field for automation: it's exactly what a business process uses to find the tasks belonging to a particular deal. Some fields appear in the task form only after they're enabled in the form settings — if you don't see participants, for example, add them to the visible set. For oversight, four fields matter most: responsible person, deadline, project and status — they're what filters for overdue tasks and workload reports are built on.
How do I add custom fields to tasks?
When the system set isn't enough — you need to store a request number, a type of work or a link to an external system in the task — the portal administrator adds custom fields in the task settings. Each such field gets a service code with the UF_ prefix — you'll need it for business processes and the REST API. The principles are the same as for CRM fields (more in the article on fields in Bitrix24): choose the type by how it's used — a list is handy to filter and report on, a string stays free text; you can change the name at any time, but not the type after the field is created. Custom fields show in the task form, work in the task-list filters and are available to automation on a par with the system ones.
How do business processes work with task fields?
Business processes in Bitrix24 are usually launched on CRM entities, and tasks are created as steps: a deal process assigns the rep a task, which then has to be found and updated (how processes work as a whole is covered in the article on business processes). In robots and REST, task fields are addressed by uppercase codes: TITLE — title, RESPONSIBLE_ID — responsible person, DEADLINE — deadline, PRIORITY — priority. The Update task by ID robot takes a task ID and a set of fields in JSON — e.g. {"TITLE":"New title","RESPONSIBLE_ID":5,"PRIORITY":"2"} — and returns a success flag of Y/N. This is how a process pushes a task's deadline when a deal changes stage, or reassigns it when the responsible person changes — with no manual edits.
How do I find a task by field values?
To update a task you first need its ID. The Find task by condition robot searches tasks by filter: responsible person, a substring in the title, project, a deadline range, status, a link to a CRM entity (e.g. DEAL_10 — tasks of the deal with ID 10) or an arbitrary JSON filter; there's sorting and a result limit. It returns the ID and title of the first task found, the full list of IDs, the count, and a "found" flag of Y/N. A typical scenario is duplicate protection: before creating a "contact the customer" task, the process checks whether there's already an open task for this deal; if there is, it doesn't create a new one but pushes the existing one's deadline via update by ID.
How do I validate data before creating a task?
A "call the customer back" task is useless if there's no phone in the card. The Check field is not empty robot checks whether a field of a deal, contact, company or lead is filled in and returns a Y/N flag plus the field's current value. In task scenarios it works like this: before creating a call task, the robot checks the contact's phone; if the field is empty — instead of a call, a "complete the card" task is created with a list of the missing data. The same trick safeguards any process action that needs data: check completeness before the step, rather than handling errors after it. The Y/N flag from the robot's response is compared in the built-in "Condition" block, so the check slots into any existing process without rebuilding it.
Conclusion
Task fields are the foundation of oversight: system fields cover deadlines and responsibility, custom fields store a company's specifics, and field codes open tasks up to automation. The robots for working with tasks — find by condition, update by ID — are gathered in the Roboteka catalog. If the robot you need isn't there, describe the task and we'll build it for free and add it to the shared library.