I bring order to your Bitrix24, CRM and business processes

• REST already overloads the portal
• Standard robot setup is not enough
• Custom event handlers are needed
• Heavy operations slow the CRM down
• Custom tabs and actions in the card are needed
• Logic is "scattered" and breaks on changes

• Stable logic inside the portal
• Clear logs and diagnostics
• Less load on REST
• Documentation of entry points
• Maintainable code structure

• I do not replace a full DevOps/SRE
• For production changes I first review logs and make a backup
• I give the exact price after access to the portal

• Need an external product on top of the CRM
• Need an API or an integration hub
• The logic does not fit in the box
• Need queues and background jobs
• Need an admin panel with roles

• Errors are visible in logs
• Heavy operations go to a queue
• The project is easier to maintain
• New features without chaos
• Testable code

• I prepare infrastructure within my own solution, not as DevOps outsourcing
• A full rework of an old project — as a separate estimate

• Sync works "sometimes"
• Duplicates appear
• Data diverges between systems
• No exchange history
• The error is not visible to the user
• The CRM needs to be connected to an external service

• Data is not lost
• Duplicates are not created
• The exchange does not fail silently
• Clear logs of incoming/outgoing requests
• The ability to retry a failed operation

• I am not responsible for failures on the side of external services and providers
• I mask secrets and do not log tokens
• First a test environment, then production

• Data is transferred manually
• Spreadsheets are reconciled between systems
• Requests get lost
• Approvals happen "verbally"
• No deadline control
• Reports are assembled by hand

• Less manual work
• Requests and approvals are not lost
• Transparent deadlines and statuses
• Reports assemble themselves

• First I record the current process, then automate it
• Complex scenarios — in stages
• Depends on access and the systems' data

• The developer left, the code stayed
• No documentation
• No logs
• Processes break
• Scary to touch production
• You need the cause, not a "symptom fix"

• A clear problem map
• Priorities and a plan
• Timeline estimate
• Recommendations on logs and architecture
• Understanding of what can be left as is

• I do not touch production blindly
• I make a backup when there is a risk of data loss
• A full architecture rework — as a separate estimate

• Integrations fail silently
• No exchange history
• A failed operation cannot be retried
• Data gets duplicated

• Integrations
• Exchange logs
• Retry / backoff
• Encrypted secrets
• Health-check
• Queues
• Admin panel

• Does not replace an enterprise-grade ESB/iPaaS
• Each system is connected as a separate task

• Lead and deal duplicates
• Robots and workflows misfire
• Heavy REST requests
• No logs or history

• Structure overview
• Logs check
• Risk search
• Problem map
• Risk table
• Fix plan

• Fixes are a separate stage
• Without access to logs/code, accuracy is lower

• Unclear whether an event arrived
• No payload to investigate
• The error is not visible
• Cannot resend

• Receiving webhooks
• Storing payload
• Signature check
• Processing status
• Errors
• Manual retry

• Built on top of Integration Hub
• Processing is set up separately for each source

• Clients cannot see statuses and data themselves
• Support is overloaded with repetitive questions
• Requests and messages get lost in email/messengers

• Authentication and roles
• Requests and statuses
• Messages
• Documents and invoices
• Notifications
• CRM integration
• Admin panel

• Not a licensed SaaS — it is an adaptable base
• Complex custom modules are estimated separately

• Clients have nowhere to see CRM statuses
• Managers forward data manually

• Request statuses
• Inquiries
• Invoices
• Messages
• Connection to CRM data

• Depends on the Bitrix24 edition and access
• Heavy logic is moved to D7 separately

• Employees work in scattered spreadsheets
• No single point for tasks and requests

• Authentication and roles
• Tasks / requests
• Access to process data

• Designed for the task — requires scoping

• Partners cannot see request statuses
• Documents and calculations are handled manually

• Partner authentication
• Requests and statuses
• Documents
• Calculations

• Designed for the partner model

The exchange runs through a financial broker whose actual callback format differed from the spec; the bank has its own status dictionary, and credit products have amount and term limits. Once the contract is approved, an application can no longer be submitted.

• A "Credit applications" smart process with 21 result fields and role-based permissions: a manager sees their own applications, a head of department sees their department, an admin sees everything
• Submission to the broker from the deal card: a draft, checks of required fields and product limits, a block on submitting after contract approval, and double-click protection
• Callback intake: key-based authorization, idempotency by eventId, tolerant body parsing — callbacks had silently failed to save for 5 days because of a mismatch with the spec; found and fixed
• A bank status dictionary — 28 business statuses and 16 technical ones; a final decision creates an activity for the manager and is written to the deal timeline
• An SMS to the client with a link to the bank questionnaire under a "one application — one SMS" rule, with delivery-report intake
• An exchange log across 6 directions, a "Submit application" business-process robot, and a morning watchdog for applications with no events for over 3 days

The module has been in production since August 10, 2026, on the broker's live environment since September 8, and client SMS have been going out since August 31. 192 CLI checks cover the offline logic, and every exchange event is visible in the log and on the deal timeline.

A live cloud portal with robots and mailings on stages — any mass move immediately sends messages to real people. REST silently ignores some filters and limits execution time, and the server and the portal live in different time zones.

• Intake of Bizon365 attendance reports: by broadcast day, a deal moves only forward by stage weights and never rolls back
• A separate branch for case-study webinars — a task for the owner instead of a new deal, idempotency by an event sha256 key and a dry_run mode with zero writes
• Moving no-shows to "Did not attend" in batches: writes only with --execute, protection against repeated and parallel runs, protection for those who attended the broadcast
• An invitation 10 minutes before the broadcast via a trigger stage, returning the deal to its original stage; course buyers are excluded from the mailing
• Joining a WhatsApp chat via ChatApp moves the deal to the right stage — through a file queue with flock instead of creating new deals
• A REST wrapper that never reports errors as success and waits on its own until the portal allows requests again

Broadcast invitations reached 628 of 628 participants with no errors, 451 of 451 deals were moved to "Did not attend", and a backlog of 396 deals was cleared; attendee protection filtered out 65 of 78 deals. A contact audit found 564 cards with a phone number in the "Name" field — the source of undeletable duplicates.

Nothing could be deleted: these are working documents in court cases. Some links went through an external URL shortener or pointed to the old portal, some cases had their own folder containers, and ambiguous matches could only be resolved together with the lawyers.

• Read-only discovery: the folder pool, classification of every link from the cards (working, via shortener, old portal, empty, junk), orphan folders
• Merging duplicate folders with priority to the root case: contents move into the canonical folder, sources are not deleted, suspicious groups go to manual review
• Syncing files from the card's file fields into the case folder without duplicates by name and size, repairing links and backfilling the service field with the folder id
• Recreating missing folders for cases that had no working folder on the drive at all
• A final one-command pipeline: three dry runs by default, a live run only with confirmation, stop on the first error; a nightly sync via cron

Discovery found 334 folders, 16 duplicate groups and 298 fixable shortener links. The live run processed 750 items: 2,544 files copied, 302 links repaired, 250 folder ids filled — 0 errors; a repeat check confirmed 7,182 files in place across 780 items.

Production cannot stop, and dozens of integrations depend on the current behavior; auditing had to be enabled by flags with safe defaults, and personal data must end up neither in responses nor in logs.

• Closed 6 places that issued an admin session on an anonymous request and an authorization bypass in 6 API endpoints; stack traces removed from responses
• Anonymous endpoints got rate limiting, the IIN is validated before paid external calls; IDOR and CSRF closed in working interfaces
• The login-form password is encrypted in the browser (RSA-OAEP, 4096-bit key); about 50 hardcoded credentials moved to .env
• An audit trail behind flags: failed logins, an API call log, a syslog mirror; a daily watchdog for log rotation and for regressions of mandatory 2FA
• The logger masks IINs, phones and cards; 90-day rotation plus a 400-day archive; false masking of hashes cut from 5.1% to 0% on 200,000 values
• A log viewer with charts and cross-log search by request id; a health API catches error spikes against the median, silence and stalled rotation

Accumulated logs were archived: 6,344 files totaling 2,041 MB compressed into a 120 MB archive with checksums, and the local/ directory shrank from 2.6 GB to 578 MB. Critical access holes are closed, and the logs show incidents rather than noise.

The live flow is about 95 requests a month, so the catalog was built on actual request frequency rather than "the usual way". An administrator must be able to edit the catalog without a developer, and the SLA deadline must not be quietly stretched.

• Analyzed the OSTicket export: separated out monitoring, counted frequencies by topic — and built a two-level catalog of 11 areas and 32 services from them, most frequent first
• A service's clarifying questions are described by a JSON schema with dependent fields; the same validation rules on the server and in the browser are checked against shared test fixtures
• Effective priority "service × urgency", response and resolution targets in working minutes; the original deadline is fixed at submission and cannot be stretched
• Auto-assignment to the least-loaded assignee in the service group and an SLA control agent with notifications
• One catalog-and-wizard engine serves 4 catalogs: help desk, HR processes, document workflow and development requests

Instead of five categories and one deadline for everything — a catalog based on actual demand, per-service targets (from 15/60 minutes for a password reset to 480/4,800 for portal development) and a deadline that cannot be moved unnoticed.

The widget has to embed on the external websites of network locations (including WordPress) without Bitrix authentication, while occupancy status still has to stay in sync with real CRM data.

• An embeddable interactive floor-plan builder — a public iframe/JS widget with no Bitrix auth (CSP/CORS configured for embedding from external domains)
• An internal admin panel for uploading and editing floor plans
• Auto-sync of occupancy status, tenant name and lease end date from the CRM via cron — plan images are uploaded manually, occupancy data updates itself
• Occupancy dashboards per site: percentage occupied by area (m²), office count, and revenue from occupied space
• The widget is already embedded on external sites for network locations

Across the network: 93 floors, 1,087 offices and 152 uploaded floor plans — with occupancy that updates from the CRM automatically instead of being reconciled by hand for every site.

The robot works in campaigns — one per application step; one client can have several cards; a repeated cron run must not produce a second call, and calls are allowed only in a daytime window.

• A cron job every 15 minutes selects deals idle for 30+ minutes using the stock stage history: a stage change resets the timer
• A pipeline stage map: each application step leads to its own robot campaign; final, rejection and service stages are never sent; calling window 08:00–21:00
• "One client — one call": cards are grouped by phone, the most recent one goes to dialing, and a negative outcome removes all cards with that number from dialing
• Three-layer idempotency: flock against parallel runs, order fields on the deal and a stable import_id on the robot side
• The call-result webhook finds the deal, records the outcome without overwriting fields with empty values and starts a business process; there is a test mode on a separate campaign
• Selection logic moved into pure functions without the Bitrix core and covered by 66 smoke checks

Stuck applications go to the robot automatically, without manual calling, and a client never gets two calls for different cards. Every run logs the skip reason for each card.

Some classic call-center metrics (SL/ASA/ATA) simply cannot be computed without telephony data; mixing different date sources (lead vs. visit) skews percentages unless kept separate.

• 20 parameterized SQL reports on top of live CRM data with safely substituted filters
• A "lead to visit to deal to sale" funnel with intermediate metrics (contact rate, occupancy, etc.)
• A multi-level TTL cache with stale fallback and locks — the dashboard never hits the CRM with heavy queries directly
• 33 whitelisted AJAX actions with permission and session checks
• Honest documentation of the limitations of every disputable metric instead of dressing up the numbers
• A head-of-sales dashboard per dealership: metrics are calculated by the deal's own dealership, and any number expands into a list of deals with a click
• A marketing dashboard by business line and traffic source; comparison with the same dates of the previous month on every page
• A shared report cache with an access check before the cache: the first build takes 7.2 s, the next user gets it in 0 ms
• A "who sees which report" access registry with the source of each grant, access granted without a deploy, and a unified navigation header across reports

Management, the call center, heads of sales and marketing got a set of dashboards on live CRM data instead of Excel exports: funnel, dealership, marketing — with a shared cache, click-through drill-down on every number and clearly documented metric limitations. Access to 6 reports is managed from a single registry without a deploy.

• Lead and deal duplicates
• Dirty phone numbers
• Lost links
• CRM and warehouse divergence
• Outdated stock

• Count duplicates and mismatches with queries: the number of affected records is visible before any fix
• Normalize phone numbers, emails and key fields to a single format
• Add a lookup for an existing record before a new one is created
• Close the source: the form, import or integration that produced the junk
• Leave a reconciliation you can re-run and see the result

• Robots do not fire
• Business processes hang
• Approvals are manual
• No deadline control
• Managers bypass the CRM

• Find which step processes stall at and on which condition
• Compare what should trigger a robot with what actually triggers it
• Move fragile logic out of the visual builder into code with logs
• Add deadline control and notifications for the people responsible
• Remove the manual steps that make managers bypass the CRM

• No logs
• No retry
• API fails
• Data arrives partially
• The error is not visible to the user

• Turn on logging of incoming and outgoing requests, with tokens masked
• Add delayed retries for temporary errors on the other side
• Separate "no data arrived" from "data arrived partially" — different failures
• Surface the error where a person will see it, not only the server
• Leave a verify mode: run the exchange without writing to the live database