Bitrix24 On Premise

Bitrix24 On-Premise

Use the target installation, its module versions, and verified live behavior as the technical source of truth. Use the bundled references as a concise navigation and decision layer over public official documentation.

Establish the evidence gate

1. Resolve the actual portal or repository root. Preserve unrelated changes.
2. Classify the request as advice, read-only diagnosis, implementation,

migration/update, deployment, or production verification.

1. Classify the available access before inspecting anything:

• source-backed box — portal files and repository are available;
• remote administered box — only an authenticated UI and/or REST is

available;

• external integration — a separate website or service sends data to

the portal.

1. For a source-backed box, run the read-only inspector:

``bash python3 scripts/inspect_bitrix24.py /path/to/portal ``

Do not run it against an unrelated website or integration repository. For a remote administered box, collect the same facts from system check, module pages, safe REST discovery, and portal settings when available.

1. Record the main module version, relevant module versions, PHP, database,

server topology, BitrixVM/BitrixEnv status, agent/cron mode, license/update state, backup state, and network restrictions when they affect the task.

1. Inspect git status, deployment metadata, the exact class/method/event,

and available tests before changing files.

1. Recheck the current public official page for volatile requirements. Never

assume that the newest online method exists in an older box.

Do not turn a read-only audit into a modification. Do not update, migrate, deploy, clear caches globally, submit CRM data, or expose a portal publicly without the corresponding user authorization.

Route the task

• Read [official-sources.md](references/official-sources.md) for the canonical

public documentation map, source hierarchy, licensing boundary, and search strategy.

• Read [architecture-and-development.md](references/architecture-and-development.md)

for D7 versus legacy API, local/, modules, components, ORM, events, agents, caching, business processes, and implementation conventions.

• Read [administration-and-operations.md](references/administration-and-operations.md)

for installation, updates, backups, PHP/database work, BitrixVM, cron, performance, clusters, and closed networks.

• Read [rest-and-integrations.md](references/rest-and-integrations.md) for REST

and REST 3.0, scopes, user permissions, webhooks, OAuth, events, batch, local apps, custom methods, network access, and 1C integrations.

• Read [crm-admin-and-site-integrations.md](references/crm-admin-and-site-integrations.md)

for authenticated Codex/browser administration, effective CRM permissions, website lead forms, incoming webhooks, contact-center routing, Open Lines, online-chat widgets, behavioral UAT, cleanup, and operational work logs.

• Read [security-and-release.md](references/security-and-release.md) for

secrets, personal data, threat boundaries, deployment gates, rollbacks, and acceptance evidence.

Search references before loading broad sections:

rg -n "crm\.item|EventManager|agents|PHP|PostgreSQL|closed network" references/

Operate authenticated portals safely

Before reading authenticated business data or changing a remote portal, show the detected portal, account, role, and intended scope and obtain the user's authorization. Inventory existing resources before creating or reusing a webhook, source, robot, CRM form, Open Line, channel, or widget. Reuse only when its owner, site, data contract, permissions, and lifecycle match.

Name every new administrative resource for its site and purpose. Capture its stable ID, pre-change settings, and rollback target. After each save, reload and reread the stored configuration; a successful click is not evidence that the portal persisted the intended state.

For CRM roles, calculate effective access across personal, department, group, inherited, and stage-specific rules. Do not infer a user's capability from one role or from the label of one permission. Verify the target behavior under the target user's effective permissions when authorized, especially stage changes on records owned by another employee.

Choose the correct extension layer

Prefer, in order:

1. product configuration, permissions, automation, or a business process when

no code is required;

1. a documented event, REST integration, local app, webhook, or stable public

extension point;

1. project code in local/modules, local/components, local/templates, or

local/php_interface;

1. a narrowly isolated legacy extension only when the installed version lacks

a suitable D7 or supported extension point.

Do not edit bitrix/modules, standard components, or other product core for a normal customization. If a core patch is unavoidable, isolate the diff, document the missing extension point, pin the affected product version, and provide an update/rebase and rollback procedure.

For new server-side code, start with D7 and namespaces. Use legacy APIs when the installed module or required capability has no equivalent. Confirm class, method, event, parameter, return type, and version in the installed source or the exact official reference page.

Enforce version-aware behavior

• Treat the main module and each feature module as independently versioned.
• Check module availability before calling Loader::includeModule() or a REST

method.

• Treat deprecation markers as migration signals, not proof that the old API

has already disappeared.

• Distinguish REST from REST 3.0 paths, request shapes, responses, and method

coverage.

• Confirm database support against the product edition and current official

requirements before proposing MySQL/PostgreSQL work.

• Treat current PHP, browser, BitrixVM, and licensing requirements as volatile.

Verify them on the day of the change.

Protect data and production

• Never print or commit .settings.php, dbconn.php, webhook URLs, OAuth

tokens, cookies, license keys, SMTP credentials, private keys, database dumps, customer records, or authenticated browser state.

• Keep secrets server-side and outside web root where the installation allows.
• Apply both application scope and acting-user permissions to REST reasoning.
• Validate authentication, authorization, CSRF/session intent, input types,

output encoding, file handling, event authenticity, retry behavior, and idempotency.

• Back up files and database before platform, PHP, database, module, or

Marketplace updates. Prove that restore is possible.

• Test on a representative non-production environment when an update or data

migration can change availability or stored data.

• Prefer targeted cache invalidation. Never hide a defect behind a blind global

cache purge.

Validate proportionally

For code changes, run the narrowest complete matrix available:

1. PHP syntax, static analysis, and existing automated tests.
2. The inspector again, with --strict for a release gate.
3. Module installation/update/uninstall paths when a custom module changes.
4. Authorized, unauthorized, invalid-input, duplicate-event, retry, and

rollback cases for integrations.

1. Agent/cron, cache-disabled/cache-enabled, and concurrent execution behavior

where relevant.

1. Desktop/mobile UI checks for components and portal pages.
2. Backup/restore, maintenance window, health checks, logs, queues, and live

smoke tests for infrastructure work.

1. A clean diff proving that core, secrets, generated caches, uploads, and

unrelated files were not changed accidentally.

For UI-managed integrations, also validate a newly isolated browser/session, the exact saved IDs and settings, one labeled synthetic end-to-end case, and cleanup of only the created test records. State what a single case did not prove, such as a full round-robin queue or absence handling.

Report detected versions, evidence sources, chosen extension point, changed files/settings, checks executed, deployment state, compatibility assumptions, and remaining risks. Distinguish local, GitHub, staging, and public production as separate gates.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: rdsolod-ui
• Source: rdsolod-ui/bitrix24-on-premise-skill
• License: MIT
• Homepage: https://skills.sh/rdsolod-ui/bitrix24-on-premise-skill/bitrix24-on-premise

Install and usage instructions live in the source repository linked above.