Developing a notification system for 1C-Bitrix administrators

Developing an Administrator Notification System for 1C-Bitrix

A Bitrix site administrator must learn about critical events quickly: new order, payment error, completed feedback form, agent failure, disk quota exceeded. Standard Bitrix mail events cover some of these scenarios, but for a full-fledged notification system they're not enough.

Standard Bitrix mail events

Bitrix kernel uses mail event mechanism: event code → email template → recipients. All events registered in b_event table, templates — in b_event_message, history of sent emails (when logging enabled) — in b_event_log.

For e-commerce, critical events already exist: SALE_ORDER_NEW (new order), SALE_ORDER_PAID (payment received), SALE_ORDER_CANCEL (cancellation). Configure recipients in event template through /bitrix/admin/sale_delivery_handler.php or through main module → "Mail events".

Problem with standard mechanism: emails sent synchronously at event moment, slowing server response with slow SMTP. Solution — send queue through b_email_service table or external SMTP with fast connection.

Custom notifications through module events

For non-standard scenarios, hook into module events in init.php. List of useful points:

New form submission — OnAfterAddResult event from form module:

AddEventHandler("form", "OnAfterAddResult", function($formId, $resultId, $arResult) {
    if ($formId == CALLBACK_FORM_ID) {
        notifyAdmin('New request #' . $resultId, formatFormData($arResult));
    }
});

Agent error — agents in b_agent execute without explicit logging. Wrap agent code in try-catch and on exception notify admin:

function MyModuleAgent() {
    try {
        // agent code
    } catch (\Throwable $e) {
        notifyAdmin('Agent error', $e->getMessage() . "\n" . $e->getTraceAsString());
    }
    return __FUNCTION__ . '();';
}

Disk quota exceeded — Bitrix has agent CIBlockAgent::CheckDiskQuota(). Can override or supplement with custom agent checking directory sizes and sending alert when threshold exceeded.

Payment errors — event OnSalePaymentUpdate with status change check to error:

AddEventHandler("sale", "OnSalePaymentUpdate", function($id, &$arFields) {
    if ($arFields['IS_RETURN'] === 'Y' || strpos($arFields['PS_STATUS_MESSAGE'], 'error') !== false) {
        notifyAdmin('Payment error for order', print_r($arFields, true));
    }
});

Multi-channel notification delivery

Email is basic channel, but not always fast enough. For critical alerts add:

Telegram bot. Create bot through BotFather, get BOT_TOKEN and CHAT_ID of admin chat. Send through \Bitrix\Main\Web\HttpClient:

function notifyTelegram(string $message): void {
    $botToken = COption::GetOptionString('local', 'telegram_bot_token');
    $chatId = COption::GetOptionString('local', 'telegram_admin_chat_id');

    $httpClient = new \Bitrix\Main\Web\HttpClient();
    $httpClient->post(
        "https://api.telegram.org/bot{$botToken}/sendMessage",
        ['chat_id' => $chatId, 'text' => $message, 'parse_mode' => 'HTML']
    );
}

Store tokens in b_option through COption, not in code — when rotating token no need to search files.

SMS through API. For truly critical events (payment gateway unavailable, hack attempts) — SMS through SMSC.ru or SMS.ru. Same HttpClient + API key.

Push notifications to browser. For alerts when admin in admin panel — through Bitrix Push Server (push.1c-bitrix.ru) or Web Push API with VAPID keys (see separate implementation).

Notification center in admin panel

Besides external channels, helpful to have internal "notification journal" right in /bitrix/admin/. Implemented as infoblock or custom b_local_notifications table with fields TYPE, MESSAGE, IS_READ, DATE_CREATE.

In admin menu add link to notification list through /bitrix/admin/menu_ext.php. Unread notifications shown as counter in sidebar menu through custom admin widget.

Filtering and priorities

Not all events equally important. Establish priorities:

• Critical → immediately → Telegram + SMS: site down, payment error, hack activity
• Important → within hour → Email: new order, new request, license expiration
• Informational → daily digest → Email: order statistics, new registrations, form activity

Digest implemented through agent: collects events for day from log, forms email and sends at 9:00 next day. Reduces information noise for managers.

Technical health monitoring

Separate notification category — technical site health:

• Site availability — external monitoring (UptimeRobot, Zabbix) more important than internal, because on server down internal agents won't run
• PHP errors — configure logging to file + agent reading error file and sending new critical records to admin
• Task queue size — table b_agent: if records with NEXT_EXEC in past accumulate more than normal, something's wrong

Table b_event_log with enabled logging grows fast. Configure regular cleanup through agent or cron: delete records older 30 days, keeping only critical events.