Development of custom Bitrix24 sections

Development of Custom Sections in Bitrix24

Standard Bitrix24 sections — CRM, Tasks, Disk — cover typical scenarios. But when a business needs a section like "Purchase Requests" with custom approval logic, role-based routing, and a custom UI — the built-in tools fall short. Universal lists and smart-processes solve part of the problem, but run up against interface limitations. This is where custom section development begins.

Architecture of a Custom Section

A custom section in Bitrix24 is an application embedded in the left menu of the portal through the placement mechanism. Technically it's an SPA loaded in an iframe within the B24 interface. Registration occurs through the REST API method placement.bind with type LEFT_MENU.

The entry point is a file served by your server (or serverless function). Bitrix24 loads it in an iframe, passing authorization parameters: AUTH_ID, REFRESH_ID, member_id. Through these parameters, the application gains access to the portal's REST API.

BX24.init(function() {
    BX24.callMethod('user.current', {}, function(result) {
        // Current user for permission checks
    });
});

Key decision at the start: where to store section data — in Bitrix24 entities (smart-processes, lists) or in an external database. Everything else depends on this.

Option 1: Data in Smart-Processes

Smart-processes (\Bitrix\Crm\Service\Factory) — a CRM entity constructor. You create a type via CRM → Settings → Automation → Smart-Processes, add custom fields, configure the pipeline. Data is stored in tables b_crm_dynamic_items_*.

A custom section in this case is an alternative UI for working with smart-process data. Instead of the standard card and kanban, you draw your own interface and read/write data through REST:

• crm.item.list — retrieve list of items
• crm.item.add / crm.item.update — create and update
• crm.item.fields — field metadata

Advantage: you get pipelines, robots, business processes, access rights, and change history for free. Limitation: REST API returns a maximum of 50 items per request; for large lists you need pagination. For 10,000+ records, the interface should implement server-side filtering.

Option 2: External Database

When data is more complex than a flat list with fields — many-to-many relationships, hierarchies, specific indexes — it's simpler to store in an external PostgreSQL or MySQL. The custom section calls your backend API and interacts with Bitrix24 only for authorization and user context.

Schema: iframe loads SPA → SPA checks AUTH_ID via oauth.bitrix.info/rest/ → gets user_id → requests data from your backend by user_id.

Advantage: no REST API limits, full control over data structure. Limitation: you lose built-in robots and business processes; access rights must be implemented manually.

Integration with B24 Interface

For a native feel, the custom section should use Bitrix24's design system. Official UI kit: @bitrix24/b24-ui. It contains components visually identical to standard portal elements — buttons, tables, filters, sliders.

Key integration points:

• Slider — open item card in side panel via BX24.openApplication({bx24_width: 800})
• Menu counters — update badge via BX24.appOption.set('bx24_leftMenuCounter', count)
• Notifications — send via im.notify.system.add to notify users of section events

Access Rights

If data is in smart-processes — rights are inherited from CRM (roles in CRM entity permission settings). For an external database, implement checks via REST method user.current + map B24 roles to your application roles.

To check department membership: department.get returns structure, user.get with filter by UF_DEPARTMENT — users in the department.

Effort Estimation

Total for medium complexity section: 1.5–2.5 weeks. The main variable is the complexity of business logic within the section, not the Bitrix24 integration itself.

Points to Watch

Iframe applications operate in an isolated context. localStorage inside the iframe is tied to your server's domain, not the portal's domain. If you have multiple portal clients — store member_id in the storage key to avoid mixing data.

The AUTH_ID token lives for 1 hour. For long sessions, implement auto-refresh via REFRESH_ID — otherwise the user will get an authorization error after an hour of working in the section without page reload.