Feature Requests

When a CircleCI workflow kicks off async work — an external service, another pipeline, or any long-running process — there's no native way to get results back into the workflow and act on them. The only signal a workflow can receive today is a binary approve/reject on a hold job, with no data attached. This means you can't pass results back in, you can't make decisions based on what happened, and if you poll for a response you're burning credits on idle compute. Examples of where this comes up: security scans where you need to route based on severity rather than just pass/fail, ML model training that returns governance metrics and artifact locations, infrastructure provisioning where you need status before proceeding, and pipelines triggering other pipelines where context needs to carry back. Customers today work around this by building callback Lambdas, persisting results to external stores, and writing retrieval logic in downstream jobs — custom glue infrastructure that shouldn't be necessary. We'd love to hear from you on your use cases where you ran into this challenge: What async work are your pipelines waiting on? How are you getting results back into your workflow today? What decisions do your pipelines need to make based on those results? What workarounds have you had to build?

Summary Allow users to define and use custom, arbitrary labels when triggering CircleCI pipelines, beyond the current fixed set of standard labels (e.g., ci). Problem Statement Currently, pipeline trigger labels are limited to a predefined set of options. This restricts teams from implementing more granular or context-specific trigger logic, making it difficult to configure pipelines that behave differently based on custom conditions or workflows. Proposed Solution Enable users to define and pass arbitrary string labels when triggering a pipeline — either via the UI, API, or configuration file. These custom labels could then be used as conditions within pipeline configurations to control which jobs or workflows are executed. Example Use Cases Triggering a specific subset of jobs based on the type of change (e.g., hotfix, release-candidate, infra-only) Differentiating between automated triggers and manual triggers using custom identifiers Supporting complex branching strategies where different pipeline behaviors are needed for the same branch Expected Benefit Greater flexibility in pipeline configuration, enabling teams to implement more sophisticated CI/CD workflows without workarounds, and reducing the need for separate pipeline definitions to handle different trigger scenarios.

As part of the new CircleCI Slack integration, users need the ability to route different types of notifications from the same project to different Slack channels — for example, sending build notifications to one channel and chunk notifications to another. Problem Statement: The new Slack integration currently supports a single Slack channel per project for notifications. This creates friction in two distinct scenarios: Notification type separation — Teams want different notification categories (builds, chunks, etc.) to go to different channels for better signal-to-noise management. Cross-team pipeline ownership — When Team A owns a pipeline definition but Team B's work triggers failures in it, Team B currently has no way to route those failure notifications to their own channel. The only workaround is to make the pipeline never fail and post to Slack manually — which completely defeats the purpose of automated notifications. Proposed Solution: Within the new Slack integration, allow users to configure multiple Slack channel destinations per project, with the ability to filter/route by notification type (build, chunk, failure, success, etc.) and/or by pipeline definition. User Stories: As a platform engineer, I want build notifications and chunk notifications to go to separate channels so each team stays focused on relevant alerts. As a downstream team, I want pipeline failure notifications routed to my channel even when I don't own the pipeline definition, so I can act on failures that affect my work without relying on the pipeline-owning team.

Similar to how job definitions can be reused for different environments or criteria, parameters would allow us to reuse job groupings for different environments, configurations, etc. In our use case we do the same kind of deployments across different envs that use different auth. The same set of jobs are used but with different inputs for env, aws profile, etc. If job groups could be parameterized, we could do something like this: # workflows dev-workflow: jobs: - deploy-group: env: dev stage-workflow: jobs: - deploy-group: env: stage prod-workflow: jobs: - deploy-group: env: prod # serial group deploy-group: parameters: env: type: string jobs: - start-release: env: <<parameters.env>> - deploy-release: env: <<parameters.env>> - finalize-release: env: <<parameters.env>>

There are a couple different paths for a user to view a soft or hard fail config policy decision associated with their pipeline, some requiring the user to be admin, but the user is alerted only when the pipeline is hard failed. It would be helpful if the decision output was more easily surfaced locally. Hard failures are surfaced via the Pipeline API. Soft failures are only present in the UI for a non-admin user. A slack notification, something on the PR, adding soft failures to the API, etc would be helpful to surface policy decisions to the user.

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.

Problem Today, CPU and RAM utilization data for individual jobs is only visible in the "Resources" tab of the job UI. There is no public API endpoint that exposes this data programmatically. The closest alternative — the Usage Export API — returns a full org-level CSV dump with no way to filter by project, branch, or pipeline ID. For teams that want to automate resource analysis (e.g. comparing resource consumption between a feature branch and main ), this means pulling and processing a large dataset for the entire organization just to get data on a small subset of jobs. --- Requested changes Expose per-job CPU/RAM usage via a public API endpoint — make the data powering the job "Resources" tab accessible programmatically, scoped to a single job ID. Add filtering to the Usage Export API — allow the org-level usage export to be filtered by one or more of: project_id , branch , pipeline_id , workflow_id , or job_name . This would make the API usable for targeted analysis without requiring consumers to download and process the full org dataset. --- Use case Engineering teams want to automate resource rightsizing — comparing CPU/RAM utilization of jobs on a feature branch versus the default branch to identify over-provisioned resource classes before merging. This is currently impossible without either scraping the UI or processing a full org-level export. --- Impact Enables automated resource optimization workflows and cost analysis scripts Reduces unnecessary data transfer for customers with large orgs who only need project- or branch-scoped data Unlocks use cases like pre-merge resource regression detection and per-team cost attribution

Currently, CircleCI Slack notifications are routed to a single channel configured at the project level. For teams working in monorepos — where many services or jobs live within a single project — there's no way to send notifications to the right team's channel based on which job or service actually failed. The ask: Allow customers to define a mapping from job name (or service name) to a Slack channel, so notifications are automatically routed to the appropriate channel for each job. Proposed mechanism : Support a YAML configuration file checked into the repo that maps job names to Slack channel IDs. Teams with monorepos could code-generate this file from their internal service registry, keeping it in sync automatically. For example: notifications: slack: routing: - job: build-payments-service channel: C012ABC - job: build-auth-service channel: C034DEF Alternatively, users can dynamically map job names to Slack channels using an API. Why it matters: Without this, all failure notifications for a large monorepo go to a single shared channel, creating noise for teams that aren't responsible for the failure. This is a meaningful barrier to adoption for engineering orgs with 10+ services in a single repo.

Currently no notification is sent to notify of a Scheduled Pipeline failing to trigger. A notification or email should be sent to notify the user/admin that this has occurred so that it can be addressed.

The use here is that we may have a workflow that has several manual approvals in parallel all requiring approval (e.g. deployments to multiple regions at once) It would be great to be able to have an "Approve All" button that, when all jobs in a workflow are waiting for approval, approves all outstanding manual approvals