Packages View

Overview

This page describes what you can do in the Packages view in Appian Designer.

To access this view, click Packages in the navigation pane at the environment level or within an application.

When you access this view at the environment level, it displays all packages and releases across all applications in the current environment. When you access this view from within an application, it displays only the packages for that specific application.

Purpose

From the Packages view, you can view and manage packages and releases. This view allows you to view packages across multiple applications, organize packages using releases, and deploy packages. This view is also a great place for development leads and deployment managers to search, filter, and perform bulk actions on packages to streamline your deployment workflow.

What are packages and releases?

• Packages: A set of application changes that a developer can deploy to another environment.
• Releases: A way to group and manage packages of related functionality across applications.

Elements of the Packages view

You can access the Packages view from within an application or for the entire environment. The actions and elements of the view are the same regardless of where you access it from.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

#	Element	Available Actions
1	Header bar	Learn more about the header bar.
2	Navigation pane	Learn more about the navigation pane.
3	Filter pane	Search and filter for packages in the list.
4	Toolbar	Compare and deploy packages. Export packages. Change the release associated with a package. Add contents to packages. Delete packages.
5	Packages list	View the packages in the list.
6	Manage Releases	From the Manage Releases dialog, you can create, view, edit, and delete releases.

View the packages list

To view the packages list, click Packages in the navigation pane.

The packages list displays information about all packages you have access to view. For each package in the list, you'll see the following columns and information:

Column	Description
Name	The name of the package. At the environment level, this column also shows the name of the application the package is in.
Description	The description of the package.
Release	The release that the package is associated with, if any.
Ticket	A link to the external project management ticket associated with the package.
Last Modified On	The date and time when the package was last modified, as well as the user who modified it.

By default, the packages list is sorted by the Last Modified On column in descending order. To sort by any column, click the column heading.

You must have at least Viewer permissions to an application to view its packages. System administrators can view all packages in the environment.

In the packages list, there may be an icon next to the package name for some packages. This is a release overlap alert and indicates that those packages contain objects associated with other active releases. To learn more, see the release overlap alert section.

Search and filters in the packages list

You can search through and filter the packages list to help you find the information you need.

To search the packages list, enter the package name or description in the search box in the filter pane. You can also search by ticket URL to find packages associated with specific project management tickets.

The powerful filters help you quickly identify a set of packages that you want to take action on. You can use the Release to filter find all the packages in a given release in order to export or deploy them. And the Objects filter allows you to instantly find all packages that include a specific object—whether you're tracking down changes related to a bug or confirming which package contained updates to a particular object.

In the filter pane, use the following filters:

• Application: Filter by one or more applications. This filter is only available in the environment level.
• Release: Filter by a release to see all packages associated with that release.
• Objects: Filter by objects in the package.
• Last Modified By: Filter by the user who last modified the package.
• Last Modified On: Filter by the date when the package was last modified. This filter returns packages that were last updated on or after the FROM date, and all that were last updated on or before the TO date.

To clear all filters, click Reset in the filter pane.

Manage packages

In the Packages view, you can take multiple actions related to packages, such as:

Action	Location
Create packages	Only available at the application level.
Associate packages with a release	Available at both application and package level.
Export packages	Available at both application and package level.
Compare and deploy packages	Available at both application and package level.
Add contents to a package	Only available at the application level.
Delete packages	Available at both application and package level.

When you open a specific package, the package will open in a new tab where you can take more actions related to that package, such as:

• Edit a package.
• Review package contents.
• Share a package.
• Modify package objects.
• Add application configurations.

Review release overlap alerts on packages

When teams work in the same application or environment, multiple developers may modify the same design objects for different purposes and their changes may be intended for deployment at different times. Having visibility into these overlapping changes is critical to avoid deploying in-progress work.

The Packages view provides visibility by displaying a release overlap alert next to the package name when a package contains objects associated with more than one active release. Open the package to see which objects overlap and investigate further to decide if you can go ahead with deployment.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Use the following guidance to help you decide if you can move forward with deployment:

1. Review the changes in the object associated with multiple active releases.
2. Talk to the developer who owns the other package.
3. Check to see if their changes can be safely deployed in your release.
4. If their changes aren't safe to deploy with your release, consider reverting to a previous version of the object to ensure a safe deployment. The other developer can then restore their changes by restoring their object's version.

As long as the object is still in packages associated with different releases, the release overlap alert will still show in the packages list. But if you have followed the above guidance, you should be able to deploy safely.

Once you've successfully deployed and are no longer using the release, mark the release as inactive. Inactive releases are excluded from release overlap alerts.

To learn about how permissions impact release overlap alerts, see Security and release overlap alerts.

Deploy packages from the Packages view

You can deploy packages directly from the Packages view at both the environment and application level using direct and manual deployments. But there are slight differences between the deployment experiences in the environment and application levels.

From the Packages view for the entire environment, you can deploy multiple packages from multiple applications in one deployment. From the Packages view for a single application, you can deploy multiple packages from the that application within the same deployment.

There are some variations in deployment actions available depending on the number of packages selected from each application.

Releases

You can create and manage releases directly from the Packages view at the environment level.

A release is a way to group packages of related functionality to deploy at the same time. Releases can help you to organize changes, manage overlapping work across teams, and coordinate deployments.

You can associate packages with a release and set a target release date. This helps you to get started organizing related functionality at the beginning of your development lifecycle.

Why use releases

Releases help you organize your changes from the beginning of your development lifecycle by enabling you to associate multiple packages with a release. Releases provide information, like if they are active/inactive and a target release date, that help you better understand which packages are actively being worked on and when they are expected to be released to users. This especially helps deployment managers manage larger sets of changes for deployment.

Releases provide developers with real-time visibility into overlapping work across teams. If the same object is included in packages associated with multiple active releases, both packages will be flagged. This way, you can make sure no in-progress changes are deployed with either release.

Key benefits of releases:

• Group related packages for coordinated deployment.
• Track target release dates for better planning.
• Filter and search packages by release.
• Streamline deployment workflows.
• Help identify overlapping in-progress work.

Create a release

You can create a new release from the Packages view at the environment level in multiple ways: through the MANAGE RELEASES action, when creating or editing a package, or through the CHANGE RELEASE action.

To create a release through the MANAGE RELEASES action:

1. Click MANAGE RELEASES, then click CREATE RELEASE.

2. In Create Release, configure the following properties:

   Property	Description
   Name	A unique name for the release. Release names must be unique across the environment.
   Description	Additional details about the release.
   Target Release Date	The date the release is planned to go into production
   Color	A color to help visually identify the release. Defaults to the first color in the list, which is red.

   

3. Click CREATE.

All new releases are marked as active by default.

Associate packages with a release

You can use the CHANGE RELEASE action to:

• Associate packages with an existing release.
• Change the release associated with a package.
• Remove the release associated with a package.
• Create a new release and associate packages with it.

Excluding creating a release, you can take all of these actions individually on a package or in bulk on multiple packages at once.

To associate one or more packages with a release:

1. Select one or more packages in the list.
2. In the toolbar, click CHANGE RELEASE.
3. For Release, select a release to associate with the selected package(s) or remove the release associated with the selected package(s).
4. Click Update.

To create a release through the CHANGE RELEASE action:

1. Select one or more packages in the list.

2. Click CHANGE RELEASE.

   

3. Under Release, click the .

4. In Create Release, configure the following properties:

   Property	Description
   Name	A unique name for the release. Release names must be unique across the environment.
   Description	Additional details about the release.
   Target Release Date	The planned deployment date for this release.
   Color	A color to help visually identify the release. Defaults to the first color in the list, which is red.

5. Click CREATE.

The selected packages are automatically associated with the new release.

Manage a release

You can manage the properties of a release through the Manage Releases action, which can only be accessed at the environment level.

Active and inactive releases

Active releases are releases that are currently being used to organize your development work and help with feature planning. You can only associate a package with an active release. Once all packages for a release have been successfully deployed, we recommend marking the release as inactive and deleting associated packages to keep your releases relevant and well organized. You can easily make inactive releases active again by editing the release.

Marking releases as inactive helps keep you organized in a few ways:

• Inactive releases are not shown in release pickers, so it's easier to find and select the correct release for new packages.
• Inactive releases are excluded from messages about objects in packages being associated with multiple releases, so messages in the Packages view are relevant and actionable.
• When you mark a release as inactive, we'll give you the option to delete the packages associated with that release so that your packages always reflect in-progress work. You can always reference your deployment history for an accurate audit of previously deployed objects.

You can view and filter for inactive releases in the Manage Releases dialog.

Edit a release

To edit a release's properties:

1. In the Packages view at the environment level, click MANAGE RELEASES.

   

2. In the row of the release you want to edit, click .

3. Select Edit.

   

4. In Edit Release, edit any of the following properties:

   Property	Description
   Name	A unique name for the release. Release names must be unique across the environment.
   Description	Additional details about the release.
   Target Release Date	The planned deployment date for this release.
   Color	A color to help visually identify the release. Defaults to the first color in the list, which is red.
   Active/Inactive	Status showing if a release is being used for active development and organization.

5. Click SAVE.

Remove a package from a release

To remove the release association from one or more packages:

1. Select one or more packages that are currently associated with a release.

2. Click CHANGE RELEASE.

   

3. For Release, select the No Release placeholder text to remove the association between the release and the selected package(s).
4. Click Update.

The packages are no longer associated with any release, but the release itself remains in the environment and other packages may still be associated with it.

Deploy a release

When you deploy packages that are associated with a release, the release information is included in the deployment. After deployment, the release is automatically created or updated for you on the target environment.

When packages associated with a release are deployed to a target environment:

• The release properties are included in the deployment.
• If the release doesn't exist on the target environment, it is created automatically.
• If a release with the same UUID already exists on the target environment, its properties are updated to match the properties of the imported version.
• The release is included in the details for the relevant deployments on both the source and target environments.
• A package is automatically generated on the target environment for each deployed release. Each generated package contains all the objects from the deployed packages associated with the release.

Generated packages for releases

When releases are deployed to a target environment, packages are automatically generated in the target environment to hold all of the objects in deployed packages associated with each release. In order for these packages to be automatically generated, enable this setting in the Administration Console of the target environment.

In each modified application, one package is created for each release. This package has the same name as the release. So if for instance your release named "Quality Management 2.0" is associated with packages that contain objects from multiple applications, one package named "Quality Management 2.0" is generated for the release in each of the applications that were updated by the deployment.

Since the original deployed packages do not persist in the target environment, the newly generated packages allow you to keep track of which objects were deployed alongside which release. This helps you stay organized and more easily deploy all the relevant objects and releases to the next environment.

View releases information for deployments

After deploying packages associated with a release, you can go to the Deploy view to view the following information about the releases included in each deployment:

• In the Releases column on the Deployment history grid of both the INCOMING and OUTGOING tabs, you can view and filter by which releases were included in each deployment. This is especially useful for tracking which deployments have deployed changes for a given release.
• In the Deployment details, you can view the releases associated with a deployment.

If a release is deleted after deployment, the release name still appears on past deployments as read-only text so you can keep track of which releases were part of each deployment.

Release name conflicts during deployment

If a release on the source environment has the same name but a different UUID as a different release on the target environment, a numeric suffix is appended to the deployed release name. For example, if "Release 2.3" already exists on the target with a different UUID, the incoming release of the same name is renamed to "Release 2.3 (2)".

Delete a release

To delete a release:

1. In the Packages view, click MANAGE RELEASES.
2. In the Action column for the row of the release you want to edit, click .
3. Select Delete.
4. Click DELETE.

When you delete a release:

• The release is removed from the environment.
• Packages that were associated with the release are no longer associated with any release.
• The Last Modified information of the packages is updated.

Release security

Any user with access to Designer can view releases.

A user can associate a release with any package they have access to. All packages created in an application are visible to any user with Viewer permissions or higher to the application. In packages, users can only see the objects that they have permission to view.

Deploying packages that have an associated release follows the existing deployment security paradigm.

Security and release overlap alerts

The Packages view displays release overlap alerts whenever packages associated with different active releases contain the same object(s). Release overlap alerts are displayed on these packages even if a user does not have access to the shared object.

What you can see in the alert depends on your permissions:

If you have access to…	You will see…	You should…
The application, package, and object	The full alert with all relevant application, package, and object names.	Discuss the overlapping changes with other developers to determine if the changes can be deployed safely.
The application or package, but not the object	An alert about the overlap for an object that you do not have permission to view.	Reach out to other developers in the environment to understand the potential impact of deployment.
At least one object and package, but not all packages or the application	An alert about the overlap for the object, without all the package or application names.	Check the object's version history and decide if the object is in a good state to deploy.

Feedback