Entity Specification
An Entity Specification (also called Configuration Profile in the tSM UI) defines a subtype of a business entity by grouping Characteristics into a coherent set. It is the primary mechanism for distinguishing between, for example, a Retail Customer and a Wholesale Customer — both are Customer entities, but each has a different Entity Specification with different dynamic attributes, forms, and rules.
What it's for
- Subtype definition — create meaningful subtypes (specifications) for any EntityType.
- Dynamic attributes — bundle one or more Characteristics that define the extra fields for the subtype.
- Form assignment — assign default forms for create, detail, list, and other UI contexts.
- Supporting entity rules — control which attachment types, comment types, worklog types, and notification types are allowed.
- Access control — optionally link an access policy for row-level security.
Entity Specifications are first-class configuration entities — they have validity, localization, audit trail, and can be organized with dataTags and configType.
According to the TM Forum standard, this entity is called EntitySpecification. The tSM API and backend use this name. The tSM UI refers to it as Configuration Profile for user-friendliness.
For the architectural context, see Entities & Characteristics.
Key concepts
Characteristics binding
The characteristics field holds a list of Characteristics codes that this Entity Specification includes. When an entity is created with this specification, the platform renders and validates the corresponding forms for each characteristic.
For finer control, the characteristicsSpecification list provides per-characteristic overrides:
| Field | Type | Description |
|---|---|---|
id | UUID | Unique identifier. |
characteristicCode | String | Code of the referenced Characteristics. |
config | Map | Per-specification configuration overrides for this characteristic. |
defaultValue | String | Default value for this characteristic within this specification. |
regexp | String | Validation regex override for this specification. |
description | String | Description override for this specification context. |
auditInfo | Object | Standard audit metadata. |
This allows the same Characteristics to behave differently in different Entity Specifications — for example, a contactEmail characteristic might be required in a Retail Customer specification but optional in a Wholesale Customer specification.
EntityType binding
The entityType field (FK EntityType.code) declares which "class" of records this specification applies to. Common examples:
| EntityType | Example specifications |
|---|---|
Customer | Retail, B2B, Wholesale, Internal |
Ticket | Incident, Service Request, Change Request |
Order | SDWAN Provisioning, Fiber Installation |
Product | Internet Access, VoIP, IPTV |
Form specification (formSpecification)
The formSpecification map assigns default forms to UI contexts:
{
"new": "customer-retail-new",
"detail": "customer-retail-detail",
"list": "customer-retail-list",
"card": "customer-retail-card"
}
Keys are context identifiers (e.g., new, detail, list, card), and values are Form codes.
Supporting entity rules
Entity Specifications can restrict which types of supporting entities are allowed:
| Field | Description |
|---|---|
attachmentTypes | List of allowed attachment type codes. |
attachmentTypeAllowEmpty | If true, entities can exist without attachments. Default true. |
commentTypes | List of allowed comment type codes. |
commentTypeAllowEmpty | If true, comments without a type are allowed. Default true. |
defaultCommentType | Default comment type code for new comments. |
worklogTypes | List of allowed worklog type codes. |
worklogTypeAllowEmpty | If true, worklogs without a type are allowed. Default true. |
notificationTypes | List of allowed notification type codes. |
notificationTypeAllowEmpty | If true, notifications without a type are allowed. Default true. |
Access policy
The optional accessPolicyCode field links to an access policy that enforces row-level security — only users matching the policy can view or edit entities with this specification.
Mnemonic code
The optional mnemonicCode field (FK MnemonicConfig.code) links to a mnemonic configuration for automatic business key generation for entities of this specification.
Expanded characteristics
When requesting an Entity Specification via API with the CHARACTERISTICS expand key, the expandedCharacteristics field is populated with the full Characteristics objects (including their Forms), avoiding additional API calls.
Reference
Entity Specification (attributes)
| Field | Type | Required | Read-only | Description / Notes |
|---|---|---|---|---|
id | UUID | – | – | Identifier (not for end-user display). |
code | String | Yes | – | Unique ASCII code (no spaces). Used to reference the specification from entities and API. |
name | String | Yes | – | Human-readable name shown in admin UI. |
description | String | – | – | Optional tooltip / longer description. |
configType | String | – | – | Business package this specification belongs to (FK ConfigType.code). |
entityType | String | – | – | Code of the EntityType this specification applies to (FK EntityType.code). |
characteristics | List | – | – | List of Characteristics codes included in this specification. |
characteristicsSpecification | List | – | – | Per-characteristic overrides (default value, regex, config). See section above. |
formSpecification | Map | – | – | Default forms for UI contexts (new, detail, list, card, …). |
attachmentTypes | List | – | – | Allowed attachment type codes. |
attachmentTypeAllowEmpty | Bool | – | – | Allow entities without attachments. Default true. |
commentTypes | List | – | – | Allowed comment type codes. |
commentTypeAllowEmpty | Bool | – | – | Allow comments without a type. Default true. |
defaultCommentType | String | – | – | Default comment type for new comments. |
worklogTypes | List | – | – | Allowed worklog type codes. |
worklogTypeAllowEmpty | Bool | – | – | Allow worklogs without a type. Default true. |
notificationTypes | List | – | – | Allowed notification type codes. |
notificationTypeAllowEmpty | Bool | – | – | Allow notifications without a type. Default true. |
accessPolicyCode | String | – | – | Access policy for row-level security. |
mnemonicCode | String | – | – | Mnemonic configuration for business key generation (FK MnemonicConfig.code). |
config | Map | – | – | Additional general configuration. |
dataTags | List | – | – | Labels for grouping and filtering. |
validityFrom/To | Date | – | – | Optional validity window. |
valid | Bool | – | Yes | Computed from validity; true when within the validity interval. |
localizationData | Object | – | – | Translations for name / description. |
auditInfo | Object | – | Yes | Standard audit metadata. |
expandedCharacteristics | List | – | Yes | Full Characteristics objects (populated only with CHARACTERISTICS expand). |
Good Practices
- Stable
code— entity instances store their specification code; renaming breaks existing data. - One specification per meaningful subtype — don't over-split (one spec per process variant) or under-split (one spec for all). Match business categories.
- Assign
configType— always set a ConfigType so the specification appears in the correct business package for governance and navigation. - Set
entityTypeexplicitly — even though it's optional in the API, always specify it so the platform can properly route and filter specifications. - Configure supporting entity rules — restrict attachment, comment, and worklog types to what makes business sense. This prevents data quality issues.
- Use
formSpecification— assign context-specific forms (new,detail,list) for a polished user experience rather than relying on defaults. - Leverage
characteristicsSpecification— use per-specification overrides (default values, validation regex) to tailor shared Characteristics to specific business contexts. - Provide
mnemonicCode— for entities that need human-readable business keys (e.g., ticket numbers, order IDs), configure a mnemonic. - Tag consistently — use
dataTagsto categorize specifications (core,integration,pilot).
See Also
- Characteristics — the dynamic attributes grouped by this specification.
- Form — the JSON Schema backing each characteristic and the forms assigned to UI contexts.
- EntityType — the entity class this specification applies to.
- ConfigType — business packaging for configuration entities.
- Custom Entities — Custom Entities use Entity Specifications for their dynamic attributes.
- Entities & Characteristics (Architecture) — conceptual overview of the TM Forum pattern.