Custom Bitrix24 Section Development

Standard Bitrix24 capabilities don't always cover specific business processes. For example, a procurement department may require a multi-stage approval section, integration with 1C UT, and a custom Vue.js interface. In such cases, we develop an SPA application embedded into the portal's left menu. O

Our competencies:

Frequently Asked Questions

Standard Bitrix24 capabilities don't always cover specific business processes. For example, a procurement department may require a multi-stage approval section, integration with 1C UT, and a custom Vue.js interface. In such cases, we develop an SPA application embedded into the portal's left menu. Over 10+ years, we have implemented dozens of similar projects. Contact us to evaluate your project and we'll propose a solution. The budget is determined after analyzing your specific requirements.

How a Custom Bitrix24 Section Works

A custom section is an application embedded into the portal's left menu via the placement mechanism. Technically, it is an SPA loaded within an iframe inside the B24 interface. Registration is done using the REST API method placement.bind with type LEFT_MENU. More about placement can be found in the official documentation.

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

Full list of authorization parameters

In addition to AUTH_ID and REFRESH_ID, the iframe receives member_id, portal_id, app_id. See the documentation for the complete list.

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

Step-by-Step Registration of a Custom Section

  1. Create an application in MarketMy Applications, type: server.
  2. Specify the path to your SPA in the "File path" field.
  3. Register the placement using the placement.bind method with type LEFT_MENU and pass the URL.
  4. Install the application on the portal.

When to Store Data in Smart Processes

Smart processes (\Bitrix\Crm\Service\Factory) are a constructor for CRM entities. Create a type via CRM → Settings → Automation → Smart Processes, add custom fields, configure a funnel. Data is stored in b_crm_dynamic_items_* tables.

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

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

The advantage: you get funnels, robots, business processes, access rights, and change history for free. The limitation: REST API returns a maximum of 50 items per request; for large lists, pagination is needed. For 10,000+ records, the interface must implement server-side filtering.

When an External DB Is More Advantageous

If the data is more complex than a flat list — many-to-many relationships, hierarchies, specific indexes — it is easier to store in an external PostgreSQL or MySQL. The custom section communicates with your backend via API, while interacting with Bitrix24 only for authorization and obtaining user context.

Scheme: iframe loads SPA → SPA verifies 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 by yourself.

Criteria Smart Processes External DB
Data complexity Flat lists, up to 5 relations Any relations, hierarchies
Performance Up to 10,000 entries without optimization No limits
Built-in robots/BP Yes No
Access rights From CRM Own implementation needed
Development time Faster (1-2 weeks) Longer (2-4 weeks)

Built-in smart process mechanisms allow implementing a section 2-3 times faster compared to an external DB, if the business logic fits the CRM model. However, for complex scenarios, an external DB offers flexibility and scalability.

Integration with B24 Interface

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

Key integration points:

  • Slider — open an item card in the 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 alert users about events in the section

Access Rights

If data is in smart processes, rights are inherited from CRM (role settings for the CRM entity). For an external DB, implement verification via the REST user.current method + mapping B24 roles to your application's roles.

For checking department membership: department.get returns the structure, user.get with filter by UF_DEPARTMENT gives users of the unit.

What's Included in the Work

Our certified specialists develop custom sections turnkey and ensure stable operation after launch. The project includes:

  • Architectural documentation and development plan approval
  • Access to a repository and staging server
  • Access rights setup and integration with robots/BP (if smart processes are used)
  • Training for portal administrators on using the section
  • Warranty support for 30 days after delivery

Submit a request, and we will evaluate the complexity and propose timelines. With over 10 years of experience and dozens of completed projects, we guarantee results. Significant cost savings compared to buying a ready-made CRM solution.

Timeline Estimation

Component Estimate
Application skeleton + registration in B24 1–2 days
CRUD list interface (table, filters) 3–5 days
Element card with slider 2–3 days
Access rights (external DB) 2–3 days
Integration with robots/BP (smart process) 1–2 days
Testing and deployment 2–3 days

For a medium-complexity section: 1.5–2.5 weeks. The main variable is the complexity of the business logic within the section, not the integration with Bitrix24 itself.

Points to Consider

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

The AUTH_ID token lives for 1 hour. For long sessions, implement auto-refresh via REFRESH_ID — otherwise, users will get an authorization error. To avoid typical development pitfalls, contact our engineers. We guarantee stable operation and provide 30-day warranty support.