Custom fields and card layout
Industry-specific fields, dependent lists and role-based screen layouts. No code needed.
Bitrix24's standard structure is enough for most companies. Where it is not, we look at configuration before code; unnecessary development becomes a maintenance burden later.
At a glance
Most incoming requests are not really customisation but a need for correct configuration. Cases that genuinely need customisation look like this:
From light to heavy; we decide together where to stop.
Industry-specific fields, dependent lists and role-based screen layouts. No code needed.
Your own record types: service tickets, contracts, applications, projects ; with their own stages and automations.
Multi-step approvals, conditional branching and RPA for work that falls through the cracks.
Custom interfaces, calculators and services running inside the portal that talk to outside systems.
Dashboards built on BI Builder for measurements the standard reports do not cover.
Packaging a repeatable need as an app on Bitrix24.Market.
A good share of customisation requests can be met with Bitrix24's existing tools. Custom fields, smart processes, automation rules and the workflow designer together get you a long way without code.
So every request goes through a "can configuration solve this?" filter first. If it can, we do not write code; because every line written means maintenance, testing and update work later.
Bitrix24's standard CRM objects do not fit every business. A service company needs a "fault ticket", a school needs an "application", a developer needs an "apartment".
SPA lets you create those record types with their own fields, stages, Kanban view and automation rules. They can be linked to standard CRM records and use the same reporting layer.
For work that genuinely requires development we use Bitrix24's REST API. That approach has an important advantage: because the code does not live inside the portal it is not affected by Bitrix24 updates.
Apps are authorised with OAuth 2.0, reach only the scopes they need, and event payloads are checked with signature validation.
Every piece of development is a liability as much as an asset. The code has to be tested, kept compatible with Bitrix24 updates and changed as requirements move.
So the quote shows not only the build cost but the maintenance expectation afterwards, in writing. Sometimes that conversation ends with deciding not to build at all and living with configuration instead.
How would this work in your process?
In a free 30-minute call we listen to your workflow and map out how this would run in your company.
At every step we ask again whether it is really needed.
We work out the real job behind the request; the answer is often something else.
Configuration, SPA, a Market app or development ; presented with their costs.
The agreed solution is written and verified on a test portal.
Released, demonstrated to the team, documentation handed over.
The modules we most often roll out alongside this one; they reinforce each other in the same setup.
Bitrix24 is not a closed box. The REST API gives programmatic, scope-controlled access to your CRM entities over standard HTTP; and we design, build and monitor the integration for you.
When approvals run over email and chat, nobody knows where a request is sitting. We turn your internal processes into flows with defined steps, owners and deadlines.
If a rep's day goes to logging records, setting reminders and retyping the same email, that is revenue leaking. We move that work to robots and give your team back the conversations.
Access management is more than a password policy: permissions, audit trails and retention are designed together. We map Bitrix24's role-based model onto how your company actually works.
Opening a Bitrix24 account takes five minutes. The real work is getting your sales process correctly placed inside that account; that is what we mean by setup.
We design training as the team doing their own work on their own screen, not as a generic product tour. No slide deck, everyone opens their own record.
Things keep changing after setup: new products, new people, new processes. A support plan lets you make those changes without opening a project each time.
Apps written against the REST API do not live inside the portal, so they are not directly affected by updates. Bitrix24 does occasionally change the API; for customers on a support plan we track that compatibility.
Yes. We hand over the source code and technical documentation of anything we build. If you continue with another team you have a complete handover package.
Yes. On-premise gives source code access, so you can go deeper than the cloud allows. It also increases your update and maintenance responsibility; we weigh that up together.
No, we would recommend the ready-made app first. If something on Bitrix24.Market meets your need, building is both more expensive and more work to maintain. Filling the gaps a Market app leaves is the better route.
Custom fields and screen layouts take a few days, an SPA design one to two weeks, a REST API app two to six weeks depending on scope. We give the exact timeline in writing after analysis.
Book a free intro call and we'll walk through your process and show which settings fit you.