This article gives the best practices for naming your objects in xDM when using the Application Builder or the Dashboard Builder. It helps to have a common naming convention for the team in charge of designing dashboards, models, and applications.

You will find 3 types of names and labels in xDM :

  • Internal Names (Also called Names) are the unique name for each object type. They can only contain alphanumeric characters, underscores and must start with a letter.
    • They should be meaningful, refer to the below table lists for typical samples.
    • Do not try to shorten names excessively. They may become meaningless. For example, using CustAccMgr instead of CustomerHasAccountManager is not advised.
    • Define team naming conventions that accelerate object type identification. For example, types and lists of values can be post-fixed with their type such as GeocodedAddressType, GenderLOV.
  • Physical Names and Prefixes are used to create the objects in the database corresponding to the logical object. These can only contain uppercase characters and underscores.
  • Labels and Descriptions are visible to the end-users. They should remain user-friendly and meaningful.
Note: Semarchy xDM tries as much as possible to derive labels from names (or vice versa) thanks to the autofill feature.
To derive labels from names, xDM uses a Camel Case convention: typing the following name: EmployeeHasManager generates the label Employee Has Manager

Naming conventions for Application Builder

Data model objects

Data model objects will be used by data architects only. They refer to all objects available in entities and attribute types.

ModelModelNameStoresAndSuppliersMDM, ItemCatalog
EntityEntityNameSingularProduct, Item, Customer
Reference Role ToRoleNameSingularManager
Reference Role FromRoleNamePluralManagedEmployees
Complex TypeComplexTypeNameTypeAddressType
User-Defined TypeTypeNameTypeSimpleStringType
List Of ValuesLOVNameLOVCurrencyLOV, ProductTypesLOV

User interface objects

User interface objects will be visible by data architects and end-users. They refer to all objects used for creating the UI.

FormFormNameFormDefaultForm, ProductAuthoringForm, ProductReviewForm, MediaSimpleForm, ItemsMainAttributesForm
CollectionCollectionNameCollectionDefaultCollection, AllAttributesCollection
Business ViewBusinessViewName[Classification]Products, ProductsByCategory, EmployeeHierarchy
Transition NameReferenceRoleFromManagedEmployees
StepperAuthorEntityNamePluralAuthorProducts, AuthorCustomers
Stepper Collection StepEntityNamePlural or ReferencingRoleNameProducts, Customers, RelatedItems
Stepper Form StepEntityNameProduct, Customer, Item
Action SetPurposeActionSetCustomerActionSet, ProductImportExportActionSet, ProductCreateEditActionSet
ApplicationApplicationNameProductSearch, ProductDesign, ReferenceDataManagement
WorkflowWorkflowNameCreateOrModifyCustomers, InitiateFullProductCreation, RequestProductLabelChange
Workflow TaskTaskPurposeCreateProductBasicInformation, AddTechnicalDetailsForProduct, VerifyProductCreationGuidelines
Workflow TransitionTransitionActionSendDataForApproval, RejectRequestAndAskForMoreInformation, AcceptAndSendToMarketing

Other model objects

Publisher (Code)CODEMDM
Publisher (Name)PublisherNameMDM Application

Naming conventions for Dashboard Builder

Dashboard mostly derives names for labels. This enables you to create complex labels with special characters. The following naming convention gives some ideas on how names could look like if you don't want them to derive directly from labels.

Dashboard appDashboardAppNamePulseProfiling, DataHub
DatasourceDataSourceNameTypeCustomerSourceData, ProductProfiling, ProductHub, Repository
QueryQueryNameCustomerMatching, ProductDataQuality
ChartChartNameTypeCustomerMatchingBar, ProductDataQualityDonut
DashboardDashboardNameDashboardDataQualityDashboard, ProfilingDashboard
SlicerAttributeNameSlicerDateSlicer, CustomerStatusSlicer