Clone a release or schedule

Note: Depending on your workspace type, this article may refer to Aha! record types differently than your team does. 

There are a couple of common use cases for cloning a release. The most common is when your core team and services centric where a release template containing established best-practice release phases, milestones, work tasks and deliverables is created for cloning new releases. These are largely focused on go-to-market related tasks. The second use case is for independent release cycles for different platforms (e.g. iOS and Android) where the feature set is essentially the same.   

Click any of the following links to skip ahead: 

Build the release template

The precursor for cloning is the creation of a release that will function as a release template. Build out the release with the required phases, milestones, features, dependencies, and to-dos based on the corporate gold standard. Where you choose to create and store these release templates will depend on the level of standardization across the portfolio of workspaces.


If your release templates are the same and you also have the same custom fields and workflows (status and type)* across the portfolio of workspaces, set up a template workspace to serve as the container for creating and storing your release templates. This keeps things clean where release templates are easy to find and are separated from the real releases. It also allows for setting user permissions to control who can modify the templates. 

If you have different release templates across workspaces while custom fields and workflows also vary, create your release templates for each workspace, including any phases, milestones, dependencies and to-dos. Then move it to the Feature Board parking lot by adding the 'Parking lot' attribute under the Actions menu. This allows you to easily hide the template from your board view when you do not need it and prevents the template from showing up as a scheduled release. 


Release work tasks

The repeatable work tasks for a release are modeled as either features or to-dos. To-dos work well for lightweight project management tasks where the status is either pending or complete. Features are the better solution when more advanced workflow and status information is required for project tracking and reporting.

When using features in this fashion, it is recommended that you add a new feature type to help distinguish between work task features and development related features. This is beneficial for filtering your views and reports to best communicate status information by feature type depending on the targeted stakeholders.

When cloning the release, any to-dos belonging to copied features will also be copied. Included will be the to-do name, description, assignee and attachments. Due dates, status, and comments will be removed.

Create the release clone

Start by creating the new release by clicking the blue "+New Release" button. In the release dialogue box, assign a name to the new release and choose either create new release or copy existing release. When you select copy existing release, you will be prompted to select the release you wish to copy from across all workspaces that you have access to. 


Once you copy and create the release, it is added to the feature board. If the original template was saved as a parking lot, you will need to edit the copied release to remove the parking lot attribute. Upon doing so, the newly created release with phases, milestones, and dependencies will also be viewable within the Release Roadmap view.

Important notes

As long as custom fields are the same and both feature and release workflows are the same across the portfolio of workspaces, custom field values and workflow information will also be included as part of the copy. If they are not the same, the copy will still be performed. However, custom field values and workflow status information will not be copied from the release template to the new release. 

Note: In some instances, you may wish to create release phase and milestone templates devoid of features or to-dos.  Examples include releases where the commonality is at a project phase and milestone level but not at the work task level or for organizations that have not yet defined a standard set of work tasks for releases. This is a different approach than cloning releases. 

Was this article helpful?
5 out of 6 found this helpful