The "Address" field in Bitrix24 is set up in an unusual way: for companies and contacts addresses are tied to requisites, while in a deal or smart process an address is added as a custom field. This article covers where to look for addresses, how to pull them in a business process as a single string or in parts, and how geocoding turns a free-form address string into coordinates, a postcode, a city and a time zone — the basis for logistics and regional reports.

Where does Bitrix24 store addresses?

The key quirk: for a company or contact, the address isn't an ordinary card field but part of the requisites. There can be several addresses, by type — actual, legal and others; a company can also have several requisites, for different legal entities for instance, and each has its own set of addresses. So the address isn't always visible where people look for it, and in a business process it can't be pulled like a plain card field. A deal has no built-in address field at all — there you add a custom field of the "Address" type or a plain string. Hence the two typical automation questions covered below: how to pull an address out of a company's or contact's requisites, and how to bring addresses that reps entered free-form into a single form.

How do I add an "Address" field to a deal or smart process?

Create a custom field of the "Address" type — it appears in the card and gets a code like UF_CRM_ followed by a number; the code is visible in the CRM field settings and you'll need it when configuring robots and the API. The alternative is a string field: simpler, but without the address-specific behavior. It's important to understand the limitation of both options: the address is stored as a single piece of text, and for a "all deals in Novosibirsk" filter or routing requests by region that isn't enough — you'll need separate "City", "Region" and "Postcode" fields, filled in automatically from the address (more on that in the geocoding section). How field types work and why it's worth splitting data into separate fields is covered in the article on fields in Bitrix24.

How do I get a company's or contact's address in a business process?

Pulling an address out of the requisites by hand, through a chain of linked entities, is tedious. The Get company/contact address robot does it in a single action: it takes the entity type (company or contact), its ID and the address type — actual (the default) or legal. It returns the full address as a single string and, separately, the city, street, postcode, region and country, plus an "address found" flag of Y/N. The full string goes into a notification to a courier or into a document template, and the parts go into deal fields for filters and reports. If the address isn't found (N), the process assigns the rep a task to request it from the customer — before logistics needs it.

How do I turn an address into coordinates — geocoding?

The Geocode address robot takes an address in any form — even "msk tverskaya 1" — and, through the DaData standardization service, returns latitude and longitude, the normalized address in canonical form, the postcode, region, city, time zone, and a precision rating: from "exact coordinates" to "coordinates not determined". The "found" flag is Y only when coordinates were actually obtained — and that's what a branch for handling unrecognized addresses hangs off. The coordinates are used to compute the distance to a warehouse and to distribute requests across delivery zones, and the time zone is used to schedule calls within the customer's working hours rather than by office time.

How do I tidy up addresses for reports?

Reps write the same city in different ways: "SPb", "Piter", "St. Petersburg" — three different values to a filter. The solution is normalization on input: when a deal is created or changed, the business process runs the address through geocoding and writes back the canonical string, with the city and region going into separate fields. After that the usual tools work: a filter by city, a report by region, segmenting the database for mailouts. Triggering the check at the right stages is set up like any robot in the workflow designer — details in the article on configuring robots. Normalization set up once saves you from cleaning the database by hand before every report.

Conclusion

Company and contact addresses live in the requisites; deal addresses live in custom fields. Robots pull an address as a single string or in parts and turn it into coordinates, a postcode, a city and a time zone — data for logistics, reports and segmentation. Both robots are in the Roboteka catalog; if your task needs an action that isn't there, describe it and we'll build the robot for free.