Mass Deployment of Packages to Tenants

Provides the Service Provider with the ability to Package applications for distribution to multiple tenants. This feature is provided to extend the functionality of Package upgrades in a multitenant environment.

If an item contained in the package being deployed already exists in the tenant's system/platform, then deployment will result in an upgrade/update, otherwise, package deployment will result in a brand new installment of the item. Learn more: Overwrite Previous Package

The Mass Deployment of Packages to Tenants option is managed by a Service Provider admin This feature is disabled, by default Learn more: Tenant Configuration Options

Package Criteria

Package Items

The following platform elements can be selected for inclusion in a Package as package items. When selected, the dependent elements shown in the table are automatically included. (Things that are not dependent are shown as excluded.)

Standard Dependencies

Platform Element	Dependent Elements
Application	Includes Custom Objects Includes Web Tabs Includes Application Information settings Includes role-based Workspace Display Order for objects Includes role-based Default View Preferences for objects Includes Sidebars and Sidebars Assignments
Objects (Custom Objects and Built-in or CRM objects)	Includes all customizable options Excludes Reports and Web Forms Excludes data
Object Data and other Data (Package Data)
Reports
Component
Classes (includes user-created classes)
Pages
Static Resources
Web Tabs (includes Components, Pages, or Widgets, if available)
Roles
Teams
Data Sharing Policies	Includes Teams and Roles involved Includes Child Teams if the Include Child Teams option is selected for that team
Mapping Profiles
Translation Workbench	Includes localized labels and items
Sites	Includes Pages

Special Dependencies

When the following elements are added to a package, the listed items are added as dependencies:

Opportunity

Price Book and Product are added as dependencies

Product

Price Book is added as dependency

Price Book

Product is added as a dependency

Campaign

List and List member are added as dependencies

Lists

List member is added as a dependency

Data Sharing Policies

Roles and Teams included as dependencies

• If the Include Child Teams checkbox is enabled, the child teams of the selected teams in the Data Sharing Policy are added as dependencies

Objects in a Master-Detail relationship

Note: The "Master-Detail relationship" option on a Lookup field has been deprecated. This section is provided for legacy objects that have a Lookup field for which that option has been selected. Learn more: Master-Detail relationships If a Detail object is added to a Package, the Master object is added (automatically) as a dependent object If a Master object is added to a Package and if that Master object includes any Rollup Summary Fields, then the Detail object is added (automatically) as a dependent object When a Tenant installs a Package, the Rollup Summary Fields limit defined in Manage Tenant Capabilities is honored If the limit is exceeded, the installation process will stop and cannot proceed In order to complete the installation, delete existing Rollup Summary Fields to reduce the total number to within the defined limit After packaging, do not add or remove any Master-Detail relationships; doing so may cause unexpected results and/or loss of data

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.

Notes:

• If a field expected by such an addition no longer exists, an error will occur when the field is referenced.
• If the field is "retired" rather than deleted (by changing it's label and using the old label on a different field, then an added item like a Data Policy that depends on the field would still work, but could deliver inaccurate results.

• Given those considerations, anyone who is in a role which allows them to modify an unlocked package needs to know what the package contains and know that, while any additions will be preserved, any changes will be overwritten at the next upgrade.

• When you add an item like a field to an object which is part of an installed package (and which might later be upgraded), a unique identifying number is appended--so there is no chance that a future upgrade will overwrite your addition.

Exception: If you are in a development Sandbox, working on a package imported from another Sandbox, your additions are seamless. No identifiers are appended.

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

Package Limitations

These package items have the following limitations:

Report

Only reports in folders that are "Visible to Everyone" or "Visible to {someRole}" can be added to a package. Reports in folders that that are visible to specific users or teams cannot be added. (The Role needs to be added to the package, as well, unless it is sure to be on the installer's system, for example by virtue of being in a package that this one depends on.)
Learn more: About Report Folders

Custom Object Views

Only views with the "Visible to Everyone" control (or visible to selected roles) can be added to a package

Users

Not included in packages, and must be re-created in the new instance

Deployment Considerations

• Deployment can only be done on packages that meet the Package Criteria
• In case of server failure/reboot during deploying, the process should be resumed when the server recovers
• If the Remote Tenant option is selected, the user will be required to enter the following information:

• Remote Server URL (must be in a valid URL format with URL protocol)
• Username
• Password

Deploy a Package

To Deploy a Package:

1. Click Settings > Administration > Global Resources > Packages
2. Click the desired Package
   • The Package must be Published before it can be included in a Package
3. Click the [Deploy] button
4. Select deployment type: 'All Tenants' OR 'Selective Tenants'. ('All Tenants' is checked by default)
5. Optionally, choose to send an upgrade notification email to each tenant; When checked, an email message is sent to the tenant's designated copy support email address (as configured in Company Information) upon the deployment completion (if deployment is successful); If the tenant has no designated email address, no message is sent; This option is disabled by default
6. Select Schedule Time: 'Immediate' OR 'Schedule Date'. ('Immediate' is checked by default)
   • Upon the completion of deployment, an email is sent to the user who submitted the request. The email contains the deployment status summary (number of tenants processed and number of successful/failed deployments)
7. Click the [Deploy] button to submit the request

To check the status of a Deployment:

1. Click Settings > Monitor > Mass Operation Status
2. Select the deployment of interest to view the progress

Distribute and Install a Package via .ZIP File

Packages can be deployed as a compressed .ZIP file, a feature available to Service Providers.

The ZIP file option provides the ability to move packages across different installations of the LongJump Platform.

The Install Package from File option must be enabled by your Service Provider. This feature is disabled by default.

Examples

• Move from the Development instance to the QA instance for testing
• Move packages from the QA instance to the production instance
• Download the package as a zip file and archive it

Create a Package as a .ZIP file

To create a Package as a downloadable .ZIP file:

1. Click the [Download Package] button to create a compressed .zip file

   

   The Package Revision Details section indicates the number of package revisions, and will automatically update when you publish new versions

2. Click the [Publish] button to create the package

Considerations

• This file can be distributed by ftp or as digital media, loaded directly to a user's desktop

• When uncompressed, the application is installed to that user's account

• This file may be very large, and unsuitable for emailing

Install a Package from a .zip file

To Install a Package from a .zip file:

1. Click Settings > Administration > Global Resources > Packages
2. Click the [Subscribe from File] button
3. Select the name of the .zip file

The package is installed

During installation, these actions are taken by the LongJump Platform:

• A list of available package items is displayed
• Validation is performed (check that Objects, Classes, Pages, Functions have unique names)
  • If any fields have been added to the packaged object, the customer_id is post-fixed to the internal field name to maintain uniqueness
  • Validation will also be done for classes, pages and resources before installing

Alternate Package Distribution Methods

A package can also be distributed in these ways:

• Publish the package and submit it to the Service Provider for distribution in the Catalog.
• Post the URL to the web or put it into an email, so users can subscribe to it directly.