Feature Requests

As it stands today, users and orgs simultaneously using Github OAuth and Github App cannot rename or delete a Github OAuth pipeline. This can lead to confusion when duplicating an OAuth pipeline to GH App as the names will be the same with no distinction in the UI. You can only delete the OAuth trigger under project settings: https://circleci.com/docs/guides/integration/using-the-circleci-github-app-in-an-oauth-org/#authorization-steps

Currently, approving an approval type job requires two clicks from the workflow page: one to go to the job details and one to approve it. Since the details of the job are just the two buttons to approve or cancel, consider displaying them directly in the workflow job popover in the workflow page.

The workflow you see on a CI branch is often not the same as the workflow on main , since CI will be running pre-flight checks and main will publish artefacts and deploy services. This can discourage folks from editing config, because you don't get confirmation of what the workflow looks like on main until after you merge. It's difficult to visualise what the resulting workflow graph looks like, especially when jobs in the workflow uses a mix of positive and negative branch filters. It would be useful if the circleci-cli could display a graph of the resulting workflow(s) on any branch they request, so they can have more confidence that they have wired up things correctly.

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.

Enabling CircleCI Organization admins to self-serve concurrency limit adjustments would be a valuable feature. It would allow customers to request limit increases (within an allowed threshold) directly within the CircleCI app. This capability could also serve as a natural follow-up action when admins are notified that jobs are being queued due to concurrency limits --> ( https://circleci.canny.io/cloud-feature-requests/p/notification-when-jobs-are-queued-due-to-hitting-concurrency-limits )

I don't know who, though making near invisible lines for the pipelines and mixing them up so we cant tell which lines goes where was a good idea? Seriously its really really bad. I feel like a detective with a magnifing glass looking for clues. Change your algoritm that builds the pipeline visually and also make the UI better and more structured.

Currently, when a user hits their concurrency limits there is no error message. They will see their builds queueing. The user can use the CircleCI v3 API to get unclaimed tasks for a given resource class( https://circleci.com/docs/runner-api/#get-api-v3-tasks ) to confirm that they have unclaimed tasks. At this time, user rely on CircleCI Support team to share a list of jobs that need to be cancelled. This feature request is for better error messaging when concurrency limits are hit and for exposure to which jobs need to be cancelled in order to move forward.

I can't see our firebase build numbers in the new beta UI

Desired State: users of CircleCI are able to identify how many jobs are currently running. Current State: users of CircleCI are not able to identify how many jobs are currently running and must email an account manager for this information. Impact: this prevents users from easily identifying the time period when jobs are being queued and prevents paid users from being able to verify if their jobs should be queued.