Bitrix24 Smart Processes (SPA): When to Use vs. Standard CRM

What Are Smart Processes in Bitrix24 (Alaio)

Smart Processes (SPAs) are fully configurable CRM entities: you define the fields, pipeline stages, automation rules, and access permissions - all without writing a single line of code, on the Professional plan or higher.

In Bitrix24's CRM, the native entities - Leads, Deals, Contacts, Companies - serve the standard sales cycle well. But a company's day-to-day operations extend well beyond closing deals: contracts need approval, production orders need tracking, assets need registering, and complaints need resolving. That is precisely where Smart Processes come in.

In practical terms, an SPA works like a "mini-CRM within the CRM": it has its own kanban board, list view, element card with custom fields, automations via robots and business processes, and role-based access control. Each SPA is self-contained - fields created in one process do not automatically carry over to another.

Based on real implementation projects, SPAs appear most frequently in the following contexts:

• Internal records: contract registers, equipment logs, warranties, technical documentation
• Post-sale operational processes: production, installation/assembly, logistics
• Approval workflows: supplier contracts, HR requests, freelancer payments
• Project portfolios: a master structure that aggregates multiple linked deals and objects
• Complaint and support management: triage, resolution, and client communication

Native Entities vs. Smart Processes: The Practical Difference

Use native CRM entities when the process is fundamentally a sale or a commercial relationship; use an SPA when the process has its own lifecycle, its own team, and is not a sales negotiation.

The table below summarises when each approach makes more sense:

Golden rule: if a team member opens the module and asks "does this have revenue attached to it?", use a Deal. If the question is "is this an object that needs to move through internal stages?", consider an SPA.

Anatomy of a Smart Process: Fields, Cards, and Stages

A well-configured SPA has three layers: the element card (fields that capture data), the pipeline stages (which define the lifecycle), and the automations (robots and business processes that trigger when something changes).

Element card and custom fields

The card is the heart of the SPA - it is where information lives. During configuration, you define:

• Field type: text, number, date, dropdown list, link to another CRM element, file, address, and more
• Card sections: group fields by theme for easier reading (e.g. "Project Details", "Documentation", "Responsible Parties")
• Mandatory fields: require critical information to be completed before an element can advance to the next stage

Based on typical implementation projects, a medium-complexity SPA usually contains between 15 and 30 fields. In more elaborate projects - such as multi-department implementations - the total number of fields across all SPAs can reach 75 or more, distributed across the processes.

Pipeline stages

Each SPA has its own pipeline, independent of all others. In real-world projects, we configure up to 15 stages per SPA, covering:

• Progress stages (e.g. "Awaiting Documentation", "Under Review", "Approved")
• Successful completion stages
• Unsuccessful completion stages (with a mandatory field to record the reason)

Once finalised, an element can be archived or promoted to another pipeline - including a sales Deal, if the internal process leads to a commercial opportunity.

Automations: robots and business processes

Robots execute automatic actions when an element enters a stage (send a notification, create a task, update a field). Business processes (BPs) are more complex workflows, triggered manually or by a field change, with multiple possible outcomes.

In reference implementations, a typical configuration includes:

• Up to 5 robots per SPA (reminders, task creation, alerts to responsible parties)
• Up to 3 business processes per SPA (chain approvals, document generation, integration with other modules)

Business processes can also be triggered automatically - when an element is created, when a field is modified, or via a CRM form, REST API, or marketplace integration.

Real-World Smart Process Examples in Production

In practice, the most common SPAs seen in implementations are: Project Register (the CRM's central anchor), Production/Assembly (post-sale operations), and Complaint Management (support and quality).

Project portfolio as the central anchor

At an engineering and construction company, the "Project Register" SPA served as the root object of the entire CRM architecture. Each project was recorded there first; only then were linked Deals created (one per asset or construction scope within the project). The SPA centralised client and supplier contracts, subcontractor agreements, technical documentation, freelancer payment approvals, and HR requests.

This model allows managers to view the full portfolio in a single place, while each team (commercial, technical, legal, HR) works within its own specific entity.

Post-sale production and assembly

At a manufacturing company, two parallel SPAs ("Production" and "Assembly") were linked to the sales Deal. When a Deal advances to "Order Confirmed", a BP automatically creates elements in both SPAs. Each SPA has its own stages, specific fields (work orders, delivery dates, technical owners), and robots that notify the operational team without any dependency on the sales team.

Complaint management

A complaints SPA allows managers to track every step - from receipt to resolution - directly on the kanban board. Robots automatically remind the responsible parties to follow up with the client; BPs create tasks for the legal team to prepare formal responses when required.

Asset and equipment register

Companies managing physical assets (fleets, machinery, IT assets) use SPAs as a living database: each item is an element with fields for location, status, maintenance history, and owner. Unlike a spreadsheet, the SPA supports automations (e.g. an alert 30 days before a maintenance deadline) and Bitrix24's native reporting.

When Native CRM Entities Are Still the Right Choice

If the process involves lead qualification, a sales pipeline with monetary value, or a commercial relationship history with a client, Bitrix24's native entities deliver more capability with less configuration complexity than an SPA.

Do not create an SPA when:

• The process IS a sale: use the Deals pipeline. It already has native integration with quotes, orders, products, and conversion analytics.
• You simply need more fields: custom fields on Deals or Contacts will solve the problem without creating a new object.
• You have two different sales pipelines: just create multiple voronkas (pipelines) within Deals - no SPA needed.
• The volume is low and the process is simple: a task checklist or a selection field is sufficient.
• The team is still learning the CRM: introducing SPAs too early steepens the learning curve.

A practical tip from project experience: in the first implementation iteration, configure the sales CRM first (leads, deals, pipelines). SPAs come in the second iteration, once operational processes are mapped and the team is comfortable with the tool.

How Smart Processes Integrate with the Rest of Bitrix24

The typical architecture in a portal with multiple SPAs - the flow starts from the initial client contact and branches into parallel internal processes:

flowchart TD
    A[Lead / Initial Contact] --> B[Sales Deal]
    B --> C{Deal Won?}
    C -- Yes --> D[SPA: Production / Execution]
    C -- Yes --> E[SPA: Assembly / Delivery]
    D --> F[SPA: Project Register]
    E --> F
    B --> G[SPA: Complaints / Support]
    F --> H[Documents & Approvals via BP]
    H --> I[Archiving or Next Phase]
    C -- No --> J[Reason Recorded + Archived]

The Sales Deal is the commercial starting point. Once won, it triggers operational SPAs (production, installation). All of these converge on the Project Register as the master entity. Complaints can be opened at any point, linked to the original Deal. Business processes centralise approvals and document generation.

This architecture - combining Deals and SPAs - is the standard approach used by ACP Group in implementations for engineering, manufacturing, logistics, and professional services companies. To understand how configuration scope is estimated, see our article on implementation hours by module in Bitrix24.

Automation Within Smart Processes: Robots, BPs, and BitrixGPT

Robots and business processes in SPAs follow the same logic as in the sales CRM - the difference is that the automation serves internal processes, not necessarily the client-facing relationship.

Robots (stage-based automation)

Configured per pipeline stage, robots execute immediate actions:

• Send a notification to the responsible party
• Create a task with a defined deadline
• Change the element's owner
• Send an email or internal message
• Move the element to another stage after X days without an update

Business Processes (complex workflows)

BPs support conditional logic, multiple approvers, branching paths, and integration with other elements. Common examples in SPAs:

BitrixGPT in SPAs

Bitrix24's AI assistant, BitrixGPT, can automatically populate card fields from call transcripts or chat summaries. This is especially useful in complaints and support SPAs, where the context of a client conversation needs to be captured quickly. Learn more in our article on AI call analysis in Bitrix24.

Step-by-Step Configuration: Creating Your First Smart Process

Creating an SPA requires no programming - the process is guided through the Bitrix24 interface and a basic version can be up and running in minutes, with refinements made incrementally over time.

1. Open the CRM and locate the option to manage Smart Processes (typically under CRM Settings or the processes menu)
2. Create the SPA: define the name, icon, and description
3. Configure the card fields: choose field types, group them into sections, and mark mandatory ones
4. Define the pipeline stages: create progress stages and completion stages (successful and unsuccessful)
5. Set up automation: add robots per stage and/or BPs for complex workflows
6. Define access permissions: who can view, create, edit, and delete elements
7. Test with real data before rolling out to the full team

For implementations with multiple SPAs, it is strongly recommended to map all processes and their fields before starting configuration - this avoids significant rework later. Our Bitrix24 discovery questionnaire includes specific questions designed for this mapping exercise.

If you are considering more advanced process automation, the article on process automation with robots and triggers provides a deeper look at the BP and trigger concepts that apply equally to SPAs.

Plan Availability and Implementation Considerations

Smart Processes are available on paid Bitrix24 plans - the availability of advanced features (such as full business processes) varies by plan; always verify on the official portal before designing your architecture.

Practical points to consider:

• Fields per SPA are independent: if two SPAs need the same field, it must be created separately in each (projects with 3 SPAs typically reach up to 75 total fields when accounting for overlaps)
• Each SPA has its own pipeline: stages are not shared between distinct processes
• Granular permissions: it is possible to grant read access to one SPA and write access to another for the same user
• Digital workspace: Bitrix24 allows multiple SPAs to be grouped into a dedicated workspace for a specific team or department, with simplified navigation
• Enterprise plan: advanced digital workspace features are dependent on the Enterprise plan in Bitrix24 Cloud; if you downgrade, the workspace becomes available in read-only mode

For teams evaluating the self-hosted option and wanting to understand what can be customised beyond cloud limitations, see the article on customisation in Bitrix24 self-hosted.