Universal lists are tabular registries inside Bitrix24: expense requests, counterparty directories, registers of contracts and access grants. Their key property is that full-fledged business processes from the designer run on list items: launch on item creation, on change, or manually. Let's look at which data a list is the right choice for, how a typical "expense request" process is structured, what to do with JSON from external systems, and when it's better to set up a smart process instead of a list.

What are universal lists and what are they good for?

A list is a table with configurable fields: text, number, date, a link to an employee, a file, a dropdown. Each item is a row in the registry. The strength of lists is data that doesn't need a sales funnel: internal requests (expenses, leave, system access), directories (rate plans, branches, standard items), logs (contracts, powers of attorney, incidents). Lists live separately from CRM, with their own access permissions: who sees the registry, who adds items, who edits others' items. A practical selection criterion: if data needs to be "maintained and approved", a list fits; if cards need to be "moved through stages", look toward smart processes — more on that boundary below.

How do you enable business processes on a list?

Business process support is enabled in the list settings — after that the list gets its own set of templates in the business process designer. A template is bound to an event: auto-launch on item creation, auto-launch on change, or a manual launch from the item. The item's fields are available to the template as document fields — they can be read in conditions, inserted into notifications, and overwritten by the document-change action. A typical pairing for a request registry: auto-launch on creation — the process checks the data, assigns an approver, and changes the item's status field based on the result. For how the designer, variables, and conditions work in general, see the business process overview.

How is a typical process structured: the expense request?

An employee adds an item: amount, expense line, comment. The process starts automatically and the first thing it decides is which route to take. The stock "Condition" compares a single value, and at just two or three criteria the template turns into a ladder of nested branches. The Compound condition (AND / OR / NOT) robot assembles the check into one step: up to four "value — operator — value" pairs with AND or OR logic, and for branching regulations, a JSON mode with arbitrary nesting of and, or, and not groups. It returns a single Y/N flag: amount within the limit AND a standard expense line — the department head approves; otherwise — the CFO. The process writes the step's result into the item's status field, and the registry stays honest.

How do you parse JSON that lands in a list?

Lists often serve as a buffer for external systems: a request arrives from the website, a status comes from the accounting system, and an entire JSON ends up in an item's text field. There's no need to drag the "raw" string from step to step — the Extract a value from JSON by path robot parses the JSON string and returns a value by a dot-separated path: for example, data.user.email or items.0.name. Strings are returned as is, objects and arrays as JSON for further parsing, plus a "Path found" flag (Y/N) — by which the process diverts broken data into a separate branch instead of silently continuing with nothing. For how to deliver JSON into Bitrix24 from the outside in the first place, see the article on webhooks.

When is a smart process better than a list?

A list is a table: it has no Kanban, no stages, and no robots on stages — automation lives only in the designer's templates. While a request fits the "added — approved — closed" logic, that's enough. The signs that a registry has outgrown a list: the team needs a Kanban by stages, you want robots and triggers like in a funnel, and items are ready to be linked to deals, contacts, and companies. Then set up a smart process — a full-fledged CRM entity with stages, robots, and links; for a detailed comparison see the smart process breakdown. A working rule: directories and logs — a list; a flow of similar cards that people move through stages — a smart process.

In summary

Lists cover registries: requests, directories, logs — with access permissions and business processes on the items. A request's route is assembled in the business process designer: forks by amount and expense line — the "Compound condition" robot; data from external systems — "Extract a value from JSON by path". When a registry comes to need stages and a Kanban — move to a smart process, and the logic templates carry over with the same bricks. Robots for both cases are in the Roboteka catalog, and installation from the Bitrix24.Market is free. If the action you need is missing — describe the task and we'll build the robot for free.