The "Address" field in Bitrix24 (Alaio) 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?
Geocoding — turning an address into coordinates — is done by an external map service, not by the CRM: you send it an address string and it answers with latitude and longitude, the address in canonical form, and a precision rating from "exact coordinates" to "not determined". The workflow's job is to supply a clean string and to store what comes back, and that first half is where the Get company/contact address robot fits: it hands the geocoder the address actually recorded on the company or contact, as one line and in parts, instead of whatever a rep once typed into a comment. Note that the robot returns the stored address only — it does not compute coordinates itself. The coordinates that come back from the service are written into deal fields and used to compute the distance to a warehouse and to distribute requests across delivery zones, and the time zone the service reports 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: "NYC", "New York", "New York City" — three different values to a filter. The solution is normalization on input: when a deal is created or changed, the business process pulls the address with the Get company/contact address robot and writes the parts — city, region, postcode — into their own fields instead of leaving one free-form line for the filter to choke on. 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. A robot pulls an address as a single string or in parts — city, street, postcode, region, country — ready for logistics, reports and segmentation, and ready to hand to a geocoder when you need coordinates on top. It's in the Roboteka catalog; if your task needs an action that isn't there, describe it and we'll build the robot for free.