NextMind CRM integration
Connects companies, tasks, people, meeting notes and follow-up candidates to a CRM assistant.
The NextMind CRM connection provides a controlled access layer for five read-only tools for company lists, tasks, related contacts, meeting notes and follow-up candidates. During initial use, the team should record the source of the question, applied filters and any confirmation step. That trace makes it visible that the connection is being used with the right scope in daily work.
Connector facts
- Availability
- self_hosted
- Authentication
- bearer
- Domain
- crm
- Kobi per call
- 0.1
Data surface and the business question
The NextMind CRM connection is designed for five read-only tools for company lists, tasks, related contacts, meeting notes and follow-up candidates. Connects companies, tasks, people, meeting notes and follow-up candidates to a CRM assistant. That means an assistant uses the permitted live-system context instead of guessing from a document. The result still depends on the freshness of the source system and the permissions granted to the connection.
A useful request makes clear which record is needed for which team. For this connection, a reliable flow is first finding the company identifier, then narrowing task or contact lists by status, priority and date filters. This makes filters and source records easier to inspect than asking for a broad list to be summarised.
Permissions, confirmation and responsibility
the assistant cannot create a task, delete a company or edit a meeting note; future write tools require single-use confirmation. This is more than a technical detail: an incorrect action in a financial, customer, production or legal record can have real consequences. Reading a result and changing an external system are not the same level of authority.
Before rollout, decide which assistants and departments can see this data. If a result is unexpectedly broad, reduce the access scope; if data is absent, do not let the assistant invent the missing record. The underlying system record and the accountable owner remain the final check for every consequential result.
Setup and operational review
runs self-hosted on mcp-host with bearer authentication; company and department grant context decide which assistant sees the tools. At setup, use a separate connection identity with least privilege so the accessible data does not exceed the operational need. For OAuth connections review the consent screen; for bearer connections review token scope, storage and ownership with the responsible team.
5 read-only tools and 0.1 Kobi Credits per call. This statement comes from the catalog or tool definition; no extra count is invented for a vendor-managed changing surface. During a pilot, observe real questions, returned records, confirmation steps and unnecessary calls. That evidence makes cost visible and exposes over-broad permissions early.
Frequently asked questions
What can this connection query?
five read-only tools for company lists, tasks, related contacts, meeting notes and follow-up candidates
What is a reliable working flow?
first finding the company identifier, then narrowing task or contact lists by status, priority and date filters
Are write operations unrestricted?
the assistant cannot create a task, delete a company or edit a meeting note; future write tools require single-use confirmation
How is the connection set up?
runs self-hosted on mcp-host with bearer authentication; company and department grant context decide which assistant sees the tools
Which metric is verifiable?
5 read-only tools and 0.1 Kobi Credits per call
What should I do with the result?
Review the result against the relevant system record and company policy; an assistant response does not replace an authorised person’s decision.