Creating an Administrator Guide for 1C-Bitrix
An administrator guide for a Bitrix project is not a retelling of the official 1C-Bitrix documentation. It describes the specific installation: which infoblocks exist and what can be edited in them, how the publication chain works, which settings must not be touched and why. Without such a document, each new administrator spends weeks onboarding, and half of the questions are resolved by calling the developer. Our experience shows: a well-written guide reduces onboarding time by 3–5 times and eliminates typical administration errors.
Problems We Solve
The main challenge: the guide becomes outdated with every update. The solution is a process where the developer updates the relevant section of the guide when delivering a task. For storage, use a system with version history—Confluence, Notion, or Google Docs. A Word file on the server is an anti-pattern because versioning is impossible. Do not place the guide in a Git repository: it contains operational information unrelated to code. In practice, cloud systems like Confluence handle freshness much better.
We guarantee the guide remains current thanks to our maintenance checklist. Our team’s certificates and licenses confirm competence in Bitrix.
What the Administrator Sections Should Contain
A typical guide composition:
| Section | Content |
|---|---|
| Access and Environment | Panel addresses, password manager link, description of roles and permission groups |
| Content Management | Infoblocks, fields, screenshots, limitations |
| Catalog Management (e-commerce) | Products, prices, warehouses (catalog), discounts (sale) |
| Orders and Customers | Order statuses, lifecycle |
| Technical Procedures | Backup, kernel update, cache clearing |
Infoblock Description: Template for Each
For each infoblock create a card using the template:
Infoblock: News Type: news | ID: 3 | Symbolic code: news Menu location: Content → News Admin list URL: /bitrix/admin/iblock_list_admin.php?IBLOCK_ID=3&type=news Element fields: - Name (NAME) — required. News title - Symbolic code (CODE) — generated automatically, do not edit - Publication date (ACTIVE_FROM) — if not set, the news is published immediately - Preview text (PREVIEW_TEXT) — short description for the list, up to 300 characters - Preview image (PREVIEW_PICTURE) — 800×600 px, JPG/PNG, max 500 KB - Detail text (DETAIL_TEXT) — TinyMCE editor, full news text - Tags (TAGS) — comma-separated, used for filtering What must not be done: - Change the symbolic code of a published news item (breaks the URL and loses search positions) - Delete sections with active elements without reassigning them This format is understandable for people without a technical background and does not require explanations each time. In practice, administrators often need information about what restrictions exist when editing, to avoid breaking the site with an accidental action.
Description of Technical Procedures
Cache clearing — the most frequent administrator action. In /bitrix/admin/cache.php there are two options: clear all cache or only component cache. Describe what to clear for different situations. If the site uses HTML cache (/bitrix/html_pages/), it must be cleared separately. We recommend documenting that caching may hide new data for up to 24 hours if TTL is high, so for critical errors cache must be cleared immediately.
Backup — built-in module (/bitrix/admin/backup.php). Describe how to create a manual backup, where it is stored, how to restore the site. This step saves the day in critical moments. In practice, regular backups prevent data loss due to hardware failure, hacking, or accidental deletion of important information by an administrator.
Module updates — through the Marketplace or /bitrix/admin/update_system.php. Advice: do not update immediately after release — give time to detect bugs. After updating, check functionality against a list of pages. Document the rollback procedure in case of critical problems after the update.
Specifics for Multisite Installations
If multiple sites run on a single Bitrix kernel, the guide must clearly differentiate: which infoblocks are shared and which are site-specific. The b_iblock table contains the SITE_ID field. The administrator must understand that changing a shared infoblock affects all sites. A mistake here is costly: a change in one infoblock can silently break logic on other sites. We recommend marking shared infoblocks in the guide with yellow, site-specific with green, to visually highlight critical points.
What’s Included in the Work
We prepare a complete administrator guide:
- Structured documentation for all sections
- Screenshots and infoblock card templates
- Instructions for technical procedures (cache, backup, updates)
- Maintenance checklist to keep it up to date
- Administrator training session on working with the document
- Consultation support for one month after delivery
Process and Delivery
Work begins with a detailed interview with the current administrative and technical team. We determine the site maintenance schedule, content update frequency, and typical administrator errors. Based on that, we create a guide tailored to your specific installation. Then we conduct a training session with administrators and leave a contact for questions for one month. The documentation is stored on a secure cloud service with versioning and change history.
With over 5 years on the market and 50+ completed Bitrix projects, order a guide and get a document that will save your team time.