1C-Bitrix Project Documentation: Infoblocks, DB, Integrations
You receive a 1C-Bitrix project with hundreds of infoblocks, dozens of integrations, and custom components — and not a single document. The first day goes into reverse engineering: ID 17 is the product catalog, ID 23 is stock balances. Without documentation, any change risks downtime. We document the project turnkey: from audit to auto-generation of schemas. 10 years of experience in Bitrix development, guarantee of relevance. The result is a complete project map ready for handover. We reduce adaptation time from weeks to days, cutting support costs by 50%.
Why Documentation is Not a Luxury but a Necessity
In projects without documentation, every update is a lottery. Infoblocks are renamed without recalculating bindings, integrations break due to token changes, new developers spend weeks studying code. Documentation pays for itself in 2–3 months by accelerating typical tasks: fixing a template takes 15 minutes instead of an hour, and finding an error takes a day instead of an hour.
How to Document Infoblocks
Infoblocks are the heart of the project. Documentation begins with automatic extraction of metadata. A script based on ORM collects IDs, codes, properties and generates Markdown files. Example:
// Script for generating infoblock documentation $iblocks = \Bitrix\Iblock\IblockTable::getList([ 'select' => ['ID', 'NAME', 'CODE', 'IBLOCK_TYPE_ID', 'DESCRIPTION'], 'order' => ['IBLOCK_TYPE_ID' => 'ASC', 'NAME' => 'ASC'], ])->fetchAll(); foreach ($iblocks as $iblock) { $props = \Bitrix\Iblock\PropertyTable::getList([ 'filter' => ['IBLOCK_ID' => $iblock['ID']], 'select' => ['ID', 'NAME', 'CODE', 'PROPERTY_TYPE', 'USER_TYPE', 'LINK_IBLOCK_ID'], 'order' => ['SORT' => 'ASC'], ])->fetchAll(); // Generate Markdown page for the infoblock echo "## {$iblock['NAME']} (ID: {$iblock['ID']}, CODE: {$iblock['CODE']})\n"; // ... } Result: property tables in a git repository, updated on deployment. Example documentation for an infoblock:
| Code | Name | Type | Notes |
|---|---|---|---|
| VENDOR_CODE | Article | S (string) | Required, unique |
| BRAND | Brand | E (link) | → Infoblock ID 8 (Brands) |
| WEIGHT | Weight (g) | N (number) | For delivery calculation |
| IMAGES | Additional photos | F (file) | Multiple |
For catalogs of 10,000+ items, we add indexes on IBLOCK_ELEMENT.IBLOCK_ID and IBLOCK_ELEMENT_PROPERTY.VALUE — without documentation such optimization is easy to miss.
What's Included in Integration Documentation
Integrations are points of failure. The integration map includes:
- Bitrix24 CRM ↔ Site: REST API + webhooks, bidirectional, leads from forms → B24, order statuses B24 → site. Tokens in
/bitrix/.settings_extra.php, variableB24_WEBHOOK_URL. Update every 15 minutes (agent\Integration\B24Agent::sync()). Logs:/local/logs/b24_integration.log. - 1C:Enterprise ↔ Site: CommerceML 2.0, products and stock from 1C, orders to 1C. Schedule — every 2 hours. For more than 10,000 items, exchange takes over 30 minutes — configured split by files.
For each integration, we specify type, direction, token location, schedule, and logs. More details in the Bitrix documentation.
Documenting Custom Database
For custom tables: ERD diagram and text description. Example:
| Field | Type | Description |
|---|---|---|
| ID | INT AUTO_INCREMENT | PK |
| SPECIALIST_ID | INT | FK → b_user.ID |
| SERVICE_ID | INT | FK → b_iblock_element.ID (IB 12) |
| DATE_FROM | DATETIME | Slot start |
| DATE_TO | DATETIME | Slot end |
| STATUS | ENUM('free','booked','blocked') | Current status |
| BOOKING_ID | INT NULL | FK → bookings.ID when STATUS=booked |
Indexes: (SPECIALIST_ID, DATE_FROM), (STATUS). Created by module local.booking in install/db/mysql/install.sql.
How to Document Components
For custom components: component.php file with parameter description and a separate Markdown with examples:
<?$APPLICATION->IncludeComponent('local:catalog.filter.extended', '', [ 'IBLOCK_ID' => 5, 'PRICE_TYPES' => [1, 2], 'USE_RANGE' => true, ]);?> Component parameters:
| Parameter | Type | Default | Description |
|---|---|---|---|
| IBLOCK_ID | int | — | Catalog infoblock ID (required) |
| PRICE_TYPES | array | [1] | Price type IDs for filter |
| USE_RANGE | bool | true | Enable price range filter |
| AJAX_MODE | bool | true | Update without page reload |
Known limitations: does not work with SKU.
How We Document a Project in 5 Steps
- Audit — inventory of infoblocks, tables, modules, integrations. Identify undocumented areas.
- Auto-generation of schemas — scripts extract structure from the database and generate Markdown.
- Writing documents — describe infoblocks, integrations, components, database. Add examples and limitations.
- Diagrams — ERD and interaction diagrams in PlantUML or Mermaid.
- Process setup — update rules, PR templates, auto-generation on deployment.
Keeping Documentation Up to Date
Documentation without an update process becomes stale. Rules:
- Changing an infoblock → update the infoblock file in the same PR.
- Adding a table → description in
/docs/database/. - New integration → update the map.
- Deployment → run schema auto-generation.
Work Stages and Timelines
| Stage | Content | Duration |
|---|---|---|
| Project audit | Inventory of infoblocks, tables, modules | 2–3 days |
| Schema auto-generation | Scripts to extract structure from DB | 1–2 days |
| Writing key documents | Infoblocks, integrations, components | 3–7 days |
| Diagrams | ERD, integration schemas | 2–3 days |
| Process setup | Update rules, templates | 1 day |
Total: 2–4 weeks for a medium-sized project. Get a consultation — contact us, and we will prepare an individual plan. Time savings on support will pay for documentation in 2–3 months. Leave a request on the website — we will assess your project.

