Bitrix24 (Alaio) CRM is not a list of cards but a network of relations: a deal references a contact and a company, a task references a CRM entity, repeat sales trace back to the same customer. As long as relations are filled in by hand, the network tears: deals with no contact, tasks with no binding, customer data drifting apart between cards. Let's look at how relations work out of the box — and how to read, write and use them in workflows.
How relations work: contact, company, deal
The basic schema: a deal can have several contacts but one company; a contact can belong to several companies; a company and a contact can have any number of deals. The relation is two-way: link a contact to a deal, and the deal appears in the contact's card on the Deals tab. The entire customer history rests on this network: a company's timeline aggregates the events of its deals, and a repeat sale is simply a new deal on an existing contact. The hygiene rule: a deal without a contact or company is an orphan — no customer filter will find it, and neither will a deal duplicates check.
Can you link a deal to another deal?
There is no direct built-in "deal to deal" relation: two deals only sit next to each other through a shared contact or company. When you need an explicit link — an upsell to a master contract, a complaint about an old shipment — add a custom field of the "Link to CRM entities" type on the deal: it lets you pick a specific deal, and the card shows a clickable link. Automation can fill such a field too: the Find deal by condition robot searches for a deal by filter — for example, the latest won deal of the same company — and returns its ID, which the next step writes into the link field. That way a "repeat" deal finds its parent on its own.
Task and CRM: how to bind a task to a deal
A task has a CRM items field — a bound task shows up in the deal's card, and the time spent on it flows into customer reports. The problem is that the field is filled in manually, and half the tasks end up with no binding. In workflows this is covered by two robots: Current task CRM binding — for processes launched on the task itself (binds it to a contact, company, deal or lead), and Task CRM binding (by ID) — from any context, by task ID. The Replace mode removes the previous bindings of the same type and sets the new one — useful when a task has moved to another deal. For which task fields the robots touch and how to read them in processes, see the article on task fields.
Relations in workflows: reading and writing fields of neighboring cards
The stock workflow designer only sees the fields of "its own" document: a process on a deal can't read a company field or write a value into a contact. A pair of robots closes the gap. Get field value from a related entity reads any field of a deal, contact, company or lead by ID — a process on a deal takes the company ID from its own field and pulls out, say, the segment or the payment terms. Set field value on a related entity does the reverse: a process on a deal sets the "Customer" flag on the contact after the first payment. For both operations, look up field codes using the rules from the guide to field IDs. Together these two robots turn isolated cards into a continuous data flow: a change in one entity is propagated by the process to everything related.
Handing over a customer: changing the responsible person across relations
A rep leaves, or a customer is transferred to another department — changing the responsible person on the company isn't enough: its deals and contacts stay with the previous employee. The Change responsible on related robot runs on a company, contact or deal and changes the responsible person on the entities related to it: all the company's deals, its contacts — your choice. One "Hand over customer" process on the company card covers the transfer end to end; to hand over a departed employee's entire portfolio, run the process with a bulk launch over the list of their companies.
Frequently asked questions
How many contacts can be linked to a deal? There's no limit; the first in the list is considered primary — it's their phone number that templates and "deal contact" robots pick up. Do relations survive lead conversion? Yes: the contact, company and deal created from a lead are linked to each other automatically, and the lead stays in the archive with links to them. How do I find all deals of an account in a process? The Find deal by condition robot with a filter by company ID returns the list of matching deal IDs and their count — then a condition or a loop is built over the list.
Conclusion
Relations are the skeleton of your CRM: a contact and a company on every deal, a binding on every task, explicit link fields wherever deals depend on each other. Reading and writing data across relations isn't possible in stock workflows — that's covered by robots from the Roboteka catalog, free to install from Bitrix24 Market. If the scenario you need isn't there, describe the task and we'll build the robot for free.