Module Visibility | Zoho Vertical Studio Help

Module Visibility

Module Visibility is a developer-side setting in the Developer Console. It controls where custom modules appear in your subscriber organizations with granular control across 13 locations: the Modules list, Web UI tabs, Tab Menu, Lookup Module Creation, Multi Lookup Creation, Related lists, Module listing, Workflow Configuration, Templates Configuration, Data Import, Data Export, Reports, and API.
Subscribers can hide or show modules in their organization using the Organize modules setting. This is a simple binary choice with no granular control. Each module is either visible or hidden in their org.
Use Module Visibility to control where modules appear across your application. Subscribers can customize which modules they want to see in their own organization. Note that only custom modules have visibility controls. Pre-built modules cannot be hidden or have their visibility settings changed.

How visibility layers work together

Module Visibility works with subscriber Organize modules through a key rule: modules only appear in a subscriber's Organize modules list if they are visible in all three standard UI locations (Modules list, Web UI, and Tab Menu) in your Module Visibility settings. This means subscribers can only customize the visibility of modules that you have made available in all core UI locations.
For example, if you configure a module to be visible only in Reports and Data Import, it will not appear in subscribers' Organize modules lists because those are not UI locations. If you later reconfigure Module Visibility to also show it in the Modules list, Web UI, and Tab Menu (all three standard UI locations), it becomes available in subscribers' Organize modules lists after they upgrade.

Where to access and configure module visibility in the Developer Console

  1. Log in to your Developer Console.
  2. Go to Build > Modules.
  3. Click the Visibility tab.
  4. Select the required custom module.
  5. Select or deselect the locations where you want the module to appear.
  6. Save changes and publish a new application version.
Module Visibility changes are included in the new application version and applied to subscriber organizations during upgrades.
You can also configure Organize modules settings in your Developer Console by going to Settings > Customization > Modules and Fields > Organize Modules. This setting is available in both the Developer Console and the Developer Console sandbox, and the configuration is the same in both. This is a separate setting from Module Visibility. Together, both settings control which modules appear in subscribers' Organize modules lists. Subscribers access the same path in their own organizations to show or hide modules. Organize modules settings are non-upgradable and apply only to new subscriber signups. Existing subscribers are not affected by changes to this configuration.

Sample use case

Imagine that you are building an Automotive Platform application for a car dealership. You create a custom module called Finance Approval to track internal approval workflows for vehicle financing. This module stores sensitive approval data that is not relevant to all subscribers.
Initially, you publish the Finance Approval module visible only in Reports and Workflow Configuration using Module Visibility. By default, it is enabled in the Organize modules configuration. However, since it is not visible in all three standard UI locations (Modules list, Web UI, and Tab Menu), it does not appear in subscribers' Organize modules lists.
Later, finance managers request that the module also be available from the Modules list. You update Module Visibility to show Finance Approval in the Modules list, Web UI, and Tab Menu (all three standard UI locations), plus keep it in Reports and Workflow Configuration. It remains enabled in your Organize modules configuration.
After publishing this new version, the module now appears in subscribers' Organize modules lists. New subscribers see it available to show or hide in their own Organize modules setting. Existing subscribers who upgrade also see it now available in their Organize modules lists. Individual subscribers can hide the module in their org if their team doesn't need it, and that choice persists even if you later reconfigure Module Visibility or change the Organize modules settings in your Developer Console.

Packaged module visibility

Module Visibility and Organize modules configuration are part of packaged module configuration.
To learn more about package behavior, refer to Components and Packaging in Zoho Vertical Studio.

Property

Upgrade Type

Subscriber Modify Access

Module Visibility state

Upgradable

No

Organize modules settings

Non-Upgradable

Yes


Subscriber outcomes

Version 1: Module visibility configured and published

You publish a module with specific visibility settings.
New subscriber signup: The module appears in the locations you configured.
Existing subscriber upgrade: The module visibility settings apply when they upgrade to the new version.

Version 2: Developer updates visibility in a later version

You publish a new version with updated Module Visibility settings for the same module.
  1. Module Visibility changes are upgradable: Any changes to Module Visibility settings apply to subscriber organizations during upgrades.
  2. Adding standard UI locations: If you add a module to all three standard UI locations (Modules list, Web UI, Tab Menu) for the first time, it becomes available in subscribers' Organize modules lists after upgrade.
  3. Removing standard UI locations: If you remove a module from all standard UI locations, it no longer appears in subscriber Organize modules lists after upgrade. However, if a subscriber had previously hidden the module in Organize modules, that hiding preference is preserved in the system. If you later add the module back to standard UI locations, it will reappear in their Organize modules list but remain hidden because of their earlier choice.
  4. Organize modules settings are non-upgradable: Changes to which modules are enabled in Organize modules settings only affect new subscriber signups. Existing subscribers are not affected.
  5. Developer hiding always applies: If you hide a module from all locations in Module Visibility, it becomes hidden in subscriber orgs during upgrade.
  6. Pricing-plan availability is separate from visibility: A module can be visible in Module Visibility, but it still does not appear in subscriber orgs if it is not added to the selected pricing plan. In this case, the module remains missing after signup or upgrade until it is added to the pricing plan and the application is published again.
  7. New subscriber signup on latest version: The module appears according to your current Module Visibility and Organize modules settings.

Scenario: Subscriber uses Organize modules

Subscribers have the Organize modules setting in their own organizations. This is different from your developer-side Module Visibility and Organize modules configuration.
  1. Which modules appear in subscriber's Organize modules list: A module appears in a subscriber's Organize modules list only if it is visible in all three standard UI locations (Modules list, Web UI, and Tab Menu) in your Module Visibility configuration in the Developer Console.
  2. If a subscriber hides a module using Organize modules: That choice persists across application upgrades, including when you expand Module Visibility to show the module in more locations. The subscriber must manually change their Organize modules setting to show it again.
  3. If you hide a module in Module Visibility: It becomes hidden in subscriber organizations during upgrade, regardless of what the subscriber has set in Organize modules. Subscribers cannot override this.
Understanding the asymmetry between developer and subscriber visibility control
The relationship between developer and subscriber visibility settings follows an asymmetrical pattern:
Developer hiding takes precedence: When you hide a module by removing it from all Module Visibility locations, the module becomes hidden in all subscriber organizations during their next upgrade. This applies regardless of the subscriber's Organize modules preference.
Subscriber hiding persists across developer changes: When a subscriber hides a module using Organize modules, that preference remains in effect even when you modify Module Visibility settings. The module stays hidden in their organization until they manually change their Organize modules setting.
Example scenario
Your Automotive Platform application includes a Service Notes module, initially visible everywhere in Module Visibility with the default "not hidden" state in Organize modules. When subscriber ABC signs up, they see Service Notes in their Organize modules list and decide to hide it.
Case 1: Developer hiding overrides subscriber preference. You remove Service Notes from all Module Visibility locations and publish a new version. When subscriber ABC upgrades, Service Notes is completely hidden in their organization, overriding their previous choice to keep it available in Organize modules.
Case 2: Subscriber hiding overrides developer visibility. You keep Service Notes visible everywhere in Module Visibility and publish a new version. When subscriber ABC upgrades, Service Notes remains hidden in their organization. Their earlier choice to hide it persists, regardless of your Module Visibility changes.

Troubleshooting upgrade failure with global set and visibility dependencies

Use this checklist when an application upgrade fails with dependency errors related to Global Set options and missing module visibility.
  1. Identify fields, layouts, workflows, and other components that still reference the Global Set values planned for removal.
  2. Remove or replace dependent references before publishing the upgrade package.
  3. Verify the related module is enabled in Module Visibility for required locations.
  4. Confirm the same module is included in the target pricing plan so subscriber organizations can receive it.
  5. Publish the corrected version, then upgrade a test subscriber org before production rollout.
Expected behavior:
  1. Upgrade completes when Global Set dependencies are resolved before option removal.
  2. Modules excluded from visibility or pricing can block expected post-upgrade component behavior.
  3. Dependency checks in a test subscriber org reduce upgrade risk for production subscribers.