BLOGS
Codebeamer Streams: What They Are and When You Need Them
Managing a single product in a single version is straightforward. Managing several variants of that product — each at a different stage of development, each with its own set of requirements, test cases, and risks — is where most ALM setups start to crack. Codebeamer streams were introduced precisely to solve this problem. This article explains what streams are, how they work, and when they make sense for your team.
The problem streams are designed to solve
Imagine you are developing an embedded control system for an automotive supplier. You have a production-ready version being maintained for existing customers, a new platform release in active development, and an early-stage regional variant being scoped for a different market. Each of these has its own requirements documents, test specifications, and risk analyses — but they also share a large body of common artifacts that should stay consistent across all three.
Without a mechanism to manage this, teams typically resort to copying projects, duplicating trackers, or maintaining parallel branches that drift apart over time. Keeping track of which version of a requirement applies to which product becomes a manual coordination problem — and in regulated industries, that kind of ambiguity creates serious compliance risk.
Codebeamer streams address this by giving teams a structured way to manage concurrent development of multiple releases and variants within a single environment, without duplicating data.
REAL-WORLD SCENARIO: An automotive supplier running Codebeamer manages three active configurations of the same product: a production release under maintenance, a next-generation platform in development, and an early-stage variant scoped for a new market. Without streams, keeping requirements, test cases, and risk items consistent across all three means either duplicating entire projects or relying on manual coordination. Either way, when an auditor asks which version of a requirement applies to which product, nobody has a clean answer.
What a stream actually is
A stream in Codebeamer is a cross-project configuration layer. It selects a set of projects and, within those projects, determines which version of each item is visible and active. When you work inside a stream, you see the state of the product as defined by that stream — not a copy of the data, but a controlled view of it.
Every Codebeamer instance has one predefined stream called the Initial Stream, which contains all projects and all versions of every item. It is the baseline from which other streams are derived. When you create a new stream, you are essentially defining a lens through which a specific configuration of your product becomes visible and workable.
This matters because it means changes made in one stream do not automatically affect other streams. A requirement updated in your maintenance release stream stays independent from the same requirement in your platform development stream — until you deliberately merge the changes.
If you are familiar with working sets from earlier versions of Codebeamer, streams are their direct successor. The underlying logic is the same, but streams operate at a cross-project level and no longer rely on data duplication — making them significantly more scalable.
Branched and shared trackers
Not every tracker in a stream needs to behave the same way. Codebeamer distinguishes between two types.
Branched trackers
Maintain independent versions of their items across streams. A requirement in one stream can evolve differently from the same requirement in another. This is the right behaviour for artifacts that are expected to diverge — Requirements, Test Cases, Test Sets, and Risk items are branched by default, and for good reason.
Shared trackers
Contain items whose content is identical across all streams that include them. If you update an item in a shared tracker, that change is visible everywhere. This is appropriate for artifacts that serve as a reference across the whole product family — platform configuration items or common components, for example.
Getting this distinction right at the start of a project is one of the most consequential configuration decisions your team will make. It determines how much independence each stream has, and how much coordination is required when changes need to flow between them.
When streams make sense — and when they do not
Streams are genuinely useful when your team is managing more than one of the following simultaneously: concurrent development phases of the same product, multiple product variants or regional versions, a maintained legacy release alongside active new development, or feature branches that need to be isolated before integration.
In any of these scenarios, streams provide a clean separation between configurations without forcing you to maintain entirely separate projects. They keep traceability intact across variants, which is essential for standards like ISO 26262 or IEC 62304.
At the same time, streams are not the right tool for every situation. If your team manages a single product with a linear development history and no active variants, the additional configuration overhead is unlikely to pay off. The Initial Stream alone will serve you well, and introducing custom streams without a clear use case adds complexity without benefit.
The right question to ask is not “should we use streams?” but “do we have multiple concurrent configurations that need to stay independent while sharing a common foundation?” If the answer is yes, streams are the appropriate mechanism.
What comes next
Understanding streams as a concept is the foundation. The next level is knowing how to apply them — which use cases they are best suited for, how phased development and variant management look in practice, and where teams typically run into problems.
If you are evaluating how streams fit into your current Codebeamer environment, or planning a migration from an older version of the platform, the Arorian team is available to help you think it through.
FAQ
A stream in Codebeamer is a cross-project configuration layer that defines which version of each item is visible and active. It helps teams work with a specific product configuration without duplicating entire projects.
Streams are the successor to working sets in Codebeamer. They support a similar use case — managing concurrent product configurations — but are designed to work across projects and scale better in larger environments.
The Initial Stream is the predefined stream available in every Codebeamer instance. It is the default stream users work in unless additional streams are created.
Branched trackers can evolve independently across streams, so changes in one stream do not automatically affect another. Shared trackers remain the same across streams, so updates are visible everywhere.
Not necessarily. If you manage one product with a linear development history and no active variants, parallel releases, or maintenance branches, the Initial Stream may be enough.
You should consider streams when you manage multiple product variants, release branches, maintenance versions, or development phases in parallel. They are useful when configurations need to stay separate while still sharing a common foundation.
