Prepare the Deployment

The second step of a direct deployment using Compare and Deploy is the Prepare Deployment step. Here, you assemble all of the objects, application configurations, database scripts, and plug-ins across packages for deployment and review any changes that have been made to objects.

In the Prepare Deployment step, you can:

• Select an application, packages, or database scripts and plug-ins for deployment.
• See all objects within your application or packages.
• Manage the application configurations, objects, database scripts, or plug-ins in the deployment.
• View the statuses for application configurations, objects, and plug-ins.
• Review changes to objects.

The Prepare Deployment step compares the objects in your current environment to the target environment. If you are deploying multiple packages from multiple applications, the objects are grouped by application for review. You can review the changes made to each application by using the left pane application cards. Learn more about package comparison.

Choose what to deploy

Your Prepare Deployment workflow depends on what you want to deploy:

• If your application is new to the target environment, you can either deploy the entire application or deploy a package. This initial deployment always includes the application configurations needed to ensure a smooth deployment to your target.

• If your application already exists in the target environment, select the corresponding option to continue:

  Option	Description
  All Application Objects	Select this option to deploy the entire application. With this option you can deploy all objects in an application, as well as database scripts and plug-ins.
  Packages	Select this option to deploy one or more packages, including packages from multiple applications. With this option you can deploy packages with objects, application configurations, database scripts, and/or plug-ins. Packages can contain any or all of the contents listed.
  Database Scripts and plug-ins	Select this option to deploy database scripts or plug-ins without a package. With this option, you can add database scripts and plug-ins to the deployment. This functionality is only available through the Compare and Deploy workflow.

Prepare an application

Deployment of an entire application always includes the application configurations.

To prepare an entire application for deployment:

1. Under What would you like to deploy?, select All Application Objects.
2. Review the contents of the application:
   • Click on the status of objects or application configurations for more information.
   • Resolve issues as needed.
3. (Optional) Add database scripts or plug-ins.
4. Click NEXT to continue to the Inspect Deployment step.

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

Prepare a package

Learn how to create a package.

To prepare one package from a single application for deployment:

1. Under What would you like to deploy?, select Packages.
2. Select your package from the Select packages dropdown list.
   • For new application deployments, application configurations are included in the deployment by default. For all future deployments you can choose whether to include them using the Include app configurations in this deployment toggle. See the Application configurations section for more information.
3. Review the contents of the package:
   • Click on the status of objects, application configurations, or plug-ins for more information.
   • Resolve issues as needed.
4. (Optional) You can remove design objects from the package:
   • In the objects grid, select an object.
   • Click REMOVE FROM PACKAGE.
5. (Optional) You can add design objects to the package:
   • Toggle off Only view objects in package. The objects grid updates to display all objects in the application.
   • In the objects grid, select the object(s) you want to add.
   • Click ADD TO PACKAGE.
6. (Optional) Add or remove application configurations.
7. (Optional) Add database scripts or plug-ins.
8. Click NEXT to continue to the Inspect Deployment step.

To learn about deploying multiple packages from multiple applications, see the Packages View.

Modify package contents

You can only modify the contents of a package if it is the only package being deployed for that application.

Meaning, you can only add or remove package contents when:

• You deploy a single package.
• You deploy a single package per application.

To quickly figure out if you can modify package contents, check to see if there is a checkbox beside the object name in the Objects tab of the Prepare step in Compare and Deploy.

Prepare multiple packages from multiple applications

When you deploy multiple packages from multiple applications using either Compare and Deploy or Export, you'll notice that each application for each package included in the deployment is shown in cards in the left navigation. This allows you to go between applications and the selected packages included in them to see the objects, database scripts, and plug-ins in the deployment.

To prepare multiple packages from multiple applications for deployment:

1. From the Packages view at the environment level, select the packages you want to deploy.
2. Select the target environment.
3. Confirm that the packages and applications listed in the left navigation pane are correct.
4. To review the contents of the packages, select an application from the list:
   • Click on the status of objects, application configurations, or plug-ins for more information. You can use the Associated Packages column to find and review information for specific packages.
   • Resolve issues as needed.
5. Review the database scripts or plug-ins included in your selected packages.
6. (Optional) Add or remove application configurations.
   • For new application deployments, application configurations are included in the deployment by default. For all future deployments you can choose whether to include them using the Include app configurations in this deployment toggle. See the Application configurations section for more information.
7. Click NEXT to continue to the Inspect Deployment step.

Add or remove application configurations

Application configurations are a category of settings that apply to the application on a global level. These configurations are not design objects, but may rely on design objects to function. Learn more about application configurations.

The deployment always includes application configurations that you cannot remove during Compare and Deploy if either of the following is true:

• Your application is new to the target environment.
• You're preparing to deploy the entire application to the target environment.

If you are deploying multiple packages at once, you can't individually add or remove application configurations from your selected packages. If the Include app configurations in this deployment toggle is on, your application configurations are already included in the selected packages. P However, if you're deploying packages for an application that already exists in the target environment, you can do any of the following during Compare and Deploy:

• If the status of the application configurations is Changed or Conflict Detected, click View Details to review the current application configurations compared to the configurations present in the target environment.
  • Added configurations are highlighted in green.
  • Deleted configurations are highlighted in red.
  • Collapsed sections contain unchanged configurations. You can click sections to expand them.
• Toggle on Include app configurations in this deployment to add application configurations to the deployment and associated package.
• Toggle off Include app configurations in this deployment to remove application configurations from both the deployment and the package.

If you're done working with application configurations, click NEXT to continue to the Inspect Deployment step.

Add or remove database scripts

Database scripts can be deployed on their own or included within the deployment of an application or package. You can specify the data source and database scripts for each package in the deployment. This means that a single deployment can have multiple database scripts and multiple data sources.

You can set the execution order of database scripts within a package and reorder the execution order of packages. This gives you complete control over the order that the database scripts are executed for your deployment. The execution order of database scripts within a package is saved to the package, but the execution order of packages is not persisted.

Database scripts are not exported along with packages and application objects. Skip this step if you do not have permission to deploy database scripts directly to the target environment.

Add or remove database scripts from single packages or packages from a single app

To add database scripts and data sources to a deployment for a single package or multiple packages from a single app:

1. Click DATABASE SCRIPTS.
2. Select a Data Source for the app or each package. If you added database scripts to the package during development, this field automatically selects the data sources for those database scripts.
   • If a data source connected system is a part of your deployment, the associated data source will not display in the list. You must deploy database scripts separately from their connected system.
3. Click UPLOAD to add a database script.
4. In the Database Scripts list:
   • To remove scripts, click next to the script in the list.
   • To change the execution order of database scripts in a package, drag and drop the database scripts into the correct order. To change the overall execution order of packages, use the order arrows next to the box for each package.
5. Click NEXT to continue to the Inspect Deployment step.

If you're deploying a database script that changes a database related to a record type with sync enabled, the deployment may require an import customization file (ICF) to trigger a sync after deployment of the script in the target environment. Learn more about triggering a sync in the target environment.

Appian must be able to successfully run the scripts before it can attempt to deploy the objects. Scripts for all packages are executed before any objects are deployed. If an error occurs during script execution, the deployment stops. To resolve script errors, refer to the deployment log for further details.

If you are deploying a generated package created for a release in an intermediate environment, you can learn more about deploying multiple database scripts for generated packages.

Deploy database scripts for packages from multiple applications

Once you start a direct deployment for packages from multiple applications, you can't add or remove database scripts to the packages. We recommend that you add or remove database scripts for these packages before you start a direct deployment.

For deployments that include packages from multiple applications, database scripts run alphabetically by application then by the order of the individual scripts defined in the Database Scripts tab. The alphabetical order by application can't be changed, but you can modify the execution order of the individual scripts to fit your unique deployment needs.

Save database scripts to a package

When you add or remove database scripts during the Prepare Deployment step, Appian saves those changes to the associated package.

When deploying multiple packages, you must add all database scripts to your packages before starting Compare and Deploy. For multi-package deployments, packages that don't already contain database scripts won't show in the DATABASE SCRIPTS tab, so you can't add or remove database scripts to them during that step.

The execution order of database scripts within a package is also saved to the package. However, the execution order of scripts across packages is not persisted. If you don't complete the steps in Compare and Deploy, review the DATABASE SCRIPTS tab again to confirm that the database scripts are in the correct order across packages.

Add plug-ins

Plug-ins can be deployed on their own or included within the deployment of an application or packages.

Deploying plug-ins with a package is only necessary under specific conditions. Learn more about these conditions before continuing.

Plug-ins are not exported along with packages and application objects. Skip this step if you do not have permission to deploy plug-ins directly to the target environment.

If you are deploying multiple packages at once, you can review the plug-ins to deploy here, but you can't add or remove plug-ins from the deployment.

To deploy plug-ins:

1. Click PLUG-INS. By default, the grid displays plug-ins that have been added to the packages during development.
2. (Optional) Filter the grid by selecting a status from the dropdown list.
3. Verify that the package includes the referenced plug-ins you want to be included. To do this, compare the Show plug-ins in package list to the Show plug-ins referenced in package list. By default, the referenced plug-ins list shows plug-ins with a Changed or New status only.
4. Add referenced plug-ins to the package:
   • Select Show plug-ins referenced in package.
   • Select one or more plug-ins in the referenced plug-ins list.
   • Click ADD TO PACKAGE.
5. Add unreferenced plug-ins to the package:
   • Select Show plug-ins in environment. The grid displays all plug-ins installed in the current environment.
   • Select one or more plug-ins in the list.
   • Click ADD TO PACKAGE.
6. Remove plug-ins from the package:
   • Select any grid display option.
   • Select one or more plug-ins in the plug-ins list.
   • Click REMOVE FROM PACKAGE.
   

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

7. Click NEXT to continue to the Inspect Deployment step.

Comparing across environments

This section describes how Appian compares objects across environments. In both direct deployments and inspect before import, Appian compares objects and application configurations included in the package to the existing applications in a target environment. By comparing the objects in your deployment to those same objects in the target environment, you can review your objects, modify them as needed, and ensure that you are deploying the correct changes to the target environment.

In direct deployments only, Appian also performs the comparison for any plug-ins included in the package.

What is compared

Package contents can include design objects, application configurations, database scripts, and plug-ins. Appian compares the packages' contents to the existing versions of those contents in the target environment when you do either of the following:

• Prepare the package as part of direct deployment (only available if you have connected environments in your infrastructure)
• Inspect the packages as part of a manual import.

This comparison determines if the items in the packages you're deploying:

• Exist on the target environment.
• Exist on the target environment and have changed.
• Exist on the target environment but have conflicts with those in your source environment.

Appian displays a comparison status for each item in the packages during the Prepare Deployment step of compare and deploy and when you inspect the package. You can use the status to confirm that your packages include the correct items and detect any conflicts before continuing with a direct deployment or import. Additionally, in compare and deploy, you can immediately view the differences between the items in the packages and the target environment.

Comparison statuses

Comparison statuses are helpful for understanding how items in an incoming package differ from existing items in the target environment, as well as how the package items will be handled during deployment.

These statuses include the following:

Status	Item Exists in Target Environment	Item Will Overwrite on Import
Changed	Yes	Yes
Conflict Detected	Yes	Yes
Conflict Resolved	Yes	Yes
New	No	Yes
Not Changed	Yes	No1
Protected	Yes	No1
Status Unavailable	Yes	Yes

¹ Use an import customization file to force import of unchanged objects or override object protection.

Changed

• The design object or plug-in was modified in the source environment and exists on the target environment.
• This status will typically appear when you make changes in a lower environment (development) and deploy them to a higher environment (test).
• When you import, Appian updates the definition of the object, application configuration, or plug-in in the target environment. The Last Modified information will be updated. Also, the importing user will be set as the designer of any imported process models with this status.

Conflict Detected

• The design object or plug-in was modified separately in both the source environment and the target environment, or the application configurations were modified in the source environment and exist on the target environment.
• This status will typically appear when the version histories of the incoming item and the existing item differ. This condition is 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 conflicts before importing your package. Otherwise, when you import, the package item'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.
• For interfaces and expression rules, clicking RESOLVE opens the guided conflict resolution experience. This experience uses a common ancestor as a shared baseline when one is available.

Conflict Resolved

• This status is only applicable to interfaces and expression rules.
• The conflicting changes in the interface or expression rule have been reviewed and any relevant changes have been saved directly to the object in the source environment. Continue with the deployment to apply the changes to the target environment.

New

• The package item 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 package item will be created in the target environment. The Last Modified information will be captured. Also, the importing user will be set as the designer of any imported process models with this status.

Not Changed

• The package item was not modified in both source and target environments.
• This status will typically appear when you manually package a full application.
• When you import, the package item'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. No change will be made to the designer of any process models with this status.
• There are two situations when changes have been made to an object, but Appian recognizes that there are no practical differences. In these cases, the object has a status of Not Changed:
  • Design objects in an application have changed, but the application configurations have not. For instance, an application on the source environment might contain more objects than the application does on the target; however, the application configurations remain the same.
  • A design 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.

Protected

• The package item was edited in the target environment as part of an expected and supported workflow. The changes from the source environment will be skipped.
• In most applications, making changes to objects in a target environment is unwanted behavior, because objects from the source environment are the most up-to-date, authoritative version of the objects. However, an application can incorporate capabilities that let business users create and edit certain objects in a target environment. For example, reports and dashboards in Process HQ can be modified by business users after deployment. In this workflow, the Protected status prevents the automatic overwriting of the business user's changes in the target environment.
• This status is only assigned if objects of this type have been edited by business users in the target environment. If an object of this type has not been edited in the target environment when you deploy from a source environment, the system assigns the object the other standard statuses. For example, you can change a report in the source environment, then deploy it to a target environment where the object has not been edited, and the system will assign a Changed status instead of Protected.

Status Unavailable

• This package item exists on the target environment, but the system doesn't have enough information to make a comparison.
• 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 deploy or import, the package item's definition will be updated in the target environment. The Last Modified information will be updated. Also, the importing user will be set as the designer of any imported process models with this status.

View comparison results

In compare and deploy, you can view the differences between package items and items in the target environment if you click a Changed, Conflict Detected, Conflict Resolved, or Protected status.

The comparison results open in a new browser tab. The following is how the comparison results for all objects and package contents appear:

• The values for the object in the source environment appear in the left column.
• The values for the object in the target environment appear in the right column.
• Sections that do not contain any changes are collapsed by default.

The differences between the items in each environment are highlighted with the following colors:

Difference	Color
Addition	GREEN
Modification	YELLOW
Deletion	RED

The comparison results are divided into sections. These sections contain properties specific to the type of object or configuration being compared.

The system applies object security and data security to the property values in the results, so you may see the following values display when appropriate:

Display Value	Condition
[Not visible]	You do not have permissions to access an object or related data from the target environment. For example, you might have access to a record type, but not to individual records associated with that object.
[Value masked] or (Target value masked)	The property potentially contains sensitive data from the source environment, so the value is hidden. For example, you might have access to a report that contains patient data in a medical setting, and business users might have configured a filter for that report that uses a patient name.

To better understand individual properties included in comparison results, see the descriptions of the object types or application configurations involved.

Addressing conflicts

Conflicts may occur when a package item is modified in the target environment and modified separately in the source environment.

When you see the Conflict Detected status:

1. Pause your deployment and proceed carefully since there is a chance of overwriting someone else's work.
2. Examine the Last Modified information for insight into who made a change to the object and when.
3. If possible, talk to the teammate who made the change in order to understand what changes they made and why.

Depending on what you find, choose either of the following approaches to moving forward:

• Resolve conflicts: For interfaces and expression rules, you can review the conflicting changes and decide which changes from the versions on the source and target environments to include in your deployment. This approach is best when combining changes from two environments, such as a new enhancement in Development and a bug fix in Test.
• Manually merge conflicting changes: Review the item across environments and manually consolidate the necessary changes on the source environment. Then test and deploy your package, containing the updated item, from the source to the target. This approach is best when combining changes from two environments for objects or package contents that aren't interfaces or expression rules.
• 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, you might choose this option when the change in Test has already been made manually in Development.

We will explore the different ways to accomplish the first two options for resolving or consolidating conflicting changes.

Resolve conflicts in interfaces and expression rules

For interfaces and expression rules, Appian provides a guided conflict resolution process that lets you pick which changes from the versions on the source and target environments to include in your deployment. This interactive process is only available for interfaces and expression rules.

This process can use a common ancestor as a shared baseline. A common ancestor is the last shared version of the interface or expression rule before the source and target environments diverged, and Appian uses environment connection history to identify it. When a common ancestor is available, Appian shows the source and target changes relative to this baseline, so you can see whether each difference is an addition, a change, or a removal—not just that the two versions differ.

This context can be useful when you're merging a production hotfix back into a development environment, incorporating changes from a parallel environment, or reviewing AI-generated changes before accepting them.

When Appian cannot identify a common ancestor for either object type, the process compares the source and target versions directly.

The conflict resolution view uses a three-column layout:

Column	Description
Source environment	Shows the values from the version being deployed from the source environment.
Resulting version	Shows the resulting version that will be saved to the source environment and eventually deployed to the target environment. By default, this column contains the resulting version and can hold values from the source version, the target version, or both. For an interface or expression rule with a common ancestor, this column instead starts as the common ancestor and updates as you select changes from the source or target.
Target environment	Shows the values from the version in the target environment.

For interfaces or expression rules without a common ancestor, the color blue designates all changes between the source and target versions.

For example:

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

For an interface or expression rule with a common ancestor, the source and target columns show each side's changes relative to that shared baseline: additions are highlighted in green and removals in red.

For example:

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

To resolve conflicts in an interface or expression rule during a direct deployment:

1. Begin the Compare and Deploy flow.
2. On the Prepare Deployment step, find the interfaces or expression rules with conflicts by checking the Status column.

3. For an object with a Conflict Detected status, click the status to view the details of the comparison results, or click RESOLVE to start the conflict resolution process. Both open in new tabs.

   

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

   

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

4. In the source and target columns, use the checkboxes to select the changes you want to include in the resulting version. As you select changes, the center column updates to show the current state of the object that will be saved.

   

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

   • You can optionally click Select All to add everything from that version to the resulting version. You can still select or deselect individual changes after clicking Select All.
   

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

   • For an interface or expression rule with a common ancestor, leave a change unselected in both columns to keep the ancestor (baseline) value. When both sides changed the same configuration, selecting one side's change automatically deselects the other side's change.
5. (Optional) If you want to start over, reset your decisions. You can reset all decisions while the status is still Conflict Detected. Refreshing the browser also resets all decisions.
6. (Optional) If you see a message about security conflicts, go to the object and resolve the conflicts manually.
7. After selecting all the changes you want to include, click SAVE IN OBJECT. This opens the interface or expression rule object.

8. In the object, verify that your changes are correct and the object functions as expected. Run any relevant test cases.

   

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

9. After testing and verifying your changes, click SAVE.
10. Return to the Prepare Deployment step of Compare and Deploy and refresh the object list. The status of the object updates to Conflict Resolved.

Continue reading to learn how to manually consolidate conflicting changes in other objects and types of package contents.

Manually merge conflicting changes

There are a few more manual steps to consolidate conflicting changes between objects and package contents manually.

Where the conflict is	Deployment type	How to resolve
Application configurations	Direct deployment	Resolve the discrepancy in the specified application configuration.
Application configurations	Manual deployment	Check the application configurations in each environment to identify which configuration is involved, then resolve the discrepancy.
Other objects and package contents	Direct and manual deployments	Edit the object and manually merge in relevant changes. It is a best practice to always resolve conflicts in the Development environment and deploy the updated object to Test. Check the guidelines for the general types of conflicts and how to address them, once you know which changes you'd like to keep.

Complex conflicts and how to address them

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. 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.

Feedback