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.

• Whenever possible, publish a package as locked for external users, or users in a production setting. Package contents cannot then be modified, which makes upgrades simple and reliable (but at the cost of disallowing customization).

• An unlocked package allows both additions and modifications to the package components. Additions are preserved during an upgrade. Modifications 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. They are typically given new labels, instead. An added item (a Data Policy, for example) that depends on that field would then still "work", but 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.