Overview

This page is about the packages you can create and deploy in Appian.

A package is a collection of Appian application changes that a developer can deploy to another environment. Preparing a package is an important step in the deployment process and involves understanding what changes you need to deploy and how these changes will affect your target environment.

We recommend that you use packages as a tool for building your applications and ensuring successful deployments. With packages, your development team can better organize the changes being introduced, collaborate effectively during development and peer reviews, and monitor the progress of each package periodically.

With packages, you can take advantage of direct deployments and external deployments.

Packages allow you to:

• Deploy new and updated objects to improve an application that already exists in the target environment.
• Deploy only database scripts or plug-ins to the target environment.

Your package may require other files to successfully deploy in the target environment. Import customization files, database scripts, and plug-ins are common dependencies that can be directly deployed alongside your packages. Based on the type of changes you are making to the target environment, your list of dependencies and how you deploy them will vary.

The packaging process includes the following steps:

1. Create a package.
2. Manage the package during development.
3. Prepare the package for deployment.
4. Deploy the package.
5. Delete the package.

Package properties

You can configure the following properties for your package:

Property	Description
Name	The name of the package. This name must be unique within an individual application.
Link to Ticket	(Optional) Add the URL of the related ticket in your project management tool (for example, Jira). This property enables better traceability between Appian and your project management tool.
Description	(Optional) Add a clear, concise description of the application changes you're including in the package. This description helps you to quickly assess differences in packages.

Create a package

To make your development life cycle more streamlined and efficient, Appian recommends creating packages before making changes to objects. Create a corresponding package once you have finalized requirements for building or enhancing an application.

All packages created in an application will be visible to any user with Viewer permissions or above to the application. Within a package, users can only see the objects to which they have the required privileges.

You can create up to 100 packages for an individual application.

To create a package:

1. In the application view, click PACKAGES.

   

2. In the Packages dialog, click CREATE.

   

3. Configure the package properties.

   For example:

   

4. Continue as appropriate:
   • Click CREATE if this is the last or only package you want to create.
   • Click CREATE AND ADD ANOTHER to create multiple packages, and repeat the previous steps again for each new package.

5. In the package list, click the name of the package you just created.

   You'll notice the contents view for the package is empty right now. Most likely, you'll want to do one or more of the following actions next:

   • Add objects to the package.
   • Add objects from an existing package.
   • Add database scripts to the package.

Manage a package during development

While building or improving your application, you'll commonly perform the actions described in this section.

View the package list

To view the list of packages for an individual application, click PACKAGES in the application view.

From this list, you can:

• Create a package by clicking CREATE.
• View a package by clicking the package name.
• Edit package properties.
• Add objects to one package from another package.
• Export a package.
• Delete a package.

View a package

To view an individual package, select the package from the dropdown menu in the application view:

For example:

The package view includes:

• The contents view, which contains a list of design objects included in the package. The contents view allows you to focus only on the set of objects that you are working on as part of your current changes to the application. Learn how to add objects to a package.
• The PACKAGE DETAILS pane, which displays creation and last modified information for the package. Learn how to share a package.
• The DATABASE SCRIPTS pane, which lists the database scripts included in the package. Learn how to add database scripts to a package.

Share a package

You can easily share the link to a package for change reviews.

To get the link:

1. View the package.
2. In the PACKAGE DETAILS pane, click Copy Package Link. Appian copies the URL to your clipboard.

Edit package properties

To edit package properties:

1. Open the edit dialog in either of the following ways:
   • In the package list, select the checkbox next to the package name, then click EDIT.
   • In the package view, click more options , then click Edit.
2. Configure the package properties.
3. Click SAVE.

Add objects to the package

Once you've created a package, you'll want to specify the design objects to include in the package.

To add design objects to a package:

1. View the package.
2. Click ADD EXISTING.

3. Continue as appropriate:

   • Click Application Contents to add all design objects in the application.
   • Click Add Folder Contents to add design objects from one or more folders.
   • Click Existing Objects to select individual design objects to add.

4. Make your selections:

   Option	Action
   Application Contents	Enter the name of the application, then select the application from the dropdown list. If you select an application other than (or in addition to) the current application, Appian first adds the objects from that other application to the current application, then adds the objects to the package.
   Folder Contents	Enter the name of a folder, then select the folder from the dropdown list. You can select multiple folders.
   Existing Objects	For each object category, enter the name of an object, then select the object from the dropdown list. Object categories include Record Types, Process Models, Reports, and Other (for example, a connected system.

5. (Optional) Click Check for missing precedents after adding objects to package.
6. Click ADD TO PACKAGE.

7. (Optional) If checking for missing precedents:

   • Review any missing precedents that Appian identifies.
   • If you want to add a precedent object to the package:
     • Select the object in the table.
     • Click ADD TO PACKAGE.
     • Click CHECK AGAIN. The previously missing precedent will disappear from the table.
   • When you've reviewed or resolved all missing precednts, click Close. The package displays.
8. Click CLOSE.

Add contents from an existing package

You can add the contents of one package (source package) to another package (destination package). These contents include design objects and database scripts.

If the destination package already contains database scripts, Appian adds scripts from the source package and, by default, places them last in execution order.

To add contents from one package to another:

1. View the package list.
2. Select the checkbox next to the source package.
3. Click ADD CONTENTS TO PACKAGE.
4. Begin entering the name of the destination package, then select the package from the dropdown list that displays.
5. Click ADD. Appian copies all objects from the source package to the destination package. If both the source and destination packages contain database scripts, Appian prompts you to review the combined list of scripts.
6. (Database scripts only) Review the combined scripts and make changes as necessary:
   • Remove duplicate scripts by clicking next to the script you want to remove.
   • Change the execution order of the combined scripts by clicking ORDER ALPHABETICALLY to reorder the entire list or clicking order arrows to move individual scripts.
   • Click SAVE.

Modify package objects

You can modify objects in the package view the same way you'd modify the objects in the applications view.

You can:

• Click on an object to edit it.
• Click NEW to add a new object.
• Click ADD EXISTING to add an existing object.

Add database scripts

Improving an application sometimes requires changes in the structure of underlying data sources. To implement these changes in the data source in a higher environment, you can create database scripts.

You can include these database scripts when you deploy a package. However, we recommend adding database scripts to the package during development. Adding scripts to packages lends itself to better maintainability and collaboration with your teammates throughout the development life cycle, because with packages you can track, add, reorder, and generally maintain the scripts as you develop.

When you add contents from one package to another, the contents include the database scripts associated with the original package.

To add a database script to a package:

1. View a package.
2. In the DATABASE SCRIPTS pane, click Manage Database Scripts .

3. Configure the following properties:

   Property	Description
   Data Source	Select the relational database that stores data for this application.
   Database Scripts	For each database script you want to add: Click Upload. Browse to and select a script. The uploaded script displays in the scripts table. Appian executes the database scripts in the order in which they appear in this table.

   For example:

   

4. (Optional) Change the order of script execution:
   • If you follow an alphabetical naming convention for your database scripts, click ORDER ALPHABETICALLY to reorder the entire table.
   • Otherwise, click the order arrows to move individual scripts.
5. Click SAVE.

To update database scripts in a package:

1. Add the new version of the script, using the steps above.
2. In the database script management dialog, click next to the original version of the script.
3. Click SAVE.

To delete database scripts from a package:

1. View the package.
2. In the DATABASE SCRIPTS pane, click Manage Database Scripts .
3. Click next to the script you want to delete.
4. Click SAVE.

Prepare the package for deployment

We recommend using compare and deploy to streamline your package deployment.

Compare and deploy allows you to:

• Compare objects in a package across environments.
• Bundle database scripts, plug-ins, and import customization files.
• Inspect your package.
• Directly deploy the package to the target environment.

When deploying changes to a higher environment, such as a test environment, your deployment process should generally follow these steps:

1. Validate your application in the source environment.
2. Compare environments and modify your package if needed.
3. Inspect your package and resolve any issues.

Validate your application

Make sure that all necessary objects are in your application by running missing precedents. It is also a best practice to review the security summary and make sure all your objects have the appropriate security set before beginning the packaging process.

Compare environments and modify your package

Comparing objects across environments allows you to review objects in your package and confirm that you are deploying the correct changes to the target environment. Comparing objects in a package is only available if you have added environments to your infrastructure.

If you manually create and export your package, you will have an opportunity to review the object comparison statuses by inspecting your package during manual import in the target environment.

Object comparison statuses

Object comparison statuses are available when you compare objects across environments or inspect packages before import. These statuses are helpful for understanding how your objects differ between a source and target environment, as well as how they will be handled during deployment. You should use the statuses to confirm that the correct objects are in your package and detect any conflicts before continuing with a deployment.

Status	Object Exists in Target Environment	Object Will Be Imported
Changed	Yes	Yes
Conflict Detected	Yes	Yes
New	No	Yes
Not Changed	Yes	No
Status Unavailable	Yes	Yes

• Changed:
  • This object was modified in the source environment and exists on the target environment.
  • This is the typical status you should expect when you make changes in a lower environment (development) and deploy them to a higher environment (test).
  • When you import, the object's definition will be updated in the target environment. The Last Modified information will be updated and the importing user will be set as the designer of any imported process models with this status.
• Conflict Detected:
  • This object was modified separately in both the source environment and the target environment.
  • This is the typical status you should expect when the object has different version histories, caused by one user making changes in a lower environment (development) and another user making changes in the higher environment (test) separately.
  • Make sure you address all objects with conflicts before importing your package. Otherwise, when you import, the object's definition will overwrite the definition in the target environment. The Last Modified information will be captured and the importing user will be set as the designer of any imported process models with this status.
• New:
  • This object was created in the source environment, but does not exist on the target environment.
  • You will commonly see this status as you are building new functionality.
  • When you import, the object will be created in the target environment. The Last Modified information will be captured and the importing user will be set as the designer of any imported process models with this status.
• Not Changed:
  • This object was NOT modified in the source environment and exists on the target environment.
  • This status will typically appear when you manually package a full application.
  • When you import, the object's definition will not be updated in the target environment because there are no updates to make. The Last Modified information will remain the same as it was pre-import and no change will be made to the designer of any process models with this status.
  • There are two situations when there have been changes to an object, but Appian recognizes that there are no practical differences. In these cases, the object has a status of Not Changed:
    • An application's contents have changed, but the application itself has not. For instance, this occurs when an application on the source environment has more objects within it than the application does on the target; however, the application's properties such as security and actions remain the same.
    • An object was modified in the source environment and/or the target environment, but the object definition is still identical. When this happens for expression rules, interfaces, and decisions, Appian will report them as Not Changed. On import, Appian will synchronize the objects and update the Last Modified information. Since the definition was already the same, no functional changes are introduced.

• Status Unavailable:
  • This object exists on the target environment, but the system doesn't have enough information to determine whether there's a conflict, the object was changed, or the object was not changed.
  • This status will apply to packages exported from a version of Appian, such as 17.2 where the inspection status was not supported for that object type.
  • When you import, the object's definition will be updated in the target environment. The Last Modified information will be updated and the importing user will be set as the designer of any imported process models with this status.

Addressing Objects With Conflicts

Conflicts may occur when an object is modified in the target environment and modified separately in the source environment. Objects with the status of Conflict Detected will be displayed when comparing objects across environments when using compare and deploy or when inspecting a package before manual deployment.

When you see this status, pause your deployment and proceed carefully since there is a chance of overwriting someone else's work. Examine the Last Modified information for clues about who else made a change to the object and when. If possible, talk to the teammate who made the change in order to understand what changes they made and why.

Depending on the results of this investigation, choose an option to move forward with:

1. Merge the changes: Review the object across environments and consolidate the necessary changes on the source environment. Then test and deploy your package, containing the updated object, from the source to the target. This approach is best when combining changes from two environments, such as a new enhancement in Development and a bug fix in Test.
2. Proceed with deployment: Overwrite the changes in the target environment. This approach should only be taken when the changes in the target are outdated and can be safely overwritten. For example, this can happen when the change in Test has already been made manually in Development.

We will explore the different ways to accomplish the first option and merge your changes, using the above example of deploying from Development to Test:

• For conflicts in an expression rule or interface's expression definition, resolve them by merging the changes directly on the object comparison view. This is most useful when each conflict in the object is a distinct change, such as a single function, component, or line of text.
  • In compare and deploy, click on the Conflict Detected status to view the object comparison:
  • In the Definition section, click Edit to start making changes.
  • Choose the changes to pull from Test to Development. Once all relevant changes are pulled in, save the newly updated object on the source environment and test it thoroughly to ensure that all changes work together.
  • Now the object in Development has all necessary changes, enabling a clean and safe deployment that overwrites the outdated object in Test.
• For more complex conflicts or conflicts in other objects, resolve them by editing the object and manually merging in relevant changes. It is a best practice to always resolve conflicts in the Development environment and deploy the updated object to Test. Below are guidelines for the general types of conflicts and how to address them, once you know which changes you'd like to keep.

Conflict Type	Resolution Steps
Expression and text fields	In the object comparison view, copy the desired expression or text from the object on Test. Then open the corresponding object on Development and paste in the copied text.
Selection fields, such as checkboxes	Open the object in Development and choose the selections to match the desired configuration in the object comparison view.
Smart services in process models	If you want to copy an entire smart service, you can do this between process models in the same environment. Deploy the process model from Test to Development, which will create a new version of the process model on Development. You can now separately open the last two versions of your process model, one being the original version on Development and one being the version deployed from Test. Copy the smart service from the process model version that came from Test. In the original version from Development, paste it onto the canvas, connect the smart service to the appropriate flows, and Save & Publish this version as the latest. Make sure to test your changes before deploying the updated process model to Test. If you want to merge select configurations within a smart service, follow the above advice for expression, text, or selection fields.
Documents	Download the desired version of the document from Test, then upload it as a new version of the document on Development.

Inspecting packages

After creating your package, it is a best practice to inspect the objects before deployment. This ensures that no unexpected changes have been made to the target environment and detects potential conflicts or import errors early.

Compare and deploy automatically inspects your package after you finish preparing it. If you do not have environments added to your infrastructure, you can also inspect your package before import in the target environment. As with all deployment activities, for production environments we recommend running inspections during off-peak hours.

The inspection results summarize which objects in your package have problems or warnings, how many will be created or updated by import, and how many will be skipped. When run in the target environment on a manually exported package, this summary also includes detailed information about the status of each object in your package and when they were last modified in the target environment.

Deploy a package

Deploying a package is the goal of your packaging process. With compare and deploy, you can let Appian send your package to the target environment, as long as the target is configured to allow direct deployment. Alternately, you can download the package zip file and deploy it yourself by logging in to the target environment and manually importing it. Learn more about manual export and import of packages.

During deployment, the definition of each object in your package is exported from the source environment into an XML file. Appian bundles these XML files into a zip file, which is used to move the objects to the target environment.

Information about related objects is preserved across the deployments. In most cases, the related objects themselves are not automatically exported. They must be explicitly added as objects within the package, or already present in the target environment. The application view allows you to check your application for missing precedents and add them to the application. You can track deployment progress in the deployments view.

Learn more about the deployment process.

Learn how to deploy your packages.

Learn more about object-specific rules that apply to deployments.

Delete a package

It is a maintenance best practice to delete packages when they are no longer needed.

After successful deployments, we recommend that you delete successfully deployed packages from applications in your source environment. This allows you to keep your applications clean, so long-running or unused packages don't build up over time. If your team works in sprints, you can also delete multiple packages in bulk at the end of each sprint or release.

Deleting a package does not delete the objects associated with the package.

To delete a package:

1. View the package list.
2. Select the checkbox next to the package name.
3. Click DELETE.
4. In the confirmation dialog, click DELETE. Appian deletes the package and removes it from the package list.