Originally published: October 3rd, 2025

We will be making some updates that will change the core ways of creating, running, and managing streams in Usage Engine Cloud Edition. While these new changes are not in effect yet, we are sharing this information ahead of time to ensure your team is prepared and acquainted with the new process to come. To help you navigate this transition, we have prepared the following information on what you need to know.

Currently, the plans are that these changes will be released on Monday the 27th of October 2025.

With the introduction of Version tagsPreview onto streams, you will be able to tag a stream with different versions and run each version from the Version history panel in the stream editor.

We are also going to extend the benefits of version tagging to the scheduling of single streams and stream groups.

When scheduling a single stream, autosaved streams will no longer be allowed to be scheduled. This means that you have to tag streams before you can schedule them.

This will also apply when scheduling a stream group. All streams in the group have to be version tagged, as autosaved streams will no longer be allowed to be scheduled. However, we will still allow running a stream group manually if the streams are untagged. Streams that are untagged will be indicated with a ‘Latest’ tag on the latest version of the stream.

Once a stream or stream group has been scheduled, it cannot be run manually to ensure consistency between streams that are scheduled and those that are run manually.

As part of this transition, Usage Engine will tag all currently scheduled streams and stream groups with an auto-generated placeholder tag to ensure backwards compatibility.

This update is not meant to disrupt your existing scheduled streams and stream groups, it will only affect how you schedule or update streams moving forward to ease and enhance your current ways of working with your streams. Therefore, there is no immediate action required, except that you will notice new ways of tagging your streams and how you schedule your streams.

Conceptually, you may think of version tagging as versioning a stream, and the new scheduling behavior for streams and stream groups as deploying them. This creates a clear separation of concerns when you are creating a stream and running it in your solution, which will make it easier to troubleshoot when a stream cannot be scheduled.

By leveraging on version tagging, the key benefit of this change is the ability to maintain more than one version of a stream, and the flexibility to run or schedule whichever version of the stream you want. This not only creates space for safer experimentation and upgrading of your streams, but also provides security to schedule an older version of a stream or stream group should anything go wrong with the latest versions that you are using.

We will also ensure that for improved traceability and auditing, version tags of all scheduled streams that were executed will be recorded in logs and audits.

Let us know how you like these improvements! Please share your feedback by using the Feedback button in Usage Engine Cloud Edition.

Here are some overview sneak peeks into what you can expect to see once the changes have been released.

In the stream editor, you will be able to run any tagged version of a stream from the version history.

Open

When scheduling a stream, you must select a tagged version of a stream.

Open

You will not be able to schedule a stream if it does not have a tagged version.

Open

When creating or editing a stream group, you must select a version of each stream, or “Latest”. “Latest” can be convenient when manually starting stream groups during testing, as it automatically executes the latest version in the stream editor version history, tagged or not.

Open

When scheduling a stream group, all selected versions must be tagged, or you will not be able to schedule the stream group.

Open

Yes. Since only tagged versions can be scheduled, you should edit a stream and tag it, then schedule the new tagged version.

Every scheduled execution should have a tagged version in the logs and audit for traceability and auditability. You may think of scheduling as a deployment of a new stream version. Tagging a version of a stream is a separate step before deploying the version.

However, you can still use the placeholder ‘Latest’ tagged version to run unscheduled stream groups during stream development and testing.

Yes. Change the scheduled version (for individual streams) or stream group versions (for stream groups) to an older tagged version you want to roll back to. The next scheduled execution will use the older versions.

You can also manually start older stream versions from the version history in the stream editor if the stream is not scheduled and not part of a group.

No. The change is backward compatible, and you do not need to take any immediate action before or after the release. All you need to do is be aware that after this release, the way you work with scheduling and versions will change to only allow tagged versions.

They will remain the same. Each scheduled stream that didn’t already have a version tag will automatically be given an “auto-migrated” version tag during the release migration. You may notice the “auto-migrated” version tag in stream logs and audit if the stream stream scheduler executes the stream, but the scheduled stream behavior will not change. From then on, you can create new tagged stream versions and schedule those.

No. This is to avoid the risk of race conditions and inconsistencies from multiple instances of the same stream, potentially with different versions, running at the same time.

Yes, but you can only run the exact same version as the scheduled version. This is to avoid the risk of race conditions and inconsistencies from multiple instances of the same stream, potentially with different versions, running at the same time.

Yes. The versions configured in the stream group will be executed.

Yes. Open the stream’s version history in the stream editor. You will be able to start any tagged version from there. This will not be allowed if the stream is scheduled or part of a stream group. Note that running a stream version manually will update the Deployed column with the executed version.

The latest stream version will be executed. If a stream is scheduled, the Start action changes to “Start scheduled”, and will execute the scheduled version. The Start action will be disabled if the stream is part of a stream group. There is no way to start any other versions from the stream list.

The versions in the stream group will be executed.

This is not supported. Resume only works for the versions that were in effect when the stream group failed partway through. Editing the stream group will reset the Resume counter, and the next execution will start from the first stream in the group.

However, if the version that was selected for a stream is the latest, and the stream was updated, resuming will use the updated stream.

Yes. You can open the schedule (for an individual stream) or stream group to see which version the stream will be running. You will also be able to see the scheduled versions in the streams list and the stream groups list, in the new ‘Deployed’ column. Finally, in the version history list in the stream editor, there will be a ‘Scheduled’ tag if a version is scheduled or part of a scheduled stream group.

No, but you can export them and import them as a separate stream if you need to view them.

No. We suggest you use an external tool to compare tagged stream versions if you need to do this.

No. If a stream is scheduled, you can only manually run the same version as the scheduled one. You will notice that the “Start” action will change to “Start scheduled” for scheduled streams.

No. Only tagged stream versions can be scheduled.

This is to prevent inconsistencies if a scheduled execution happens while the stream group is being edited.

It can mean either 1) This stream has never been executed or scheduled or been part of a group, or 2) The last time it was manually started using the Start action, an Autosaved version was executed.

No. There is only a single version of data stored for a stream, no matter how many stream versions you have. It is up to you to make sure the new stream version can read any persistent data the stream has stored in a previous version.