If you run on Slack, your CRM tells Slack.
The infrastructure that carries CRM events into your channel is ready in the product: an outgoing webhook, retry when a notification does not arrive, and a notification step in the visual workflow designer. We decide together in the discovery call which event lands in which channel, and we set up the subscription.
Decisions are made in the channel, the record sits somewhere else
In a team built around Slack, work is discussed in the channel. Decisions are made in the channel, news is heard in the channel, files circulate in the channel. The CRM, meanwhile, is a separate tab. Here is where the mechanism breaks: the news is produced in the channel, the record is kept somewhere else, and the only thing connecting the two is someone switching tabs. This is the picture we have seen in our own projects:
- When a deal closes, the first to announce it is the person who writes in the channel. When the record gets updated remains a separate question; sometimes it never does.
- The question "who is handling this customer?" is asked in the channel, answered in the channel and stays there. Three months later the same question is asked again.
- A lead arriving from the web form waits until a rep opens the CRM. First response time comes to depend on who switched tabs and when.
- Announcements are written by hand: someone sends the "this quote was approved" message if they remember, and does not if they do not. The notification depends on a person, not on a process.
- Channel history looks like an archive but is not one: a message can be found by searching, but it is not attached to the customer record.
- As the number of channels grows, so does the noise. Because it was never decided which events are genuinely worth announcing, either everything gets posted or nothing does.
The need here is not to turn a chat app into a CRM. Let the record stay in the CRM and let the news reach the channel on its own, with the decision about which news arrives already made in advance.
One direction is ready, the other is a project; we keep them apart
There is no out-of-the-box module for Slack, and we will not say there is. The connection is built as an integration project whose scope is set in the discovery call, using the REST API, webhooks and import/export.
But there is something we have to write out separately on this page, because Slack is different from the other headings: the infrastructure the notification direction rests on is complete in the product today. The receiving system can verify each notification came from us, a notification that does not arrive is retried, the target address is validated so addresses inside your internal network are not accepted, and the notification sits as a step in the visual workflow designer. So it is not something to be "written", it is something to be configured.
This feature is new; if your decision depends on it, let's try it together in a demo. The notification is configured as a node in the same workflow engine the product's other flows run on.
The reverse direction (creating a record in the CRM from the channel) is not equally easy, and we do not present it as if it were. That direction is written over the REST API. The API is usable from outside: ERP integrators can read and write records through this same REST API. We described the same framework as it applies to an ERP on the Netsis integration page, and our general approach on the integrations page.
Friday 17:20. The week is closing, the sales channel is open. Once the connection is in place, this is what changes:
-
1
A won deal lands in the channel on its own
On the deal-won event, a notification goes to your channel. What announces the news is the record itself, not a person; nobody forgets to announce it, nobody announces it twice.
-
2
The notification arrives with the record's address
The message carries the fields you defined in scope (customer name, amount, owner), along with a link to the record. From the channel you reach the record itself in one step.
-
3
You decide which event goes to which channel
Sales, support and management channels can be fed separately. The event list per channel is defined during setup; noise is not turned down afterwards, it is limited from the start.
-
4
A new lead does not wait for a tab switch
A record arriving from a form or from the API lands in the CRM with its source tagged and is announced in the channel at the same moment. The first response no longer depends on someone opening the CRM.
-
5
If a notification cannot be delivered, it does not vanish silently
The receiving system can verify the notification came from us and reject forged ones. A notification that does not arrive is retried, so a temporary outage on the other side does not mean data loss.
-
6
Writing from the channel into the CRM is separate work, and is priced that way
If you want to create a record from a message in the channel, the route is the REST API, with permission-based access. We do not offer this as an out-of-the-box feature; we build it as separate work whose scope is set during discovery.
The surface a Slack connection rests on
Outgoing webhook
On record-created and record-changed events, a notification goes to the receiving system. It can verify the notification came from us and reject forged ones.
Retry on failed calls
If the other side cannot respond at that moment, the call is retried. A temporary outage does not mean a notification that never arrives.
Target address validation
The webhook target address is validated; addresses inside your internal network are not accepted. This is the notification infrastructure's own security control.
Notification node in the workflow engine
The notification is a node in the visual workflow designer: conditions, filters and ordering are set up inside the same flow, and no code is written.
Records that arrive with a source tag
Which channel the record behind a notification came from is held in the source field. Which channel brings in business shows up in the report, not in the channel.
REST API for the reverse direction
If you want to create records in the CRM from the channel, this is the surface you rely on: every record in the CRM can be read and written through the REST API; access is granted with permissions, without sharing passwords, and the field structure can be read from outside.
Which direction is ready, and which is a project?
| Direction | What exists today | How it is set up |
|---|---|---|
| CRM → channel notification | Outgoing webhook, retry, target address validation and the workflow step all work in the product | The subscription and the event-to-channel mapping are configured during setup; no code is written |
| Creating a record in the CRM from the channel | We have no Slack app, bot or slash command | Written over the REST API, as separate work whose scope is set during discovery |
| A CRM screen embedded inside Slack | None; we do not offer an interface that opens inside Slack | We do not offer it. The link in the notification takes you to the record itself, and the screen opens in the CRM |
| Logging a Slack conversation onto the customer record | None; the messaging channel list is closed: email, WhatsApp Business API, WhatsApp QR pairing and SMS | If you want the conversation recorded, the route that works today is the WhatsApp Business API and email. WhatsApp QR pairing is not an official API and carries the risk of the number being restricted; we do not offer it as a product promise |
What we have verified
How is Slack notification put into service?
-
1
Discovery
We work out which events should land in the channel and which channels will be fed. We recommend that whoever holds the right to add apps on the Slack side joins the call.
-
2
Scope and event list
The event-to-channel mapping, the fields to appear in the message and the noise limit are put in writing. The scope and the cost, if any, are shared in writing before work begins.
-
3
Configuration and test notification
The subscription is defined, verification is tested on the receiving side, and test notifications are sent with sample events. Retry behaviour is also observed at this stage.
-
4
Go-live and first-week tuning
The channel layout is settled together with the team. Notification volume is watched during the first week; if too much arrives, the event list is narrowed. Noise is a matter of tuning, not of fate.
Scope and setup terms
What the Slack connection covers:
- Notifications reach Slack through an outgoing webhook. There is no Slack app, bot or slash command, and no listing from us in the Slack app directory.
- Slack notification is new. The capability is in the product; if your decision depends on it, let's try it together in a demo.
- Conversations are linked to records through the WhatsApp Business API and email. Slack conversations do not land on the customer record; the messaging channels are email, WhatsApp Business API, WhatsApp QR pairing and SMS.
- WhatsApp QR pairing comes with a caveat. The same inbox can also be connected this way, but the method is not Meta's official API and carries the risk of the number being restricted by Meta. The route we recommend is the official Cloud API; if you still prefer QR pairing, we share the risk in writing and take the decision together. The details are on the WhatsApp integration page.
- Stock stays in your ERP or warehouse system. Authority over the stock record stays there.
- The order → invoice → collection chain is set up in the product. It is not sold as an automatic accounting flow.
- Manufacturing and MRP: bill of materials and line definitions exist in the product. Work-order execution is new; if your process depends on it, let's try it together in the demo.
The reasons for the last three, and what can be done instead, are in one place: scope and setup terms.
Data location: your data is kept in the European Union: the database in Helsinki (Finland), files in Frankfurt, backups in Falkenstein (Germany). We have no component in Türkiye, and we have no such feature as region selection. When you send a notification to Slack, the content of that message goes to Slack's own infrastructure; you decide which fields appear in the message when the scope is set. This is a transfer abroad under KVKK art. 9; we establish its legal basis together during the contract process. The details are on the security page and in the KVKK disclosure notice.
Certification: we hold no ISO 27001 or SOC 2 certificate, and we will not claim one until we do. We fill in your enterprise security assessment forms and describe the architecture in writing.
We put the number on the pricing page, not on this one
The scope of Slack notifications, and the cost if there is one, are worked out in the discovery call and shared in writing. Plan prices we keep in one place, so that you never read a different number in two places.
Three plans, a scope table and separately priced items, all on one page.
Frequently asked questions about the Slack integration
Does Rapitek CRM integrate with Slack?
Does Rapitek CRM have a ready-made Slack app?
Which events can be sent from the CRM to Slack?
Can we create records in the CRM from Slack?
Do Slack conversations land on the customer record?
Are the notifications secure, and can a forged notification be told apart?
What happens if a notification cannot be delivered?
Can we send notifications to a tool other than Slack?
How mature is the Slack connection?
Is the Slack connection included in the plan price?
How long does setup take?
How do you limit notification noise?
Where is our data kept?
Can we see it before buying?
Let us settle which events land in the channel in 30 minutes
In the intro call, let us show how the notification node is built in the workflow designer using your own scenario, and let us determine the event list and the noise limit together. Then we open your 7-day trial account; no credit card required.
