Feature Requests

Allow identity providers (IDPs) to proactively provision and deprovision users based on predefined role mappings. This will ensure new users have access and and retired users are promply removed.

Currently, we utilize holds on our workflows to require a pair of eyes to check on deployments heading to production. While a great feature, it is often unclear when jobs are stuck in a "hold" unless you're glued to the CircleCI console and are acutely aware that a build is being executed on a branch that even needs an approval. It would be very handy to receive notifications for workflows in a "hold" status, as well as to even approve them through Slack! CCI-I-1028

You are able to see all workflows/jobs for a given branch by going to https://circleci.com/gh/{org}/{project}/tree/{branch} such as https://circleci.com/gh/socialtables/ent-killer/tree/master It would be extremely useful to see a list of all tagged jobs/workflows for all tags. We use tags to trigger staging/production builds and have no way of visualizing a record of all workflows/jobs of this type. Added filtering to be able to get workflows that have done a certain step would also be very useful. For us, viewing all workflows that have succeeded job deploy-production would allow us to fully use Circle to manage deploys. CCI-I-621

The current Month-to-Month Performance plan is designed to keep builds running by automatically purchasin credits when included credits are exhausted. While this helps avoid interruptions to CI/CD workflows, some customers would like additional controls to manage their spending. Customers with fixed budgets or internal spending policies have expressed that they would like more visibility and control over monthly costs, rather than relying solely on usage monitoring.

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.

At the moment, create a new git-branch in Bitbucket is triggering automatic Circle-CI build although no commit have been pushed to this branch yet. This resulting in a redundant build and in-case your pipeline resides on commit-it it might override resources using this commit-it. CCI-I-684

There are cases where jobs grouped together still need a level of parameterization like if a subset of jobs are used for deployment of environments. At the moment this is not possible creating the need to duplicate job groups per environment. On another note, the naming of job group wrappers in the console is both noisy and not aligned with named job groups in the config. For example job-start-1 and job-end-1 instead of something like my-group-name as an accordion block of the indented jobs contained within. As soon as you have more than one separate job group, you end up with many of these wrapper blockers littered throughout making the set of jobs less readable in the console.

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.

Summarized from https://discuss.circleci.com/t/organization-wide-webhooks/2200 : Currently we are setting the same webhook for many projects. It would be handy to have an option for organization-wide webhooks, that is, webhook notifications that apply to every project of the organization. As an example we currently set the exact same Slack hook for every project, and it is very easy to forget doing that when adding new projects. GitHub introduced the exact same feature a while ago and it’s been an incredible help for us. CCI-I-568

Currently they show up as errors and make it more difficult to see the actual problems. They don't fail the build but are mixed in the error reporting CCI-I-546