Development of a 1C-Bitrix Personal Account Module

Bitrix has a ready-made component system.auth.registration and personal account pages in the standard delivery, but they are only sufficient for the simplest case: changing the name and viewing orders. As soon as the task arises to “show bonus points, accrual history, linked loyalty cards, several delivery addresses with a map, and B2B contract documents” — the standard cabinet becomes a starting point for rework, not a ready-made solution. We develop a personal account module turnkey: we analyze business processes, design the architecture, and implement all sections from scratch. Our experience is 5+ years and 50+ projects on Bitrix, so we guarantee stable operation even under high load. Economy of scale — up to 40% savings compared to hourly customization of each component separately.

How to Develop a Bitrix Personal Account That Doesn’t Lag?

The default cabinet in Bitrix is a set of scattered components, each independently querying the database without a common data layer. As a result, the profile page can make 15–20 SQL queries on load. A personal account module is built differently: one aggregating service collects user data on login, caches it in the session, and supplies it to all components from a single source. This reduces the number of queries to 2–3 — a 5–10 times speed increase compared to the standard approach.

Architecture: Cabinet Layers

Profile Service (UserProfileService) — central class encapsulating all user data logic:

class UserProfileService { private int $userId; private array $cache = []; public function getOrders(array $filter = [], int $page = 1): OrderCollection { return \Bitrix\Sale\OrderTable::getList([ 'filter' => array_merge(['=USER_ID' => $this->userId], $filter), 'order' => ['DATE_INSERT' => 'DESC'], 'limit' => 10, 'offset' => ($page - 1) * 10, ]); } public function getLoyaltyBalance(): int { if (!isset($this->cache['loyalty'])) { $this->cache['loyalty'] = LoyaltyTable::getBalanceForUser($this->userId); } return $this->cache['loyalty']; } } 

Cabinet components receive the service via the DI container Bitrix\Main\DI\ServiceLocator. Each component is responsible for one section: orders, addresses, notification settings, documents.

Routing. Each section gets its own URL (/cabinet/orders/, /cabinet/addresses/, /cabinet/documents/). Implemented via a custom handler in urlrewrite.php or through the main module with rule registration via UrlRewriter::setRule.

In Detail: Delivery Address Management

By default, Bitrix stores one address in the user profile. For multiple addresses, a custom table is needed:

CREATE TABLE myvendor_user_address ( id SERIAL PRIMARY KEY, user_id INT NOT NULL, label VARCHAR(100), -- "Home", "Work" city VARCHAR(100), street VARCHAR(200), building VARCHAR(20), apartment VARCHAR(20), lat DECIMAL(10, 7), lng DECIMAL(10, 7), is_default BOOLEAN DEFAULT false, created_at TIMESTAMP DEFAULT NOW() ); 

The lat / lng fields are filled via Yandex Geocoder on address save. During checkout, the user selects an address from the list — data is inserted into b_sale_order_props without manual entry.

B2B Documents Section

B2B users often request invoices, acts, UPD. The module links documents (generated by the print form module) to the user profile via myvendor_user_document table. In the cabinet — filtering by document type, period, status, PDF download button. View permissions are checked through user groups.

Notifications

The user manages notification subscriptions: email, SMS, push. Each channel is a separate record in myvendor_notification_pref. When sending a notification from business logic, the application first checks user preferences, then selects the delivery channel.

Why a Cabinet Module Is More Efficient Than Standard Components?

The standard approach — each component fetches data on its own. The module — a single service with caching. Result: page load speed increases, database load decreases. Moreover, the module is easily extensible with new sections without modifying existing code. Comparison is clear:

Cabinet Security

• All data change operations (email, password, address) require confirmation via code on email/SMS
• CSRF protection via standard Bitrix mechanism (bitrix_sessid)
• Rate limiting on password change attempts via myvendor_rate_limit table
• Phone masking in display (show only last 4 digits)

What Is Included in Turnkey Module Development

We deliver a complete package: architecture documentation, module source code, installation instructions, training for your managers, 30-day bug fix warranty. After delivery, we provide 2 weeks of free support. Contact us to evaluate your project — we will send a rough estimate within 1–2 business days. The budget is determined after requirements audit and often turns out lower than customizing standard components by an in-house developer.

Development Timeline

It is important to fix the list of cabinet sections before development starts — adding a new large section (e.g., loyalty program) in the middle of the project requires revision of the profile service and data schema. Get a consultation — we will help to draft a technical specification and estimate the budget.

For an in-depth study of Bitrix architecture, we recommend the official documentation and the REST API section. It is also useful to understand the principles of REST for API design.

Developing a personal account module is a systematic job requiring experience with infoblocks, HL-blocks, and business processes. Entrust it to a team with 1C-Bitrix certifications.