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.