Setting up Personal Data Processing Consent for 1C-Bitrix
A consent form for personal data processing is not just a checkbox. Consent must be documented, tied to a specific user and form, and if necessary — revoked. Bitrix provides the UserConsent module for this, which appeared in the D7 kernel.
Built-in UserConsent mechanism
Starting from D7 kernel version, Bitrix includes the class \Bitrix\Main\UserConsent\Consent and related tables. Main ones:
-
b_user_consent— consent records -
b_user_consent_text— consent texts with versioning
Consent is created through the add() or addByContext() method:
$result = \Bitrix\Main\UserConsent\Consent::addByContext(
'feedback_form', // Context ID (form name)
[
'USER_ID' => $userId, // or 0 for anonymous
'USER_IP' => $_SERVER['REMOTE_ADDR'],
],
[
'AGREEMENT_ID' => 1, // ID of agreement text from b_user_consent_text
'URL' => \Bitrix\Main\Application::getInstance()->getContext()->getRequest()->getRequestUri(),
]
);
The AGREEMENT_ID field references a specific version of the agreement text. This is important: if you update your privacy policy text, old consents remain tied to the old text — you can prove exactly which text the user consented to.
Setting up agreement texts through admin
Agreement texts are managed in /bitrix/admin/ through the main module. Each text has an ID, name and versioned content. When updating privacy policy, a new version is created — old consents are not invalidated, new users get the current text.
For each form on the site, a separate "context" (identifier string) is created: registration, checkout, callback_form, newsletter. This allows tracking which entry point obtained the consent.
Integration with forms and web forms
Registration form. Component bitrix:main.register supports built-in consent checkbox output — parameter USE_AGREEMENT = Y in component settings. The agreement text ID is passed through AGREEMENT_ID parameter. Data is recorded automatically upon successful registration.
Web forms module (form). For feedback forms — add a field of type AGREEMENT in the form builder (/bitrix/admin/form_edit.php). When the form is submitted, Bitrix automatically records consent in b_user_consent with attachment to form result (b_form_result).
Custom forms. When self-processing POST data (AJAX form on Fetch API), call Consent::add() in PHP handler before saving form data. Without this, consent is not recorded anywhere, even if there's a checkbox on the page.
Consent revocation
The user must have the ability to revoke consent. In the personal account (/personal/) add a page for managing consents. List of specific user's consents:
$consents = \Bitrix\Main\UserConsent\ConsentTable::getList([
'filter' => ['USER_ID' => $USER->GetID()],
'order' => ['DATE_CREATE' => 'DESC']
]);
Revocation is not deleting a record, but creating a new one with IS_ACCEPTED = N. History is preserved: user gave consent 01.01.2024, revoked 15.03.2024. This is legally important.
After consent revocation, you need to determine what to do with already accumulated data. Automatic deletion doesn't happen — this is an organizational process with technical support.
Checking consent before processing data
At critical points (before sending email newsletter, before transferring data to CRM) verify current consent exists:
$hasConsent = \Bitrix\Main\UserConsent\Consent::isAccepted(
'newsletter',
['USER_ID' => $userId]
);
if (!$hasConsent) {
// don't process data
}
This protects against situations where user revoked consent, but the system continues sending emails due to accumulated queue in b_subscribe_subscription table.