Many sales teams do not lack tools. They lack a clear view of what is happening across leads, tasks, conversations, and automation.
We are building ToolsFlowCRM around that problem: keep the daily sales workflow connected without forcing a small team to assemble and maintain several separate products.
ToolsFlowCRM is currently in active development. Its CRM features are available without plan limits while we test the product, improve the workflows, and learn from real feedback.
What the product brings together
The current product combines:
- configurable Kanban pipelines for leads and deals;
- contact and company records connected to each opportunity;
- tasks and calendar planning;
- customer conversations in the same working context;
- analytics for day-to-day visibility;
- API access and private integrations;
- Flow Bot, a visual editor for branching business processes.
Each workspace receives its own CRM address, so teams can work in an isolated environment and adapt the pipeline to their actual sales process.
Why connected context matters
A lead rarely lives in only one screen. A salesperson may need the current pipeline stage, the main contact, the next task, the latest conversation, and the result of an automation at the same time.
When those pieces are split across different products, people compensate with spreadsheets, copied notes, and manual reminders. The problem is not only extra clicks. Context becomes inconsistent: one system says a lead is waiting for a reply while another already contains the answer.
Our design goal is to make the customer journey visible from capture to follow-up. The pipeline remains the operational overview, while the entity card contains the details and activity needed to make the next decision.
Visual automation instead of hidden rules
Flow Bot is our approach to workflow automation. A process is represented as connected nodes with explicit branches and results. Teams can see where a process starts, what conditions are evaluated, which action runs next, and how subprocesses relate to the main execution.
This visual model is useful for practical workflows such as:
- assigning a new lead based on source or pipeline stage;
- creating follow-up tasks;
- filling CRM fields;
- sending webhooks to private systems;
- waiting for a result and continuing on the selected branch.
The editor is still evolving, but the principle is stable: automation should be inspectable. A user should be able to understand the path without reading JSON or reverse-engineering an invisible rule engine.
Documentation is part of the product
An API is only useful when another developer can understand its behavior quickly. We maintain a custom developer documentation portal alongside the interactive API reference.
The documentation is organized as task-oriented articles rather than one large schema dump. It explains authentication, pagination, entities, request examples, response examples, and the details that tend to cause integration bugs.
For example, list endpoints return up to 250 entities by default. A smaller limit can be requested, but values above 250 are capped. Small contract details like this belong in the main documentation, not only in generated OpenAPI output.
What we are optimizing for
We are deliberately prioritizing clarity before feature count:
- A pipeline should communicate state at a glance.
- A customer record should preserve the context needed for the next action.
- Automation should show its branches and execution history.
- API behavior should be documented with concrete requests and responses.
- The interface should remain dense enough for daily work without becoming visually noisy.
This is an iterative process. Real CRM workflows surface edge cases that polished mockups do not: overlapping automation branches, ambiguous subprocess history, inconsistent result editors, and translations that need one canonical source of truth.
Try it and share feedback
You can explore ToolsFlowCRM at toolsflow-online.com and read the developer documentation.
The product is still in active development, so focused feedback is especially useful: what information is missing at the moment of a sales decision, which repetitive step should be automated, or which API behavior is difficult to understand?
Those concrete workflow problems are what we want to solve next.
Top comments (0)