If you run on Slack, your CRM tells Slack.
The infrastructure that carries CRM events into your channel is ready in the product: a signed outgoing webhook, retry on failed calls, and a notification node in the workflow engine. 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, OAuth2, 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 outgoing webhook is signed, a failed call is retried, the target address goes through SSRF validation, and this notification sits as a node in the visual workflow designer. So it is not something to be "written", it is something to be configured.
Let us write this down too: to date not one of our tenants has switched it on. We measured it — across 24 tenants, defined webhook subscriptions: zero. That is why you will not read the sentence "our customers are connected to Slack" on this page. The capability exists in the product, the usage has not been measured; we do not want to confuse the two. The workflow engine it runs on, however, is in production: across flows defined in two tenants, 617 of 617 measured runs completed successfully.
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. That the API really can be used from outside, we can state only through a borrowed fact: at a live customer installation, a third-party ERP integrator reads and writes records over that same REST API. We do not give the name because we do not have permission to publish it; what we are stating is a measured fact. This is a single installation, not a list of cases. 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 signed 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 call is signed; the receiving side verifies the signature and filters out forged notifications. A failed call 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 and OAuth2. 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
Signed outgoing webhook
On record-created and record-changed events, a notification goes to an external endpoint. The call is signed; the receiving side verifies the signature and filters out forged notifications.
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.
SSRF validation
The webhook target is validated; an endpoint pointed at the internal network is 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 and OAuth2 for the reverse direction
If you want to create records in the CRM from the channel, this is the surface you rely on: the product ships out of the box with 183 business objects, each published in the REST API with its own data and schema endpoint; access is authorised with OAuth2, and the field structure is read from outside with describe.
Which direction is ready, and which is a project?
| Direction | What exists today | How it is set up |
|---|---|---|
| CRM → channel notification | Signed outgoing webhook, retry, SSRF validation and the workflow node 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 and OAuth2, 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, signature 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.
Our limits: what we do not promise on this page
The notification infrastructure being ready does not mean we can promise everything. We write out by name the things we do not promise.
- We do not offer a Slack app, bot or slash command. There is no listing from us in the app directory, and we do not say there is.
- We do not say "our customers are connected to Slack". We measured it: across 24 tenants, defined webhook subscriptions: zero. The capability exists, the usage does not; those are two separate sentences.
- Slack conversations do not land on the customer record. The messaging channel list is closed: email, WhatsApp Business API, WhatsApp QR pairing and SMS. Today the route that ties a conversation to a record is the WhatsApp Business API and email.
- We do not offer WhatsApp QR pairing as a product promise. 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 this one, we share the risk in writing and take the decision together. The details are on the WhatsApp integration page.
- We do not say your stock will stay in sync. Authority over the stock record stays in your ERP or warehouse system.
- We do not say the order → invoice → collection chain will flow on its own. The chain is set up in the product; we do not think it is right for it to be sold as an automatic accounting flow.
- We do not promise manufacturing and MRP automation. Bill of materials and line definitions exist in the product; we cannot describe work-order execution with a reference today.
We wrote the reason for the last three, and "what can be done instead", in a single place: the three things we do not promise. We do not repeat it here, so that we do not end up making two different statements in two places.
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 many of your customers use 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 demo 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.
The event list and the channel mapping are worked out in the discovery call and shared in writing.
