Most teams treat Slack as a dumping ground for every tool notification. Here is how to wire Decuga to Slack so project management, service desk, and change management alerts each land exactly where they belong.
The average product team has seven or more tools posting to Slack. The result is a #general channel full of Jira issue updates nobody reads, a #alerts channel where critical production warnings get buried under sprint board noise, and a #support channel where ticket updates and bug reports compete for attention. Notifications become wallpaper. The important ones go unread for hours — not because people are ignoring them, but because the signal-to-noise ratio is so low that scanning the channel no longer feels worth the time.
7+
Average tools posting to team Slack
63%
Slack notifications ignored within 1 hour (Slack internal data)
3
Decuga notification channels — PM, SD, Change
1
Bot token needed for the whole setup
Rather than sending every notification to a single webhook URL, Decuga routes events by category. You configure three separate Slack channels — one for Project Management events, one for Service Desk events, and one for Change Management events. Each team subscribes only to the channel relevant to them. A support agent does not need to see sprint task assignments. An engineer reviewing change requests does not need ticket status updates cluttering their feed.
| Channel | Events delivered here | Who subscribes |
|---|---|---|
| #pm-alerts (or similar) | Task assigned, mentions, comment replies on tasks | Product managers, designers, developers |
| #support-alerts | Ticket assigned, ticket status changed, comment replies on tickets | Support agents, customer success |
| #change-alerts | Change submitted, approved, rejected, completed, failed, rolled back | Engineering leads, SREs, release managers |
One detail that matters more than it looks: when someone replies to a comment or gets mentioned on a service desk ticket, that notification goes to the Service Desk Slack channel — not the PM channel. The same event type (COMMENT_REPLY) routes to a different channel depending on what it belongs to. A comment on a task goes to #pm-alerts. A comment on a ticket goes to #support-alerts. A comment on a change request goes to #change-alerts. This means your support agents see discussions about their tickets in their channel, not buried in a channel they rarely open.
Channel posts keep the team informed. Direct messages make sure the individual who needs to act actually sees the notification. Decuga looks up each notification recipient's email address in your Slack workspace and sends them a personalised DM alongside the channel post. If Alice assigns a task to Bob, Bob gets a DM: "Hey Bob, Alice just assigned something to you." It appears in Bob's Slack DMs, which most people keep far more clear than shared channels. If Bob is not in your Slack workspace, the DM is silently skipped — the channel post still fires and in-app notification is always created regardless.
Who gets the DM?
The DM goes to the notification recipient — the person the event is about. Task assigned → the assignee gets a DM. Change approved → the change request creator gets a DM. The actor (the person who took the action) never gets a DM for their own actions, and self-notifications are suppressed entirely.
The setup takes about ten minutes and requires no developer involvement.
Create the Slack app from the Decuga manifest
Go to api.slack.com/apps → Create New App → From an app manifest. Paste the Decuga manifest JSON (found in the Slack connector docs). This creates a bot with exactly the six OAuth scopes needed — no more, no less.
Install the app and copy the Bot OAuth Token
Install App → Install to Workspace → approve permissions. Copy the Bot User OAuth Token (starts with xoxb-). This single token is all Decuga needs.
Connect in Decuga
Settings → Integrations → Connect on the Slack card. Paste the token. Done — the connector is active immediately.
Assign a channel to each category
Click Configure on the Slack card. Three dropdowns appear, populated from your workspace channels. Pick one channel per category. Channels you haven't created yet won't appear — create them in Slack first, invite @Decuga, then reopen Configure.
A few conventions that work well in practice: name the channels clearly and consistently (#decuga-pm, #decuga-support, #decuga-changes), set them to private so non-relevant teams are not distracted, and invite only the people who need the alerts. The Decuga bot must be a member of each channel to post — use /invite @Decuga inside each channel after creating it. If you later rename a channel in Slack, nothing breaks; Decuga stores the channel ID (e.g. C0123456789), not the name, so renames are transparent.
Invite the bot before configuring
The channel dropdown in Decuga only shows channels the bot has access to. Create the channels in Slack, run /invite @Decuga inside each one, and then open Configure in Decuga — the channels will appear in the dropdowns.
Once the three channels are wired up, the flow becomes invisible in the best way. A product manager creates a task and assigns it to a developer. The developer gets a Slack DM and sees a message in #decuga-pm. A customer submits a support ticket. The assigned agent gets a DM and #decuga-support shows the new ticket. An engineer submits a change request. The reviewer sees it in #decuga-changes and gets a DM. When the reviewer approves it, the engineer gets a DM confirming the change is approved — without logging into Decuga, without refreshing a dashboard, without checking email.
Ready to try Decuga?
Start free — no account or credit card required. One month free trial of the Starter plan.
Start free trial