The sample shows the POST /environments operation to create a new environment associated with the organization encoded in the access token. In the request body, the name, region, and type attributes are required. The value of the name attribute must be unique within the organization. The billOfMaterials attribute allows you to specify the Ping products associated with this environment.

If you set the type attribute to PRODUCTION, you cannot delete the environment until you reset the value to SANDBOX. If you have a trial license, you cannot create PRODUCTION environments or promote SANDBOX environments to PRODUCTION.

Note: If a worker application creates a new environment, that worker application is given Identity Data Admin and Client Application Developer role assignments for that environment automatically. Only the worker application can perform Identity Data Admin operations in that environment. However, the worker application can give the same role assignment to another user or another worker application. Additionally, if the worker application doesn’t have the Environment Admin role assigned for the Organization, the worker app is also assigned the Environment Admin role for the new environment. For more information about roles, see Roles.

Warning: Access to a worker application’s client secret requires having a superset of the worker application’s role assignments. Initially, the worker application is granted all of the role assignments of the admin (or worker app) that created it, which gives the admin (or any other admin with a superset of those role assignments) access to the worker application’s secret.

However, if the worker application ever gains new role assignments (for example, by creating a new environment and being granted role assignments to cover the new environment), then this can mean that the admin who originally created the worker application can no longer access its secret. This can happen when the admin roles aren’t a superset of the new role assignments for the worker application.

You can address this condition by ensuring that when an environment is created by a worker application, that worker application grants any newly received role assignments for that environment to any admins who need access to the worker application’s secret. For example:

Assume there’s an admin who always has full access to all environments in an Organization. This admin already has Organization Admin and Environment Admin role assignments at the Organization level. Assume as well, there’s a worker application that occasionally may create new environments. To ensure this admin maintains full access to the new environments created by the worker app, as well as access to the worker application’s client secret, an environment-creation script might look like this:

The worker application creates a new environment (POST {{apiPath}}/environments).
The worker application creates an Identity Data Admin role assignment for the admin, scoped to the newly created environment (POST {{apiPath}}/users/<AdminUserID>/roleAssignments).
The worker application creates a Client Application Developer role assignment for the admin user (POST {{apiPath}}/users/<AdminUserID>/roleAssignments).

See the the Administrator Permissions and Role Assignments section in the PingOne Developer Guide for more information.

Prerequisites

Property	Type	Required?
`billOfMaterials`	Object	Optional
`billOfMaterials.products[0]`	Array	Optional
`billOfMaterials.products[0].id`	String	Required
`billOfMaterials.products[0].type`	String	Optional
`billOfMaterials.products[0].description`	String	Optional
`billOfMaterials.products[0].console`	String	Optional
`billOfMaterials.products[0].softwareLicense.id`	String	Optional
`billOfMaterials.products[0].deployment.id`	String	Optional
`description`	String	Optional
`icon`	String	Optional
`license.id`	String	Required
`name`	String	Required
`organization.id`	String	Optional
`region`	String	Required
`type`	String	Required

Prerequisites

Related topics

Request model