Bitrix24
Assessing self-hosted Bitrix24 before development
What to establish about versions, permissions, integrations and releases before estimating changes to an existing portal.
Estimating changes to an existing portal should start with a user scenario and its dependencies. A small interface button may change permissions, trigger automation or send data to an external system. Assessment helps define the scope before the team agrees on deadlines.
This is my recommended approach to assessing a project's technical context. It focuses primarily on self-hosted Bitrix24 and does not replace a dedicated security or performance audit.
1. Describe the user's action
“We need to improve tasks” does not define an outcome. Identify one specific scenario: who opens the section, what they select, what action they take and what they should see afterwards.
For example, an employee submits a request, a task is created for the assignee, and the employee can see its status. Before estimating, clarify who chooses the assignee, what happens on resubmission and whether an employee can open someone else's request. This is a hypothetical example, not a description of a particular implementation.
Write the acceptance criterion in the user's terms. Then check whether a standard feature or existing integration already handles part of the scenario.
2. Record the technical environment
| What to establish | Why |
|---|---|
| Self-hosted or cloud, product edition | Identify available customisation methods |
| PHP and affected module versions | Compare the code with the actual API |
| Local and third-party modules | Find the owners of application logic |
| Background jobs and agents | Understand when deferred work runs |
| Cache and external services | Identify additional dependencies |
| Test environment and release process | Choose a safe verification method |
A targeted set of information is enough for an initial assessment. A full database dump or unrestricted access should not be a prerequisite for discussing a task. First, define the permitted read scope and anonymised examples.
3. Trace the data path
Follow the action from interface to result: component or controller, permissions check, application logic, data persistence, event, background job and external call. Not every project has every step, but an overlooked dependency can change an estimate.
Record the owner of each entity. If a catalogue comes from 1C and a user changes a value on the website, establish whether that change will survive the next exchange. Also distinguish the data source from its cached copy.
4. Check errors and recovery too
A minimum set of related checks:
- A user without the required permissions cannot perform the action through a direct request.
- Resubmission does not create an unwanted duplicate.
- An external-system error is not presented as successful completion.
- A partially completed operation has a clear recovery method.
- The change does not break an existing scenario using the same data.
Adjust this list to the risk of the task. Checking a button colour and checking an exchange that creates records in two systems require different depths of verification.
5. Agree on release and rollback
Before implementation, establish who releases the change and where the previous version is stored. If data changes, restoring files alone may not be enough: separate steps may be needed to make old code compatible with the new structure.
After release, run a short check tied to the original task. “The page opens” is weaker than “a user with the required permissions completed the scenario and received the expected result”.
What the assessment should leave behind
The assessment should describe the goal, affected components, dependencies, unknowns, stages, acceptance criteria and release conditions. Separate the estimate into work you understand and questions that still affect it.
If uncertainty concerns one API or background process, investigate that part first. Refine the plan afterwards. This gives the client a basis for a decision and the developer a verifiable task boundary.