Semarchy xDM naming convention

When designing a logical model, it is necessary to adhere to a naming convention to ensure the model is easily understandable and implemented cleanly.
In xDM, various names and labels are used across objects:

  • Internal names (called names): these are primarily for use by model designers and must be unique within the model. They can only contain alphanumeric characters and underscores, and must start with a letter.

  • Physical names and prefixes: used to create objects in the database corresponding to logical objects. These names can only include uppercase characters and underscores.

  • Labels and descriptions: visible to users (including end-users and data stewards) interacting with data through the UI. These labels and descriptions are user-friendly, and can be edited during later stages of design. They are externalized and can be localized (i.e., translated) within the platform.

Here are some tips for naming objects in xDM:

  • Use meaningful internal names. For exemple, name reference relationships following the pattern <entity name><relationship verb><entity name>, like CustomerHasAccountManager.

  • Avoid excessively shortening internal names, as they may lose meaning. For instance, using CustAccMgr instead of CustomerHasAccountManager is not recommended.

  • Use PascalCase for internal names to facilitate auto-fill features (e.g., ContactBelongsToCustomer, GeocodedAddressType).

  • Establish team naming conventions to quickly identify object types. For example, suffix types and lists of values with their respective type, like GeocodedAddressType, GenderLOV.

  • Define user-friendly labels and descriptions. While internal names are for model designers, labels and descriptions are primarily for end users.

The following table lists a typical naming convention you can adapt to your project.

Object Name pattern Examples

Model

[Model Name]

StoresAndSuppliersMDM, ItemCatalog

Entity

[Entity Name]

Product, Item, Customer

Attribute

[Attribute Name]

IsProductAvailable

Reference

[From Entity]Has[To Entity][Role]

EmployeeHasEmployeeManager

Reference Role To

[Role Name In Singular]

Manager

Reference Role From

[Role Name In Plural]

ManagedEmployees

Complex Type

[ComplexType Name]Type

AddressType

User-Defined Type

[Type Name]Type

SimpleStringType

Publisher (Code)

[CODE]

MDM

Publisher (Name)

[Publisher Name]

MDM Application

Job

[JOB_NAME][JOB_TYPE]

INITIAL_LOAD_FULL, CERTIFY_PRODUCT_SIMPLE

Form

[Form Name or Kind]Form

DefaultForm, ProductAuthoringForm, ProductReviewForm, MediaSimpleForm, ItemsMainAttributesForm

Collection

[Collection Name or Kind]Collection

DefaultCollection, AllAttributesCollection

List Of Values

[LOV Name]LOV

CurrencyLOV, ProductTypesLOV

Business View

[Business View Name]([optional Classification])

Products, ProductsByCategory, EmployeeHierarchy

Transition Name

[Reference Role From]

ManagedEmployees

Stepper

Author[Entity Name]s

AuthorProducts, AuthorCustomers

Stepper Collection Step

[Entity Name]s or [Referencing Role Name]

Products, Customers, RelatedItems

Stepper Form Step

[Entity Name]

Product, Customer, Item

Action Set

[Action Set Name Or Purpose]ActionSet

CustomerActionSet, ProductImportExportActionSet, ProductCreateEditActionSet

Application

[Application Name]

ProductSearch, ProductDesign, ReferenceDataManagement

Folder

[Folder Name]

ProductsManagement

Workflow

[Workflow Name]

CreateOrModifyCustomers, InitiateFullProductCreation, RequestProductLabelChange

Workflow Task

[Task Purpose]

CreateProductBasicInformation, AddTechnicalDetailsForProduct, VerifyProductCreation

Workflow Transition

[Transition Verb/Action]

SendDataForApproval, RejectRequestAndAskForMoreInformation, AcceptAndSendToMarketing