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 (but the package then cannot be customized, which often isn't desirable).

• An unlocked package allows both additions and modifications to the package components. Additions are preserved during an upgrade. Modifications are erased. For example:

• If a Data Policy was added to a package object, the Data Policy is preserved.
• If a Custom Form was added, it too is preserved.
• In both cases, a required field might no longer exist, resulting in an error.

• 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.