Inspect Package

This page explains how import inspection can help you avoid partial or problematic deployments. Before importing an application, a patch application, or Administration Console settings, you should inspect and evaluate the package contents. No objects are created or updated during inspection.

Source and Target Environments

In this article, the source environment is the environment from which the package was exported and the target environment is the environment where the inspection and import is taking place. Some common deployment path examples include:

Source Environment, deploys to… Target Environment
Development Test
Development 1 Development 2
Break Fix / Hotfix Development
Test Production

Inspect Environments

How to Inspect a Package

Inspection identifies objects with missing dependencies, data stores that don't match the schema on the target system, and package corruption (invalid XML); it does not catch all possible errors, such as incorrect permissions or insufficiently unique names. Since you can't undo an import, it's a best practice to inspect your packages before deployment to catch any detectable package issues.

To inspect a package:

  1. Click one of the following buttons in your target environment, depending on your package type:
    1. Import Application for full application packages in Appian Designer
    2. Import Patch for patch packages in the application
    3. Import for admin setting packages and related application or patch packages in the Administration Console
  2. Upload your package zip file and related import customization file (if applicable)
  3. Click Inspect

Interpreting Package Inspection Results

After you click Inspect, you will be presented with your package inspection results. At the top, there is a summary of how many items in your package have problems or warnings, how many will be created or updated by import, and how many will be skipped. Underneath this summary message is detailed information about the projected import status of each of the objects in your package.

Inspect Application

Conflict Detected

If an object is modified in the source environment AND separately on the target environment, it will appear in the Conflict Detected section of the Inspection Results. When you see this status, you should pause your deployment and investigate the changes.

When you click Import Package, the definition in the package will overwrite whatever is in the target environment. Since the changes in the target environment are not guaranteed to be in the package, there is a risk of losing work! 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.

This check is helpful for detecting conflicts when deploying from a Break Fix environment back to Development or among multiple Development environments.

Addressing Objects With Conflicts

When you encounter the status Conflict Detected on inspect, you should proceed carefully since there is a chance your import will overwrite someone's work. When you see an unexpected conflict:

  1. Examine the Last Modified in This Environment information for clues about who might have made a change before you. If possible, talk to them in order to understand what changes they made and why.
  2. Look at the object definition in the target environment and compare it to the source environment. Consider which environments these changes have been made in, e.g. are there running instances to consider in Production?
  3. Depending on the results of this investigation, do one of the following:
    1. Import the package as-is and overwrite the changes in the target environment.
    2. Export the object from the target environment and import it into the source environment, overwriting changes in the source environment. Build and export an updated package from the source environment.
    3. Manually merge the changes in the source environment and then build and export an updated package. Note: the objects will still appear in the Conflict Detected section, but the manual merge means you won't be overwriting changes.

To avoid false conflicts, export your application from your development environment after upgrading from a pre-17.3 version and import it to each higher environment. This will set a baseline for your changes.

Inspection Statuses

Objects with no detected import problems appear in the Success section. For these items, inspection performs additional analysis to generate an Inspection Status, which describes how the object in the package compares to what exists in the target environment and, therefore, what type of change the import will make. The available inspection statuses have the following unique characteristics:

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

More details about the inspection statuses are available below:

  • 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 (e.g. Development) and deploy them to a higher environment (e.g. Test).
    • When you click Import Package, 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.
  • 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 click Import Package, 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 export full applications, rather than patches that only contain your changes.
    • When you click Import Package, 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.

If you need to force an import for objects with a Not Changed status, add the FORCE_UPDATE import-specific setting to your import customization file. See Managing Import Customization Files for a use case with more information on when and how to force an update.

  • 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 (e.g. 17.2) where the inspection status was not supported for that object type.
    • When you click Import Package, 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.

These inspection statuses are helpful for detecting conflicts when deploying from a Break Fix environment back to Development or between multiple Development environments. In a typical Development-Test-Production deployment progression, the statuses will allow a quick gut-check to confirm that the correct objects are being created and updated.

Inspecting Data Types from Web Services

It's a best practice to include data types created from WSDLs in your application or patch package before exporting it.

If those data types are not included in your package AND they don't already exist on the target environment, they'll be listed as problems in the inspection results. Data types that are normally created by the Call Web Service Smart Service or webservicequery() function during import cannot be created by the package inspection process.

FEEDBACK