--- title: Modules description: Modules are subdivisions of a PingOne Authorize environment that each contain their own Trust Framework definitions, policies, and version history. component: pingone page_id: pingone:authorization_using_pingone_authorize:p1az_modules canonical_url: https://docs.pingidentity.com/pingone/authorization_using_pingone_authorize/p1az_modules.html llms_txt: https://docs.pingidentity.com/pingone/llms.txt docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md revdate: 2026-10-21T16:24:22Z section_ids: module-contents: Module contents module-types: Module types p1az-custom-modules: Custom p1az-managed-modules: Managed module-selection: Module selection module-deployment: Module deployment --- # Modules Modules are divisions of a PingOne Authorize environment that each contain their own Trust Framework definitions, policies, and version history. Use modules to divide authorization ownership across application teams so that each team can build, version, and deploy their policies independently without affecting the others. For example, a retail company might create separate modules for their customer service, inventory, and payment teams. The payment team can update and deploy their transaction approval policies, while the inventory and customer service teams continue working in their modules unaffected. ![Screen capture of the Custom tab on the Modules page.](_images/p1az-modules-overview.png) | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | You can have up to 201 modules in each PingOne environment, including:- The **Default** module. - Up to 100 custom modules. - Up to 100 API service modules.Learn more about PingOne Authorize limits in [PingOne standard platform limits](../getting_started_with_pingone/p1_platform_limits.html). | ## Module contents Each module contains the following authorization resources: * **Trust Framework** The attributes, services, conditions, and processors used in the module's authorization policies. Learn more in [Trust Framework](p1az_trust_framework.html). * **Policies** The policy sets and policies that define the module's authorization logic. Learn more in [Authorization policies](p1az_policies.html). * **Version History** A history of changes made to the module's policies and Trust Framework definitions. You can name versions and publish them to decision endpoints and Authorize gateways. Each module maintains its own independent version history. Learn more in [Authorization policy version history](p1az_version_history.html). ## Module types PingOne Authorize provides the following types of modules. ### Custom Custom modules are modules that you [create](p1az_creating_modules.html) and manage, and they're listed on the **Custom** tab of the **Modules** page. Module names must be unique within an environment. You can [delete](p1az_deleting_modules.html) a custom module unless a version of that module has been deployed to a decision endpoint or Authorize gateway. ### Managed Managed modules are listed on the **Managed** tab of the **Modules** page. The **Shield** (![Screen capture of the shield icon.](_images/pab1683047811271.png)) icon indicates that these modules are system owned, and editing restrictions apply. You can't update or delete these modules. You can add and update authorization resources in these modules. * Default PingOne Authorize bootstraps the **Default** module automatically when PingOne Authorize is first added to an environment. This module shares a Trust Framework with all API service modules. Definitions you add in this module or in any API service module are available in all other API service modules. * API service PingOne Authorize creates these modules automatically when you enable [custom policies](p1az_adding_custom_policies_for_api_services_and_operations.html) for an [API service](p1az_api_services.html). Each API service has a corresponding module that contains the authorization policies only for that service. API service modules share a Trust Framework with the **Default** module, but they maintain their own independent policies and version history. You can delete an API service module only by [deleting](p1az_delete_api_service_or_operation.html) the corresponding API service. ## Module selection To manage authorization resources for a specific module, select that **Module** on the **Trust Framework**, **Policies**, or **Version History** pages. Module selections persist across these pages, so you can switch between them without having to reselect the module. ![Screen capture showing the Module list on the Policies page.](_images/p1az-policy-module-selector.png) ## Module deployment To deploy authorization versions, [publish](p1az_publishing_versions.html) a module's version to a [decision endpoint](p1az_decision_endpoints.html) or [Authorize gateway](../integrations/p1_authz_gateways.html). When selecting a deployment target, you specify the module first, then choose a version from that module's version history. Each decision endpoint and Authorize gateway can have only one deployed module version at a time. | | | | - | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | Decision endpoints that correspond to API services are system owned. Deploy API service modules by [deploying the API service](p1az_deploying_api_services.html) rather than by publishing a version. |