<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=207541) </details> <!--IssueSummary end--> ### Problem to solve The configuration for slack notifications lacks the ability to dynamically route to channels based on details of the trigger. For example, when a notification is triggered on a merge of a branch, depending on the name of the branch, I might want to notify a different slack channel. i.e. **feature/search** branch might only need to notify `#search-team` **feature/inventory** branch might only want to notify `#inventory-changes` ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. * [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ --> ### Further details **Cross functional teams** Cross functional teams often use a single slack channel. We want the ability to notify when an update has been released to everybody involved in that channel. **Reduced noise** Right now, we only have capability for a single repository to notify on everybody contributing to that repository. With a repository that has a lot of contributors, this is very noisy. Much easier to be able to route changes to where it makes sense. <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> ### Proposal A *potential* path to providing this capability would involve the following 1. **Allow Multiple Trigger Configurations** Based on the next bullet point, if we had more granular control of how we could configure triggers, then we would need the ability to specify more than one of these. 2. **Add Qualification/Matching on Trigger Criteria** This could be in the form of a regex potentially. Ultimately, when evaluated, if the criteria evaluates to true, that configuration can be used. i.e. A **search** team might have it's own configuration for the `Deployment` trigger that matches on `feature/search` whereas the **inventory** team might use the criteria `feature/inventory`. Both pointing at respective channels. ### Permissions and Security Should be consistent with existing permissions. ### Documentation * Update Docs ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> ### What does success look like, and how can we measure that? **Acceptance Criteria** * A user can route a slack notification to a specific channel based on basic details available. Included, but not limited to branch name, repo name, trigger name. **Success Metrics** * General increase in the use of slack notifications. Right now, it likely is limiting the use of this because of the inability to segment on notification triggers. ### What is the type of buyer? Members of a cross-functional team? ### Customer Impact - [Ultimate, SaaS, 140 seats](https://gitlab.my.salesforce.com/0016100001beDS0)