Package Considerations

• To publish an application, include it as part of a Package, and then publish the package. Application components are automatically added to the package.

• The components contained in a locked package cannot be modified. So new fields cannot be added to an object, for example, and existing fields cannot be modified.

• The components of an unlocked can be modified, with both additions and changes. Additions are preserved during an upgrade. Changes are overwritten. For example:

• If a Data Policy is added to a package object after installation, that Data Policy is preserved.
• If the package object contains a Data Policy, and that Data Policy is modified after installation, the modifications are overwritten by the next upgrade (assuming that it still contains that Data Policy).
• Similarly for additions and modifications to Forms, Validations, and other aspects of the package object.

Note:

• If a field expected by such an addition no longer exists, an error will occur when the field is referenced.
• In general, fields are not deleted from objects, but they may be "retired" by giving them a new label and changing things to use a different field, instead. An added item (a Data Policy, for example) that depends on that field would then still "work", but could deliver inaccurate results.

• Fields, Classes, Pages, and Static Resources that are part of an installed application cannot be (re)Packaged and Published. (Exception: When an ISV user has subscribed to a package published by the ISV, components of that package can be republished.)

• If Versioning has been enabled in the installer's database, all of the versioned items are added as "checkout" items (items that must be checked out before they can be modified).

• If a package element is checked out, it cannot be added to a package until it is committed (checked in)

• The names of Fields and Objects created cannot match the name of any Package element. If there is a conflict, Package installation will fail. To succeed, either the Publisher or Subscriber will need to rename the conflicting item(s).

• To include Package Data, you must Create a Data Handler class and then Configure Package Data, so that data can be selected as part of the packaging process.
• Permissions Considerations:
  • When roles are included in a package:
    • Any permissions they contain for objects present in the package are carried over to the subscriber's instance of the platform.
    • Any administrative permissions they define are also carried over.
    • No other permissions are carried over.
  • When a user installs a package that contains role definitions:
    • The user is prompted to assign users to the new roles.
    • If the user is re-installing, the user can choose to override, ignore, or merge permissions for the new roles. (Installation documentation should instruct the user on the preferred course of action.) The choices are:
    • Override - Overwrite the existing role definition.
    • Ignore - Leave the existing role untouched.
    • Merge (the default) - form a union of existing role permissions and the role permissions defined in the package.
  • If a package does not include any Roles:
    • The package installer is shown a list of existing Roles defined in the tenancy.
    • The installer can select the Roles which will have access to the objects included in the package.
    • All selected roles get Create, Delete, and View permissions for records owned by the user, and View permissions for records owned by other team members.

• When installing a Package that includes Sites, these fields are automatically populated:

• Login As User for Unauthenticated Access field is populated as the user who is logged in
• User Web Adress is BLANK

Note: When a package is reinstalled, these fields retain the values configured by the Package Subscriber.