Feature Requests

The current native Slack integration enforces a hard 1:1 constraint — one Slack workspace can only be connected to one CircleCI organization at a time. For enterprise customers, this is a significant blocker. Many enterprise organizations authenticate via GitHub and operate across multiple distinct CircleCI organizations to manage separate business units, product teams, or subsidiaries — all while routing into a single corporate Slack workspace. The ask: Allow a single Slack workspace to receive notifications and interact with multiple CircleCI organizations simultaneously.

Add a notification trigger that fires when a build passes for the first time after a failure. Currently users can filter to failed-only notifications, but there's no recovery signal — leaving engineers to manually check CircleCI to know when a pipeline is healthy again. Customer evidence: A beta native Slack integration user specifically requested this as a complement to failed-only filtering — they want the failure-to-recovery loop closed without switching back to "all notifications" mode. Expected outcome: Allow users to opt-in to be notified when a pipeline recovers, reducing manual monitoring toil and completing the failure response workflow entirely within Slack.

Allow users to configure which details are included in native Slack failure notifications. Teams have different signal-to-noise preferences — some want full context, others want lean, scannable alerts. Initial fields to consider toggling on/off: * Commit message * Branch name * Triggered-by user * PR link Customer evidence: A beta user with a high-volume monorepo specifically requested the ability to hide commit messages for better information density. This is a broader pattern — teams migrating from legacy Slack integrations have often already tuned their notifications, and customization parity is a key adoption driver. Expected outcome: Users can tailor notification content to avoid information overload while ensuring the details most relevant to their workflow are always surfaced — leading to notifications that are actually read and acted on, rather than missed, dismissed or muted.

If "Auto-cancel redundant workflows" is enabled, it should also apply to PRs/branches that get merged into master. There's no use finishing a build for a PR that just got merged into master, because it's going to get built there too.

Currently, only org admins can manage runner resource classes. This blocks the onboarding of new runners onto CircleCI due to the escalated privileges required.

I'm interested to know how often people in our organization are having to rerun jobs when a flaky test fails on their branch. Who performed the rerun, when was it done, which repo, which branch, which job, which test failed, etc.

Gen2 resources are available for Docker and Machine x86 executors, but not yet available for ARM executors

Today only actor values are captured in audit logs. It would be useful to link personal access tokens to the users that created them, and track usage from these tokens for auditing purposes. Currently, there is no way to track what user has used ssh-rerun on the platform (if accessed by PAT token); if a user account is compromised, audit logs will not surface what user initiated the rerun or what they did with it.

I would like to have native support for setting up OIDC with Azure, similar to what we have for AWS. This would help us in expanding our multi-cloud setup and streamline our authentication processes.

Feature request: Organization-level API token. Use case and workaround:We use Terraform provider to interact with the CircleCI API, and since CircleCI supports personal and project-level API tokens (but not organization-level API tokens), the current workaround involves service user which generates an API token, which is suboptimal. CCI-I-1546