The module lifecycle covers creating a module, publishing it as part of an application version, updating its configuration, changing its display name or visibility, and managing changes for subscriber organizations.
Lifecycle stages
Stage 1: Create and publish
Create the module in the Developer Console and configure its fields, layouts, sections, and other supported properties.
To make the module available to subscribers:
- Create and configure the module.
- Add the module to the applicable pricing plan.
- Publish a new application version.
The module is available to new subscribers who sign up for that version. Existing subscribers receive the module when they upgrade to that version.
Note: Publishing a module without adding it to the applicable pricing plan does not make it available to subscribers.
Stage 2: Update and publish
After a module is published, you can make supported changes to its configuration in the Developer Console and publish a new application version.
The way a change is applied to subscriber organizations depends on whether the corresponding module property is upgradable. For details about the upgrade behavior of individual module properties, see
Modules.
Existing subscribers receive applicable upgradable changes when they upgrade to the new application version. New subscribers receive the configuration included in the version they sign up for.
Stage 3: Rename a module
You can change the display name of a packaged module after it has been published.
The API name of a packaged module cannot be changed after the first publish.
When you publish the updated display name:
- Existing subscribers see the updated display name after upgrading to the new application version.
- New subscribers see the updated display name when they sign up to the latest version.
- Subscribers cannot edit the display name or API name of a packaged module.
Stage 4: Hide or phase out a module
A module that is part of a published application version cannot be deleted.
If you no longer want the module to appear in the application, use Module Visibility to hide it. Publish a new application version after changing the visibility settings.
When the subscriber organization upgrades:
- The module is hidden according to the updated Module Visibility configuration.
- The data in the module is not lost, but it will be hidden. The module and its data become available again if the module is made visible later.
- New subscribers to the latest version also receive the module according to the published visibility configuration.
If a module is being phased out, check whether other packaged items still reference it. Widgets, connected apps, profiles, and automation rules can fail during publish or upgrade if they still point to a module or resource that has been hidden from the current package state. Remove or replace those references before you publish the next version.
Module lifecycle and subscriber behavior
The following table summarizes common module lifecycle changes and their effect on subscriber organizations.
Scenario | Developer Console behavior | Subscriber organization behavior |
Module created and published | Create the module, add it to the applicable pricing plan, and publish the application version. | New subscribers receive the module with that version. Existing subscribers receive it after upgrading to that version. |
Module configuration updated | Make a supported change to the module and publish a new application version. | Applicable upgradable changes are applied when the subscriber upgrades. |
Module display name changed | Update the display name and publish a new application version. The API name cannot be changed after the first publish. | The updated display name is reflected after upgrade. Subscribers cannot edit the display name or API name. |
Module visibility changed | Update Module Visibility and publish a new application version. | The visibility change is applied when the subscriber upgrades. |
Module deleted | A module that is part of a published application version cannot be deleted. | The module remains part of the published application version. |
Phasing out a published module
If you need to phase out a module that has already been published, do not attempt to delete it from the application.
Instead:
- Stop using the module in new layouts, workflows, or other application configurations where applicable.
- If users should no longer see the module, configure Module Visibility to hide it.
- Publish a new application version.
- Test the new version in a subscriber organization.
- Upgrade a test subscriber organization and verify the module's visibility and dependent configurations.
- Communicate any required changes to subscribers before they upgrade.
Note: Hiding a module does not delete its data. The module and its data can become available again when the module is made visible.