Feature Requests

Description: Currently, the CircleCI Slack app only supports notifications for the default branch of a project. Teams frequently need visibility across more than one branch — for example, monitoring both main and a release branch, or a set of long-running feature branches. What we'd like: The ability to specify multiple branches (not just the default branch) when configuring Slack notifications at the project level in the CircleCI Slack app. Why it matters: Teams often have more than one branch that matters for operational visibility. Limiting notifications to a single default branch means teams either miss important failures on other key branches, or have to fall back to the Slack Orb with manual YAML configuration — which defeats the purpose of the no-config Slack app integration. Proposed solution: Allow users to enter one or more branch names (or branch patterns) when setting up project-level Slack notifications in the app. This could be a multi-value input field or support for wildcard/regex patterns.

We're launching CircleCI functions in beta, a new way to reuse config alongside orbs. Functions are versioned, tested programs that set up the tools your jobs need, like installing Node, configuring AWS, or setting up Docker. You and your coding agent can find, configure, and validate them before a pipeline runs. With functions you can: Use 10 CircleCI-maintained functions for Node, Python, Go, Ruby, Java, .NET, AWS, Docker, browser tools, and the GitHub CLI Catch version and input mistakes before your pipeline runs, with errors that tell you what’s wrong Get dependency caching built in, with no separate save and restore steps Getting started With your coding agent: Ask your agent to set up CircleCI with functions. It can use the CircleCI CLI (v1.3.0 or later) or connect through the CircleCI MCP server to find the right function, configure it, and validate your config before you push. With the CLI: Run circleci function list to browse the catalog, then circleci function add setup-node to add one to your config. In your config: Declare the function in a functions: block at the top of your config, then call it by name in any job. See the example in the docs . Functions are free on every plan, and your orbs remain fully supported. Browse every available function in the functions catalog . This is a beta feature, so we'd love your feedback on what's useful, what's missing, and how we can make it better. Drop your thoughts here!

Today, CircleCI Slack notifications only fire on workflow completed. For teams running long-running or scheduled pipelines, that leaves a lot of gaps in visibility. We'd love to see support for the following notification types: Workflow kickoff — notify when a pipeline starts, so teams know a build is in progress. Especially useful for long-running pipelines where silence can be ambiguous. Upcoming scheduled workflows — notify ahead of a scheduled workflow run as a heads-up that automation is about to trigger. Each of these should be individually toggleable so teams can subscribe to only what's relevant for them. Who this helps: Teams running nightly builds, release pipelines, or any workflow where knowing when something starts or is about to run matters as much as whether it passed or failed.

Currently, jobs, parameters and workflows support (or don't) different booleans and conditionals amongst themselves, requiring users to setup different logic instead of keeping things DRY and copying throughout the config file.

The auto scroll is nice for the steps viewer - except that if you try to scroll while it's auto scrolling, it fights you over and over again. Make the auto scroll faster and stop scrolling it if the user starts scrolling. It's incredibly annoying to try to scroll and have it scroll back like three times every time when I open the steps view

Add Google Cloud Storage (GCS) as a first-class destination for CircleCI Cloud audit log streaming (Scale plan), alongside Amazon S3 / S3-compatible destinations. Problem: Audit log streaming today targets AWS S3, or other S3-compatible endpoints that support OIDC with STS-style AssumeRoleWithWebIdentity. Many enterprise security teams run GCP-native SecOps (Chronicle, GCS-backed pipelines) and cannot assume that role flow against a plain GCS bucket. The documented workaround is to stream to S3 first, then forward (for example S3 → SQS → Google), which adds AWS cost, complexity, and a second cloud dependency for GCP-only customers. Use cases: GCP-centric orgs that want CircleCI audit events in GCS / Chronicle without an S3 hop Compliance teams that require audit data to land in a GCP-controlled bucket Reducing multi-cloud glue for customers already standardized on GCS Workarounds today: Stream to AWS S3 (or a true STS-compatible S3 API), then forward into GCP Manual / self-serve audit log requests from the UI (not continuous streaming)

Today a job can invoke an executor with arguments, for example executor: { name: win/default, shell: bash.exe }. Under top-level or orb executors:, you can only define a concrete environment (machine / docker / macos, optional shell, and so on) or a string rename of another executor. You cannot define a reusable executor that wraps an existing named executor and fixes some of its parameters. That means patterns like "Windows orb default image and size, but Bash as the default shell" cannot be packaged once for jobs and orb consumers. The supported workaround is to re-declare the underlying machine image, resource_class, and shell yourself in the project or orb, which duplicates the upstream executor and drifts when the upstream orb changes. Please support defining an executor as a reference to another executor plus parameter overrides, so the override is set once at definition time and inherited by every job that uses the new name.

I'm using a Microsoft Teams for Chat tool, so I want you to add Microsoft Teams for Chatroom Integrations. Could you consider about that? CCI-I-650

Currently, you can only re-run a job with SSH from within the UI. This feature request is for a button to re-run a job from within the UI.

pr_only_branch_overrides has to be updated per project and maintaining these lists can become burdensome. Having the list of branch overrides and the ability to add/remove from the list in the UI would help reduce confusion.