Go to Playbook Main Page
Go back to Design
Go back to Implementation
Naming Standards#
Key Ideas#
Effective naming conventions are critical for maintaining clarity, consistency, and scalability across projects, services, and processes. Adopting well-defined naming standards reduces confusion, simplifies collaboration, and ensures that artifacts are easily understood and managed in multi-environment or multi-team setups.
The following key ideas outline the fundamental principles to consider when creating naming conventions, along with examples and descriptions to guide implementation. These rules aim to enhance readability, enforce standardization, and improve compatibility across various systems and tools.
- Consistency: Stick to the same naming pattern across all projects, services, and processes.
- Modularity: Reflect the purpose or functionality of the artifact in the name.
- Readability: Use PascalCase, camelCase, or snake_case for clarity. Avoid ambiguous abbreviations.
- Abbreviations: Use CAPITAL case for defined abbreviations. Ensure the abbreviation is documented.
- Environment Indicators: Prefix or suffix names with environment indicators for configuration files (e.g., DEV, QA, PROD).
- Avoid Special Characters: Use only alphanumeric characters, underscores (
_), or hyphens (-) to ensure cross-platform compatibility. - Length: Keep names concise but descriptive (usually less than 50 characters).
| Component | Sub-Component | Naming | Example | Description |
|---|---|---|---|---|
| CDI (Cloud Data Integration) | Connection | conn_<projectname>_<type of connection> |
conn_prodex_snowflake | |
| CDI (Cloud Data Integration) | Mapping | m_<Purpose>_<SourceSystem>_<TargetSystem> |
m_deltaLoad_onekey_table | |
| CDI (Cloud Data Integration) | Replication Task | mt_rep_<sourcesystem>_<target>_<objectname> |
||
| CDI (Cloud Data Integration) | Synchronization Task | mt_sync_<sourcesystem>_<target>_<objectname> |
||
| CDI (Cloud Data Integration) | Streaming Task | mt_strm_<sourcesystem>_<target>_<objectname> |
||
| CDI (Cloud Data Integration) | Mapping task | mt_<sourcesystem>_<target>_<objectname> |
Including the project name in the naming convention can enhance monitoring and provide better context for identification and management. | |
| CDI (Cloud Data Integration) | Taskflow | tf_<projectname>_<Purpose> |
||
| CDI (Cloud Data Integration) | Scheduler | <projectname>_<job_frequency> |
prodex_daily_2_pm_cet | |
| :---- | :-------------- | :---------- | :---------- | |
| CAI (Cloud Application Integration) | Process | process_<projectname>_<purpose> |
||
| CAI (Cloud Application Integration) | Process Objects | po_<projectname>_<object_name> |
||
| CAI (Cloud Application Integration) | Service Connector | sc_<projectname>_<purpose> / sc_<projectname>_<SourceSystem>/<TargetSystem> |
||
| CAI (Cloud Application Integration) | App Connector | app_<projectname>_<purpose> / app_<projectname>_<SourceSystem>/<TargetSystem> |
||
| CAI (Cloud Application Integration) | Project | <project name> |
GMA,PRODEX | |
| CAI (Cloud Application Integration) | Folder Naming Convention | Folder name per component or keep everything in single folder | ||
| CAI (Cloud Application Integration) | Scheduler | <projectname>_<process_name> |
prodex_mdm_sequence_number | |
| :---- | :-------------- | :---------- | :---------- | |
| Transformations Object Ports | For Input ports | i_ | ||
| Transformations Object Ports | for Output ports | o_ | ||
| Transformations Object Ports | For Input/Output Ports | io_ | ||
| Transformations Object Ports | For Variable Ports | var_ | ||
| Transformations Object Ports | For returns from lookups | lkp_ | ||
| Transformations Object Ports | For returns from mapplets | mplt_ | ||
| :---- | :-------------- | :---------- | :---------- | |
| Informatica Cloud Object | Source | src_<SOURCE_NAME_<OBJECT> |
||
| Informatica Cloud Object | Target | tgt_<update_types(s)>_<TARGET_NAME> |
||
| Informatica Cloud Object | Sorter | src_<DESCRIPTION> |
||
| Informatica Cloud Object | Aggregator | Agg_<FUNCTION> |
||
| Informatica Cloud Object | Expression | Exp_<FUNCTION> |
||
| Informatica Cloud Object | Filter | Fil_ or Filt_<FUNCTION> |
||
| Informatica Cloud Object | Joiner | Jnr_<DESCRIPTION |
||
| Informatica Cloud Object | Lookup | Lkp_<TABLE_NAME> or suffix with _<descriptor> |
||
| Informatica Cloud Object | Normalizer | Nrm_<FUNCTION> |
||
| Informatica Cloud Object | Router | Rtr_<DESCRIPTION> |
||
| Informatica Cloud Object | Mapplet | Mpl_<DESCRIPTION> |
||
| Informatica Cloud Object | Rank | Rnk_<DESCRIPTION> |
||
| Informatica Cloud Object | Hierarchical Parser | HPc_<DESCRIPTION> |
||
| Informatica Cloud Object | Hierarchical Builder | HBd_<DESCRIPTION> |
||
| Informatica Cloud Object | Java | Jva_<DESCRIPTION> |
||
| Informatica Cloud Object | Sequence Generator | Sqn_<DESCRIPTION> |
||
| Informatica Cloud Object | Transaction Control | Tcl_<DESCRIPTION> |
||
| Informatica Cloud Object | Union | Unn_<DESCRIPTION> |
||
| Informatica Cloud Object | Webservice | Wsv_<DESCRIPTION> |
||
| Informatica Cloud Object | Cleanse | Cln_<DESCRIPTION> |
||
| Informatica Cloud Object | Mask | Msk_<DESCRIPTION> |
||
| Informatica Cloud Object | Deduplicate | Ddp_<DESCRIPTION> |
||
| Informatica Cloud Object | Parse | Prs_<DESCRIPTION> |
||
| Informatica Cloud Object | Rule Specification | Rsp_<DESCRIPTION> |
||
| Informatica Cloud Object | Verifier | Vrf_<DESCRIPTION> |
||
| Informatica Cloud Object | Profile | Profile_<Source>_<Table>_<DESCRIPTION> |
||
| :---- | :-------------- | :---------- | :---------- | |
| Informatica MDM SaaS | Business Entities | <projectname>_<entityname> |
GMA_Party | |
| Informatica MDM SaaS | custom attributes | Use the naming convention X_<attributename> for custom attributes in OOTB entities like Person or Organization when the Customer360 solution is implemented. For entities created in a Multidomain MDM solution, there is no specific naming requirement. |
Out-of-the-box (OOTB) entities come with a pre-defined data model. To differentiate custom attributes from predefined ones, a prefix X_ is used, clearly indicating their custom nature. | |
| Informatica MDM SaaS | Match Rule Set | <ProjectName>_<EntityName>_<MatchType>_<> |
GMA_Party_ExactRule GMA_Party_FuzzyRule |
Use “ExactRule” for Exact Matching Use “FuzzyRule” for Fuzzy Matching |
| Informatica MDM SaaS | Publish Events | Publish_<ProjectName>_<Entityname>_<TargetSystem> |
Publish_GMA_Party_Kafka | The change in order between Source and Entity is intentional, designed to signify the flow of data and ensure clarity in understanding the direction of data exchange. |
| Informatica MDM SaaS | Publish Events | <EventType>_<ProjectName>_<Entityname>_<Condition/AffectedRole> |
Review_GMA_Party_CRUD Review_GMA_Party_DataSteward ManualMergeTask_GMA_Party |
Use “Review” as EventType for User generated Events Use “ManualMergeTask” for System generated Events |
| Informatica MDM SaaS | Ingress Jobs | Ingress_<SourceSystem>_<ProjectName>_<Entityname> |
Ingress_EXD_GMA_Party | If there is more than one source system table being loaded to the same entity, add that table name after the source name |
| Informatica MDM SaaS | Egress Jobs | Egress_<ProjectName>_<Entityname>_<SourceSystem> |
Egress_GMA_Party_EXD | The change in order between Source and Entity is deliberate, intended to highlight the difference in the direction of the data flow and provide clarity in understanding the integration process. |
| Informatica MDM SaaS | Generate Index | GenerateIndex_<ProjectName>_<Entityname> |
GenerateIndex_GMA_Party | If all entities are being regenerated at once, use “All” instead of the entity name. GenerateIndex_ |
| Informatica MDM SaaS | Match and Merge | <JobType>_<ProjectName>_<Entityname>_[RuleSetName]* |
MM_GMA_Party_FuzzyRule Reset_GMA_Party GenerateTasks_GMA_Party |
For Match & Merge, use prefix “MM”. For Match only, use “Match”. For Merge only, use “Merge”. For Resetting records, use “Reset”. For Generating Merge Task, use “GenerateTasks” *For Match & Merge and Match Job Type, add the Match Rule Set. |
| Informatica MDM SaaS | Source Systems | <Source_System> |
ExD | Since the source system can be shared across multiple entities and projects, its naming does not require any distinguishing factor, ensuring simplicity and consistency across the architecture. |
| Informatica MDM SaaS | User Roles | <Service>_<Region*>_<Role> |
MDM_EU_DataSteward MDM_Tester |
In cases where a region is not applicable, use the naming convention service_Role to ensure clarity and alignment with the function or responsibility of the service. |
| Informatica MDM SaaS | Data Access Rules | DA_< ProjectName>_<Entityname>_<Allow/Deny>_<RoleName> |
DA_GMA_Party_Allow_MDMUSDataSteward | |
| Informatica MDM SaaS | Data Quality (DQ) Rules | Object names should start with the prefix RS_, followed by the corresponding MDM field name being modified and a descriptor that highlights the nature of the check being performed.If the check is only used for one type of entity, add the entity name between the “RS_” and the field name. If used for the same field in multiple entities, leave the entity name out. (Applicable for Reusable components) Examples: RS_GMA_Party_FullName_Standardized This rule specification will be associated with the Party entity, targeting the FullName field to ensure the value is standardized as per defined criteria. RS_Phone_Number_Format |
||
| This rule specification will be applied to the phone number field in any applicable entity to ensure proper formatting and standardization of phone numbers. | Cloud Data Quality assets are used in mappings to load data into MDM and can also be attached to business entity fields using Rule Specifications, whereas for CDI mappings, all types of DQ assets (e.g., Verifier, Dictionary, Cleanse, Parse, Profiles) can be used. Refer to Naming Conventions – MDM SaaS and use ProjectName_EntityName in place of EntityName. |
Go to Playbook Main Page
Go back to Design
Go back to Implementation