--- title: Create and modify object types description: If the managed object types provided in the default configuration don't meet your needs, you can create or modify them. component: pingidm version: 8.1 page_id: pingidm:objects-guide:creating-modifying-managed-objects canonical_url: https://docs.pingidentity.com/pingidm/8.1/objects-guide/creating-modifying-managed-objects.html keywords: ["Data Object Model", "Schema"] section_ids: managed-objects-property-def-fields: Typical managed object property definition fields create_an_object_using_the_admin_ui: Create an object using the admin UI default-values-managed-obj: Default values --- # Create and modify object types If the managed object types provided in the default configuration don't meet your needs, you can create or modify them. Every managed object type has a `name` and a `schema` that describes the properties associated with that object. The `name` can only include the characters `a-z`, `A-Z`, `0-9`, and `_` (underscore). You can add any arbitrary properties to the schema. | | | | - | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | * Avoid using the dash character (`-`) in property names (for example, `last-name`) because dashes in names make JavaScript syntax more complex. Instead, use camel case (for example, `lastName`). If you can't avoid dash characters, write `source['last-name']` instead of `source.last-name` in your JavaScript. * Managed object properties that contain an underscore (`_`) are reserved for internal use. Don't create new properties that contain underscores or include these properties in update requests. | ## Typical managed object property definition fields * `title` The name of the property, in human-readable language, used to display the property in the UI. * `description` A brief description of the property. * `viewable` Specifies whether this property is viewable in the object's profile in the UI. Boolean, `true` or `false` (`true` by default). * `searchable` Specifies whether this property can be searched in the UI. A searchable property is visible within the Managed Object data grid in the end-user UI. For a property to be searchable in the UI, it *must be indexed* in the repository configuration. For information on indexing properties in a repository, refer to [Object mappings](explicit-generic-mapping.html). Boolean, `true` or `false` (`false` by default). | | | | - | ------------------------------------------------------------------------------------------------------------------------- | | | The end-user UI is not bundled with PingIDM. Learn more in [Install the end-user UI](../setup-guide/idm-enduser-ui.html). | * `userEditable` Specifies whether users can edit the property value in the UI. This property applies in the context of the End User UI, where users are able to edit certain properties of their own accounts. Boolean, `true` or `false` (`false` by default). * `isProtected` Specifies whether reauthentication is required if the value of this property changes. For certain properties, such as passwords, changing the value of the property should force an end user to reauthenticate. These properties are referred to as *protected properties*. Depending on how the user authenticates (which authentication module is used), the list of protected properties is added to the user's security context. For example, if a user logs in with the login and password of their managed user entry (`MANAGED_USER` authentication module), their security context will include this list of protected properties. The list of protected properties is not included in the security context if the user logs in with a module that does not support reauthentication. * `pattern` Any specific pattern to which the value of the property must adhere. For example, a property whose value is a date might require a specific date format. * `policies` Any policy validation that must be applied to the property. For more information on managed object policies, refer to [Default policy for managed objects](configuring-default-policy.html). * `required` Specifies whether the property must be supplied when an object of this type is created. Boolean, `true` or `false`. | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | IDM assesses the `required` policy only during object creation, not when an object is updated. You can effectively bypass the policy by updating the object and supplying an empty value for that property. To prevent this inconsistency, set both `required` and `notEmpty` to `true` for required properties. This configuration indicates that the property must exist and must have a value. | * `type` The data type for the property value; can be `string`, `array`, `boolean`, `integer`, `number`, `object`, `Resource Collection`, or `null`. | | | | - | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | If any user might not have a value for a specific property (such as a `telephoneNumber`), you must include `null` as one of the property `types`. You can set a null property type in the admin UI (Configure > Managed Objects > User, select the property, and under the Details tab, Advanced Options, set `Nullable` to `true`).You can also set a null property type in your managed object configuration by setting `"type" : '[ "string","null" ]'` for that property (where `string` can be any other valid property type. This information is validated by the policy service, as described in [Validate Managed Object Data Types](configuring-default-policy.html#policy-config-input).If you're configuring a data `type` of `array` through the admin UI, you're limited to two values. | * `isVirtual` Specifies whether the property takes a static value, or whether its value is calculated "on the fly" as the result of a script. Boolean, `true` or `false`. * `returnByDefault` For non-core attributes (virtual attributes and relationship fields), specifies whether the property is returned in the results of a query on an object of this type *if it is not explicitly requested*. Virtual attributes and relationship fields are not returned by default. Boolean, `true` or `false`. When the property is in an array within a relationship, always set to `false`. * `relationshipGrantTemporalConstraintsEnforced` For attributes with relationship fields. Specifies whether this relationship should have temporal constraints enforced. Boolean, `true` or `false`. For more information about temporal constraints, refer to [Use temporal constraints to restrict effective roles](roles-temporal-constraints.html). * `default` Specifies a default value if the object is created without passing a value. Default values are available for the following data types, and arrays of those types: * boolean * number * object * string | | | | - | -------------------------------------------------------- | | | IDM assumes all default values are valid for the schema. | * `enum` []()Restricts a field's possible values to a defined set of options. `enum` is supported for `string` and `number` types, and for `array` types containing strings or numbers. To define `enum` values, add the `enum` property to the field's schema definition in the managed object configuration *(tooltip: You can edit the managed object configuration over REST at the config/managed endpoint, or directly in the conf/managed.json file.)* using an API PUT request to the `/openidm/config/managed` endpoint or editing the file. Currently, you can't use the IDM admin UI to add, remove, or edit enums directly. In the following examples, the `string` type shows the JSON hierarchy of the property, while the others truncate everything except the property itself. * string * number * array of strings ```json { "_id": "managed", "objects": [ { ... "schema": { ... "properties": [ ... { "favoriteColor": { "enum": [ "red", "green", "blue" ], "title": "Favorite Color", "type": "string", "viewable": true, "searchable": false, "userEditable": true, "description": "Choose your favorite color", "format": null, "isVirtual": false }, ... ``` ```json { "custom_enum_single_number": { "title": "Rating", "description": "Select the best number", "type": "number", "viewable": true, "userEditable": true, "enum": [ 4, 8, 15, 16, 23, 42 ] } } ``` ```json { "custom_enum_array_string": { "title": "Preferred Colors", "description": "Choose your preferred colors", "type": "array", "viewable": true, "userEditable": true, "items": { (1) "type": "string", "enum": [ "red", "green", "blue", "yellow" ] } } } ``` | | | | ----- | --------------------------------------------------------------- | | **1** | The `enum` definition must be placed within the `items` object. | ## Create an object using the admin UI 1. Select Configure > Managed Objects > New Managed Object. 2. On the New Managed Object page, enter a name and readable title for the object, make optional changes, as necessary, and click Save. The readable title specifies the label that displays in the UI. 3. On the Properties tab, specify the schema for the object type (the properties that make up the object). 4. On the Scripts tab, specify any scripts that are triggered by events associated with the object type. For example, scripts that run when an object of this type is created, updated, or deleted. You can also create a new managed object type by editing your managed object configuration *(tooltip: You can edit the managed object configuration over REST at the config/managed endpoint, or directly in the conf/managed.json file.)* using an API PUT request to the `/openidm/config/managed` endpoint or editing the file. > **Collapse: Example: object created using the admin UI** > > ```json > { > "name": "Phone", > "schema": { > "$schema": "http://forgerock.org/json-schema#", > "type": "object", > "properties": { > "brand": { > "description": "The supplier of the mobile phone", > "title": "Brand", > "viewable": true, > "searchable": true, > "userEditable": false, > "policies": [], > "returnByDefault": false, > "pattern": "", > "isVirtual": false, > "type": [ > "string", > "null" > ] > }, > "assetNumber": { > "description": "The asset tag number of the mobile device", > "title": "Asset Number", > "viewable": true, > "searchable": true, > "userEditable": false, > "policies": [], > "returnByDefault": false, > "pattern": "", > "isVirtual": false, > "type": "string" > }, > "model": { > "description": "The model number of the mobile device, such as 6 plus, Galaxy S4", > "title": "Model", > "viewable": true, > "searchable": false, > "userEditable": false, > "policies": [], > "returnByDefault": false, > "pattern": "", > "isVirtual": false, > "type": "string" > } > }, > "required": [], > "order": [ > "brand", > "assetNumber", > "model" > ] > } > } > ``` ## Default values You can specify default values in the managed object configuration *(tooltip: You can edit the managed object configuration over REST at the config/managed endpoint, or directly in the conf/managed.json file.)*. If you omit a default value when creating an object, the default value is automatically applied to the object. You can have default values for the following data types, and arrays of those types: * boolean * number * object * string For example, the default managed object configuration *(tooltip: You can edit the managed object configuration over REST at the config/managed endpoint, or directly in the conf/managed.json file.)* includes a default value that makes `accountStatus:active`, which effectively replaces the `onCreate` script that was previously used to achieve the same result. The following excerpt from the managed object configuration *(tooltip: You can edit the managed object configuration over REST at the config/managed endpoint, or directly in the conf/managed.json file.)* displays the default value for `accountStatus`: ```json "accountStatus" : { "title" : "Status", "description" : "Status", "viewable" : true, "type" : "string", "searchable" : true, "userEditable" : false, "usageDescription" : "", "isPersonal" : false, "policies" : [ { "policyId": "regexpMatches", "params": { "regexp": "^(active|inactive)$" } } ], "default" : "active" } ``` | | | | - | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | IDM assumes all default values are valid for the schema. Although IDM skips policy validation for objects with default values, you can [force validation](policies-over-REST.html#force-validation-default-values) on property values. |