A workflow in Bitrix24 (Alaio) always knows the record it runs on — and almost nothing about the records around it. Yet half of real scenarios start with a lookup: does this customer already exist, is there an open deal for them, has a follow-up task been created? The stock designer has no search step, so processes either skip the check and breed duplicates, or route through external scripts. This guide shows how find-robots close the gap: search by any field, get the ID and a found flag, then branch, link and update.
Why search for records from a workflow?
Because the trigger record is rarely the whole story. A new inquiry arrives as a lead, but the person may already be a contact with purchase history. A support request references a company with an open deal your process should attach to rather than duplicate. A stage change should update the follow-up task — if one exists. In each case the workflow needs an answer to "is there a record where field X equals value Y", and the value comes from the current record's own fields.
How does find-by-condition work?
One robot call per lookup. Find contact by phone or email matches people by their most stable identifiers; Find deal by condition and Find lead by condition search by a field-value pair you configure. Each returns two things into workflow variables: the ID of the found record and a Y/N found flag. The flag is what makes the pattern safe — the process branches on it explicitly (condition mechanics here), and for compound gates like "found AND stage is open" there is Compound condition (AND / OR / NOT). One practical prerequisite: search by phone only works when numbers are stored uniformly — do the phone formatting pass first, or equal numbers will look different to the comparison.
What do you do with the found ID?
The ID is a handle for every subsequent step. Update robots — Update deal by ID, Update contact by ID — write fields on the found record, not the current one. Get field value from a related entity and Set field value on a related entity move data between the two. And when nothing was found, the else-branch creates the record with stock tools, so the process converges to "exactly one record, current data" on both paths.
How does search prevent duplicates?
Find-before-create is the cheapest deduplication there is: one lookup at the entry point beats a merge campaign after the fact. The built-in duplicate control catches some cases at manual entry, but records created by imports, forms and integrations flow past it — a workflow with Find contact by phone or email in front is the net that catches the rest. What to do with the duplicates you already have is a separate craft, covered in the find-and-merge guide.
Does it work for tasks and smart processes?
Yes, the same pattern extends beyond classic CRM. Find task by condition answers "is there already an open follow-up" before the process creates the next one. Find smart process item searches records of custom entities — subscriptions, shipments, assets — which the stock designer treats as invisible from other entities' workflows; what smart processes are and when to use them is in the smart processes guide.
Where to go from here
Wire one lookup into your intake process today: find-contact in front of lead conversion pays back the same week. More lookup-then-act recipes are collected in the automation examples, and the full set of search, update and relation robots lives in the catalog.