Performing Use Case Cleanup Post-Installation

Task 1: Review and fix dependencies on other use cases

After you have installed the use case, certain items may not appear or function as designed because they are dependent on use cases that you have not licensed. For example, a calculated field that references an application outside of this use case will not validate unless you have also licensed another use case that contains that application. The following sections list the most common dependencies and provide steps to resolve the dependencies. In each section, the Related Use Case column lists the use case(s) that you may or may not have licensed. If you have licensed any of the listed use cases, you can skip that row. If you have not licensed any of the listed use cases, then the dependencies apply to your installation and you may want to resolve them.

Note: Resolving these dependencies is not required. You may opt to skip this step, but leaving these fields as they are may cause confusion or generate calculation errors.

Review the following sections and resolve any dependencies that apply to your installation. You only need to resolve any dependencies that apply to use cases you have not licensed.

Task 2: Delete obsolete objects

Packaging does not delete obsolete objects. Delete these objects because they may affect how the applications function. Follow these guidelines:

• If you select Override Layout when you install the package, the package installation process removes old fields from the layout, if those fields do not also exist on the Source Package layout. All fields removed from the layout are in the Available Fields list.
• Evaluate your need for certain data driven events (DDE), pre-existing rules, and actions that were not updated through Packaging. Delete any obsolete rules and actions.
• Verify the DDE and calculation order and update it if necessary.
• Evaluate pre-existing notifications and reports that Packaging did not update. Delete obsolete notifications and reports.

To ensure that all obsolete objects are deleted, compare the Data Dictionary to your environment. For more information about objects, see "Packaging" in the Archer Platform Help.

Task 3: Validate formulas and calculation orders

Follow these guidelines on validating formulas and calculation orders:

• The packaging process logs an error if a formula does not validate. This error may be caused by a formula that references applications or fields that do not exist in the instance and were not part of the package (for example, fields in applications that are part of a different use case). Review those fields to determine if they are needed.
  • If a field is needed, modify the formula to remove references to applications or fields that do not exist in your instance. Fields that do not exist in your instance are identified with an exclamation mark.
  • If a field is not needed, delete the field or remove it from the layout. If the field is not deleted, removing the formula prevents errors from being written in the log files when records are saved.
• Verify the order of calculations for each application and sub-form in the use case. See the Data Dictionary for calculation orders for each individual application or sub-form.
• Update the order of calculations as needed for each application and sub-form in the use case.

For more information about deleting objects, see Deleting Fields in the Archer Platform Help.

Task 4: Verify key fields

Packaging does not change key fields. To verify the key fields in each application, see the Data Dictionary.

Task 5: Update record permissions fields

Packaging does not remove inherited record permissions fields or user/groups populated in a record permissions field. To verify the record permissions fields in each application, see the Data Dictionary.