EntityType

EntityType is the canonical classification of a record in tSM (e.g., Customer, Ticket, Order, Attachment).
Together with an entity’s ID, it forms a universal reference used by UIs, processes, integrations, and cross-module links.

Business value:

• Consistent behavior — drives which forms, characteristics, rules, and widgets apply to a record.
• Cross-module linking — powers generic relationships like ownerType / refType (e.g., an Attachment with ownerType="Ticket").
• Discoverability & routing — ties an entity to its microservice and public API.
• Presentation — provides iconography and card/list widgets for a coherent UI.

Think of EntityType as the “class” of your records. Everything else (forms, listings, actions) composes on top of it.

---

Typical Uses

• Global references across modules: store ownerType="Ticket" + ownerId="019a7265-821f-70db-b8fe-f16e300ea061" to relate supporting entities (comments, attachments, …).
• UI composition: choose card profile, listing widget, and icon based on the type for consistent rendering.
• API discovery: resolve or override the public API URL for a type.
• Governance: use validity to soft-enable/disable types in environments or during migrations.
• Tagging & config: attach small bits of typed configuration and labels for admin tools and dashboards.

---

Examples

Entity	EntityType	Description
Ticket TCKT-123	Ticket	Service request/incident
Customer C001	Customer	Business or residential customer
Attachment A55	Attachment	File linked to another entity

Related concepts:

• Entity specification / profile — subtype rules and UI configuration per type.
• Characteristics — dynamic attributes bound to a type.
• ownerType / refType — use the EntityType string to establish relationships system-wide.

---

Reference

EntityType (attributes)

Field	Type	Required	Read-only	Description / Notes
id	UUID	–	–	Identifier (not intended for end-user display).
code	String	Yes	–	Unique ASCII code (no spaces). Used everywhere (links, rules, configs).
name	String	Yes	–	Display name shown in admin UI.
microservice	String	Yes	–	Code of the Microservice where this entity lives (routing & ownership).
publicApiUrl	String	–	–	Optional override of the entity’s public API path relative to the microservice backendUrl. If not set, it’s derived from the entity code (kebab-case, plural).
defaultCardProfile	String	–	–	UI card profile to render entity details by default.
listingCardWidget	String	–	–	UI component used to render items of this type in lists.
icon	String	–	–	Icon identifier used in the UI.
description	String	–	–	Longer description / tooltip.
validityFrom/To	Date	–	–	Time window when the type is considered active.
valid	Bool	–	Yes	Computed from validity; not stored.
abbreviation	String	–	–	Short label for compact UI (must be unique if used).
config	Map	–	–	Free-form, small configuration for admin/UI tooling (not a deployment substitute).
dataTags	List	–	–	Labels for grouping/reporting (e.g., core, customer, ticketing).
localizationData	Object	–	–	Translations for name / description.
auditInfo	Object	–	–	Standard audit metadata.

---

Good Practices

• Keep code stable — it becomes a key in references (ownerType, refType), configs, and API routing.
• Set microservice correctly — drives discovery and helps tools find the right backend.
• Prefer derived publicApiUrl unless you need a custom path; keep it relative to the microservice backendUrl.
• Define UI hints (defaultCardProfile, listingCardWidget, icon) so lists and cards look consistent across the platform.
• Use dataTags to group types in admin screens and reports (e.g., support, crm, files).
• Leverage validity to phase in/out types without schema changes.

---

See Also

• System Settings: Microservice — where the backends are registered
• System Settings: Module — business-domain grouping that consumes entity types
• Supporting Entities – Overview — how ownerType / refType reference entity types across modules