Packaging

Packaging provides the means for copying applications and other objects from one Archer instance to another. Instead of manually recreating objects in a new instance and updating their elements, Packaging efficiently installs objects and applies the changes in the new instance.

Use Packaging in the following scenarios:

• Supporting IT change control practices by enabling the transfer of large changes from development to test to production instances. Packaging reduces the risk of deploying changes and decreases manual configuration tasks, which also decreases the total cost of ownership.
• Sharing applications and solutions on the Archer Community on Archer Community.
• Receiving and installing updates to Archer Solutions.
• Troubleshooting issues with Customer Support. Packaging enables customers to more efficiently communicate error situations to Customer Support, improving the ability to diagnose and solve issues.

Packaging terminology

Packaging process

The following figure shows the complete packaging process, from creating a package on the source instance to installing it on the target instance.

Package objects

The package is a ZIP file that contains one or more objects. An object is any entity within Archer that Packaging supports, for example, an application, or a sub-form or field within an application.

A Level 1 object cannot exist without a root object. Level 2 objects cannot exist without a Level 1 object. Some Level 1 objects have child objects, for example, a values list is a child of the custom values list field. The values list includes individual values list values. All objects and elements are transferred within a package.

When you create a package on the source instance, you can select which access roles, applications, questionnaires, dashboards, data feeds, and workspaces to include. Then, when you install a package on the target instance, you can select which of these root objects to install. For each selected root object, you can map all child objects to existing objects in the target instance or have the system create new objects.

Note: Packaging does not delete objects or permission settings. It only adds new or updates existing objects and permission settings. Exceptions include layout and workflow, in which packaging replaces the existing settings.

Supported and unsupported objects

The following objects are supported in Packaging:

• Access Roles
• Applications
• Dashboards
• Data Feeds
• Folders
• Global values lists
• Groups

  Note: Groups are only added when they are used in a configuration for something in a package.

• iViews
• Letterhead templates
• Questionnaires
• Reports
• Solutions
• Sub-forms
• Workspaces

  Note: Folders are used to organize certain user-created objects, such as iViews and Mail Merge templates. iViews must exist in the package from the source instance. Values List values is a child object of Global Values Lists.

Packaging does not support the following objects:

• Appearance themes
• Personal dashboards
• Personal reports
• Record content
• Training and Awareness Campaign notification templates
• User and group creation
• User-specific preferences and attributes

  Note: Email subscription preferences is an example of user specific preferences and attributes.

How objects are identified

Objects are identified by a unique system ID. Nearly every object in Archer has a system ID, for example, applications, fields, and values lists.

The primary purpose of a system ID is to identify an object in the Archer database. Packaging uses system IDs to identify objects in the source and target instances. By comparing the system IDs of objects in the source and target instances, Packaging can determine whether an object already exists in the target and should be updated, or whether to create a new object.

All objects supported by Packaging use system IDs, with the following exceptions:

• Workflow
• Users

Workflow objects use system IDs, but Packaging does not match Workflow objects. Instead, Packaging overwrites the workflow configuration.