Update: We've decided to plan for removal in 18.0, instead of 17.0 https://gitlab.com/gitlab-org/gitlab/-/issues/435906+. ### :no_entry_sign: Blocking issues Note we can only remove the integration when customers can use the following features that are available for our Slack notifications integration with no equivalent in the GitLab for Slack app today: - Instance/group level administration https://gitlab.com/gitlab-org/gitlab/-/issues/391526+ - Support for multiple workspaces https://gitlab.com/gitlab-org/gitlab/-/issues/424190+ - We need to allow people to easily migrate their existing settings from the Slack notifications integration to the GitLab for Slack app integration https://gitlab.com/gitlab-org/gitlab/-/issues/372412+. ### ℹ️ Background As a follow-on of https://gitlab.com/groups/gitlab-org/-/epics/8670+ and https://gitlab.com/groups/gitlab-org/-/epics/1211+ and the deprecation of the Slack Notifications integration, this epic will focus on the removal of the legacy integration. This would be necessary if Slack put a date on the removal of the [webhook functionality](https://api.slack.com/legacy/custom-integrations/messaging/webhooks) that underpins how the old integration performs the notifications, as it would no longer work! That page is still just flagging Slack webhooks as to be deprecated, and *possibly removed in future* at this point. No date or timeframe is given. We might want to go to this phase before we're forced to by Slack if we wanted to clean up the code. 1. **Active messaging** as per Katie's designs (messages posted to Slack channels, emails). 1. **Remove** the old integration. > I think the key case is that today users can specify labels that filter notifications for all triggers. You can't customize this per trigger (e.g. for MRs only notify me when label = "Ready for Development", but for Issues only notify me when label = "type::feature"). I'm thinking with a migration workflow, if day one we don't support labels per trigger, but add it in the future, it means modifying the dependency on the migration workflow as well. I'm thinking we could aim to add these new features to all "notifications" integrations as we add them to the Slack integration. The list of these integrations is https://gitlab.com/gitlab-org/gitlab/-/issues/335673#note_1041317426. They all share much of the same underlying code (both backend and frontend) and so this would actually be simpler for engineers. In this case, the "migration workflow" is always a simple "copy and paste" of the settings on the backend from the old integration to the new integration, as they both have total feature parity. See https://gitlab.com/gitlab-org/gitlab/-/issues/335673/#note_1068327289 for more context. ### :date: Removal date We're currently documenting that removal will happen in %"18.0", but this should only happen once the above blocking issues have been completed (and, completed with a reasonable amount of time for people to make use of them in order to assist their migration to the GitLab for Slack app). Otherwise, the removal would need to be bumped back to a later major milestone. ### :no_entry: Do not delete customer data We do not want to delete customer data in the `integrations` table for the Slack Notifications integration as we want to allow customers to migration their data to the GitLab for Slack app integration https://gitlab.com/gitlab-org/gitlab/-/issues/372412. This means the removal of the Slack Notifications integration will not involve deleting data. We may remove the model for the integration so long as we provide some tool that can run on any GitLab instance that would continue to migrate their data.