Build an Industry-Specific Solution on Bitrix24
Standard Bitrix24 configurations cover 60–70% of tasks for a universal business. The remaining 30–40% is industry-specific—custom entities (real estate property, insurance policy, medical case), non-standard pipelines, deep integrations with industry systems, and specialized calculations and automations. In our practice, every second Bitrix24 implementation project requires custom development beyond typical CRM functionality. An industry-specific solution is an add-on over standard Bitrix24, implemented through a combination of the platform's low-code tools, custom REST applications, and server-side logic. Developing such a solution is fundamentally different from routine setup: this is where real engineering begins. We use an Agile approach with two-week sprints to quickly adapt to changing business requirements. We design each solution with long-term evolution in mind and guarantee support at all stages.
How to Choose Between Extension and Integration?
The first decision in an industry solution project is determining what goes into Bitrix24 and what stays in external systems. Both extremes are equally bad:
- Everything in Bitrix24 — creating a monolith where the platform is overloaded with functions it wasn't designed for. Financial accounting, warehouse logistics, production planning—these are not CRM tasks.
- Bitrix24 as a thin client — then why pay for a license? The whole point of a unified work environment is lost.
The optimal boundary: Bitrix24 handles customer communications, deal and task management, and visualization of data from external systems. Industry systems (1C, HIS, ERP, WMS) handle the domain logic. This approach ensures flexibility and lowers maintenance costs.
Which Bitrix24 Tools to Use?
Smart Processes (SPA)
The foundation for custom entities in Enterprise and higher plans. They allow creating "Construction Object", "Insurance Policy", "Medical Case" with custom fields, pipelines, access rights, and robots. With REST API 22.x, smart processes have become a full-fledged replacement for custom modules. According to our estimates, developing on SPA is 3 times faster than building a custom module on D7 core.
// Creating a smart process item via REST
CRest::call('crm.item.add', [
'entityTypeId' => 138, // Your SPA ID
'fields' => [
'title' => 'Object: Northern Residential Complex',
'ufCrm138_1234' => 'Residential complex', // custom field
'ufCrm138_5678' => '2025-12-31', // planned deadline
'assignedById' => 42,
],
]);
More about smart processes
Smart processes are a low-code platform for creating custom entities. They support robots, business processes, access rights, and REST API. Ideal for industry-specific objects: real estate property, insurance policy, medical case. Not suitable for complex database-level logic or unique calculation algorithms.
REST Application on Marketplace
For solutions intended for replication. Application registration, OAuth 2.0, webhooks on CRM events. This path is more complex but allows selling the solution to other clients.
Embedded Pages (Embeddable Apps)
Iframe insertions of custom UI into CRM cards. Implemented via placement.bind and allow displaying data from external systems in the side panel of deal cards: order status from 1C, support ticket history from a ticket system, technical specifications from an ERP.
When Are Smart Processes Not Suitable?
If unique database-level logic or complex calculations are required, a custom module is better. But for 80% of industry tasks, SPA is sufficient. Maintenance savings can reach 50%.
Case Study: Industry Solution for a Real Estate Agency
Our client is an agency with 50 agents, working in primary and secondary markets with developer partner programs.
The problem with standard Bitrix24: no "Property" entity with characteristics (type, area, floor, cost per m², sale status), no property-to-multiple-deals relationship (from different agents), and no agent commission calculation.
Solution architecture:
Smart Process "Property"
├── Fields: type, area, floor, cost, status (available/reserve/sold)
├── Relation: Developer (Company in CRM)
└── Relation: Deals (Standard entity)
Smart Process "Commission"
├── Relation: Deal
├── Fields: percentage, amount, payment status
└── Robot: auto-calculate when deal moves to "Won"
REST Application "Property Catalog"
├── Embedded page in contact card
├── Shows available properties matching client criteria
└── Button "Reserve" → creates a Deal + updates Property status
Implementation in 6 Weeks
| Week |
Work |
| 1–2 |
Analysis, entity design, approval |
| 3 |
Configure SPA, fields, relations |
| 4 |
Develop REST application (catalog + reservation logic) |
| 5 |
Integrate with the website (parse developer properties) |
| 6 |
Testing, training, launch |
Result: time from client request to property selection reduced from 2 hours to 15 minutes. Time savings of 87%, and successful deals increased by 40% in the first quarter.
Integration with Industry Systems
For most industries, bidirectional synchronization with accounting systems is critical. Common patterns:
- 1C → Bitrix24 (data from accounting to CRM): invoice payment statuses, warehouse balances, shipment data. Implemented via 1C connector or through REST API with a cron agent in 1C.
- Bitrix24 → 1C (deals into orders): on deal win, automatically create an order in 1C. Trigger via webhook ONCRMDEALSTAGEIDCHANGE, transfer through COM object or 1C REST.
- External APIs: for insurance — AIS OSAGO/KASKO insurers, for healthcare — HIS via FHIR protocol, for logistics — transport company APIs (CDEK, PEC).
Comparison: Custom Module vs Smart Process
| Criterion |
Custom Module |
Smart Process |
| Development speed |
3–4 weeks |
1–2 weeks |
| Flexibility |
High |
Medium (SPA limitations) |
| Platform updates |
Require adaptation |
Automatically compatible |
| Maintenance cost |
High |
Low |
For most industry tasks, smart processes are the optimal choice unless unique database-level logic is needed. Using SPA reduces development costs by 30–50%.
What's Included in Industry Solution Development
We provide a full cycle of work:
- Analytics and design of entities, pipelines, access rights.
- Development of smart processes, REST applications, embedded pages.
- Integration with external systems (1C, ERP, WMS, APIs).
- Architecture and operational documentation.
- Training key users (2–3 days).
- 3-month warranty support after launch.
Version Control and Deployment
An industry solution is code that needs versioning. Mandatory stack:
- Git repository for REST application and server scripts
- Staging environment (separate Bitrix24 portal or test On-Premise instance)
- CI/CD for automated change deployment
Without versioning, after six months no one will remember why a particular field was added to a smart process, and changes will start breaking each other.
An industry solution is a long-term product that lives and evolves with the business. Architect with changes in mind: modularity, documentation, clear boundaries of responsibility between Bitrix24 and external systems.
Get a consultation on your project — we will analyze your industry and propose the optimal solution. Request an audit of your current CRM to identify necessary customizations.
Become a certified 1C-Bitrix partner with 8+ years of experience and 500+ completed industry projects. Guaranteed quality and stable operation even under peak loads. TecDoc API, GIS “Marking”, EGAIS, size charts with RU/EU/US conversion — a standard catalog.section cannot handle this. Industry projects require non-standard data architecture, specialized integrations, and business logic not available out of the box. We develop such solutions on 1C-Bitrix, and the hardest part is not the code but diving into the client's domain. Over the years we have accumulated a library of ready-made modules for nine industries — this reduces launch timelines by 20–40% compared to custom development. Contact us to receive a turnkey estimate and timeline within 2 business days.
Auto Parts — TecDoc and Cross-References
Auto parts is the most technically complex catalog type. Without TecDoc, there is no point.
VIN-based lookup. The user enters a VIN — the system decodes make, model, year, trim and displays an aggregate tree. Click “Braking system” → “Front brake mechanism” → get a list of parts with part numbers. We implement via TecDoc API (getArticleDirectSearchAllNumbersWithState, getLinkageTargets) — each request returns a JSON with part-car mappings. According to TecDoc documentation, the catalog covers over 60,000 models and 30 million part numbers. The ready-made TecDoc module accelerates launch by 3x compared to custom development and saves significantly on parser and caching systems.
Cross-references. Original part number → OEM, aftermarket, premium equivalents. A cross-number table in a separate infoblock indexed by PROPERTY_CROSS_NUMBER. For a catalog with 500,000+ part numbers, without Sphinx/Elasticsearch, cross-search will slow down beyond 5 seconds.
Interactive aggregate diagrams. SVG map of engine or suspension with clickable zones — click on a part, go to its card. Zone coordinates are stored in infoblock element properties.
Typical challenges: TecDoc API is slow (500–1500ms per request), data is cached locally and updated once a day via cron. Savings on a typical project with TecDoc is significant by eliminating the parser development stage. If you need an auto parts catalog, contact us — we'll show a prototype on your data.
Building Materials — Calculators and Oversized Items
Calculation calculators. This is not just “multiply quantity by price.” Foundation calculator: type (strip, pile, slab) → dimensions → soil → get concrete volume, rebar quantity, waterproofing, formwork, all with a 10–15% margin. Technically: JS calculator on the frontend for instant recalculation, server-side validation via REST endpoint in PHP. Calculation formulas are in a configuration file, not hardcoded. The client updates coefficients through the admin panel themselves. Our ready-made calculators process calculations 10 times faster than custom forms — a typical project with such modules saves significant costs.
Delivery of oversized items. The standard sale.delivery module cannot calculate by tonnage and number of pallets. We write a custom handler: sum item weights from PROPERTY_WEIGHT, divide by vehicle capacity (usually 5 tons), count trips. Separate line for floor lifting (cost depends on weight and floor number, typically 50–200 per pallet).
Nomenclature. Dozens of technical characteristics: dimensions (LxWxH), unit weight, strength class, frost resistance, water absorption. All are filters in smart_filter with product count recalculation. More than 100 characteristics per item is not the limit — we handle it through optimized queries and caching.
Other Industries: Pharmaceuticals, Apparel, HoReCa, Education
Pharmaceuticals — the most regulated industry. Integration with GIS “Marking” via MDLP API: transfer of retail sales data (up to 10,000 requests per day for a network of 50 pharmacies), DataMatrix code verification at shipment. Linking products to the state register of medicines (over 200,000 items), automatic registration certificate check. Separation of prescription and over-the-counter: prescription items cannot be added to cart, only in-pharmacy request. Prohibition of remote sale for certain categories — about 30% of items are excluded from online ordering.
Apparel and footwear: size conversion table RU/EU/US/UK in a highload-block. Filtering by size — by availability, not by entire grid. Return system: claim from personal account, label generation, automatic refund request. Lookbook catalog with clickable points on images.
HoReCa: nutritional value and allergens in product card, shelf-life management with auto-discontinuation, subscription models (weekly farm product set), B2B minimum order quantities for restaurants with separate price type.
Education: course catalog with filters by format, duration, level. Student personal account with schedule and materials. Integration with LMS (Moodle, GetCourse) via API, SSO authorization, progress sync. PDF certificate generation via TCPDF.
Why Do Industry Solutions Require Custom Architecture?
The standard “Section → Subsection → Product” hierarchy does not work for complex domains. For auto parts: “Car → Aggregate → Unit → Part” — four levels linked via highload-blocks. For building materials: “Category → Subcategory” plus matrix classification by purpose (foundation, walls, roofing). Multiple classifiers — OKPD-2 (contains over 40,000 groupings), HS Code, ETIM — are stored in highload-blocks linked to catalog elements. They are needed for B2B clients, tenders, and integration with government procurement.
| Integration |
Industry |
Method |
| TecDoc API |
Auto Parts |
REST/SOAP, local caching |
| GIS “Marking” (MDLP) |
Pharmaceuticals |
MDLP API |
| EGAIS |
Alcohol |
UTM (Universal Transport Module) |
| “Honest SIGN” |
Marked goods |
ChZ API |
| Industry ERP/MES |
Manufacturing |
Custom connectors |
How Do We Accelerate Development with Ready-Made Modules?
Over the years we have built a library of 20+ turnkey components: TecDoc parser with caching, building materials calculator with server-side validation, size grid module, integration with GIS “Marking” and “Honest SIGN”. This cuts timelines by 20–40% (on average 1.5 months) and allows project launch in as little as 2 months. Get a consultation on ready-made modules for your industry — we'll find the optimal solution.
Typical Mistakes in Industry Catalog Development:
- Insufficient data normalization: storing many characteristics in a single string instead of using highload-blocks.
- Ignoring caching of external API requests (TecDoc, MDLP) — leads to page slowdowns.
- Lack of testing with real data: one wrong coefficient in a building materials calculator can result in ordering 20 extra pallets of bricks.
- Weak integration with 1C: data loss during exchange via CommerceML, product duplication.
Development Approach
- Industry audit (3–5 days). Dive into specifics: market structure, unique processes, regulatory requirements. We don't reinvent the wheel — we use learnings from similar projects.
- Data architecture (1–2 weeks). Infoblock structure, highload-blocks, properties, relationships. Mistakes at this stage are costly — redoing the catalog structure for 100,000 items later is painful.
- Prototyping (1 week). Catalog with industry filters, product card with calculator, specialized checkout. Test with real users.
- Development (1–4 months). Often the most labor-intensive stage — catalog data population: mapping from Excel/1C, normalizing characteristics, uploading images. Parser processes up to 6,000 items per hour.
- Testing industry scenarios (1–2 weeks). One wrong coefficient in a building materials calculator — and the client orders 20 extra pallets of bricks. We verify calculations with real data.
What Is Included in the Deliverable
- Documented data structure: infoblock schema, HL-blocks, properties, relationships
- Catalog population guide for content managers
- Training webinar for the team (up to 2 hours)
- 30 days of free support after launch
- Source code of modules in repository (Git)
- Admin panel access and technical documentation
Timelines and Complexity
| Level |
Timelines |
Examples |
| Basic industry |
2–3 months |
Building materials catalog with calculator |
| Intermediate |
3–5 months |
Auto parts with TecDoc, marked goods |
| Complex |
5–8 months |
Marketplace with industry specifics, ERP integration |
We will evaluate your project within 2 days — just contact us. Get a turnkey timeline and cost estimate. Закажите консультацию по готовым модулям для вашей отрасли.