• Success
    Manage your Success Plans and Engagements, gain key insights into your implementation journey, and collaborate with your CSMs
    Success
    Accelerate your Purchase to Value engaging with Informatica Architects for Customer Success
  • Communities
    A collaborative platform to connect and grow with like-minded Informaticans across the globe
    Communities
    Connect and collaborate with Informatica experts and champions
    Have a question? Start a Discussion and get immediate answers you are looking for
    Customer-organized groups that meet online and in-person. Join today to network, share ideas, and get tips on how to get the most out of Informatica
  • Knowledge Center
    Troubleshooting documents, product guides, how to videos, best practices, and more
    Knowledge Center
    One-stop self-service portal for solutions, FAQs, Whitepapers, How Tos, Videos, and more
    Video channel for step-by-step instructions to use our products, best practices, troubleshooting tips, and much more
    Information library of the latest product documents
    Best practices and use cases from the Implementation team
  • Learn
    Rich resources to help you leverage full capabilities of our products
    Learn
    Role-based training programs for the best ROI
    Get certified on Informatica products. Free, Foundation, or Professional
    Free and unlimited modules based on your expertise level and journey
    Self-guided, intuitive experience platform for outcome-focused product capabilities and use cases
  • Resources
    Library of content to help you leverage the best of Informatica products
    Resources
    Most popular webinars on product architecture, best practices, and more
    Product Availability Matrix statements of Informatica products
    Monthly support newsletter
    Informatica Support Guide and Statements, Quick Start Guides, and Cloud Product Description Schedule
    End of Life statements of Informatica products
Last Updated Date Dec 16, 2022 |

Challenge

A variety of factors are considered when assessing the success of a project. Naming standards are an important but often overlooked component. The application and enforcement of naming standards not only establishes consistency in the repository but provides for a developer-friendly environment. Good naming standards ensure the MDM SaaS repository can be easily understood and easily accessed by all developers.

Description

Implementing standard naming conventions facilitates smooth migrations and improves readability for anyone reviewing or carrying out maintenance on IDMC platform assets. It can help in understanding the processes that are affected. If consistent names and descriptions are not used, significant time may be needed to understand the workings of mappings and transformation objects. If no description is provided, a developer is likely to spend considerable time going through an object or mapping to understand its objective.

This document offers standardized naming conventions for various IDMC platform assets used for MDM SaaS. Whatever convention is adopted, it is important to make the selection very early in the development cycle and communicate the convention to the project team. The policy can be enforced by peer review and at test phases by adding processes to check conventions for testing plans and for testing execution documents.

MDM SaaS Naming Standards

Business Entities

In Customer 360 (C360) SaaS, the naming conventions for new groups and fields for an existing entity are somewhat enforced.  When working in MDM SaaS, since there are no existing entities, a naming convention is more important.

Compared to the MDM Multidomain Hub, the length of entity and field names in MDM SaaS is a generous 255 characters. There is less of a need to shorten names by removing vowels. Therefore, use reasonable terms with no abbreviations for entity names.

The suggested naming standards are:

Object

Display Name

Physical Name

Entity

The display names should have a meaning to the business users, such as for the data stewards. Where possible this name should be the full unabbreviated name and in title case capitalization.

Spaces, dashes, and underscores are allowed.

The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_).

Entity Field Groups

The display names should have a meaning to the business users, such as for the data stewards. Where possible this name should be the full unabbreviated name and in title case capitalization. 

To emphasize the repeating nature, the name should be in the plural form (e.g., Addresses instead of Address.)

Spaces, dashes. and underscores are allowed.

The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_).

Entity Fields

The display names should have a meaning to the business users, such as for the data stewards. Where possible this name should be the full unabbreviated name and in title case capitalization. 

If the field is in a group, there is no requirement to prefix or suffix the field name with something to represent the field group and distinguish the field from another in another field group.

 

For example, Field Groups of Addresses and Phones each have a Start Date field. It is not required to name the fields Addr_Start_Date and Phone_Start_Date.

The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_).

 

Fields in a group field will be referenced using the Group Name in JSON and XML (e.g.  Addresses.Address Line 1).

Job Definitions

In C360 SaaS, Job Definitions are used to execute MDM processes like loading data into MDM (ingress) and extracting data out of MDM (egress).  Other jobs include generating search indexes, match & merge, generate merge tasks, and publishing events.

The suggested naming standards are:

Object

Display Name

Physical Name

Ingress job

The display names should start with “Ingress”, followed by the name of source system and then the business entity being loaded.

If there is more than one source system table being loaded to the same entity, add that table name after the source name.

Spaces, dashes, and underscores are allowed.

Examples:

Ingress Salesforce Organization – this would load data from Salesforce into the Organization table.

Ingress Salesforce Contact Person and Ingress Salesforce Lead Person would both extract data from different Salesforce tables to load into the MDM Person entity.

The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_).

Egress job

The display name should start with “Egress”, followed by the business entity being extracted and then the name of the source or consuming system.

If there is more than one target in the source or consuming system, it is not necessary to have different job definitions. Entity data should be extracted from MDM once, and then bifurcated in the CDI mappings to two (or more) target tables.

Spaces, dashes, and underscores are allowed.

Examples:

Egress Organization Salesforce – this would extract data from the Organization entity and update the Salesforce system.

Ingress Person Salesforce – this would extract data from the Person entity and update both the Contact and Lead tables in Salesforce.

The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_).

Generate Index

The display names should say “Generate Index” followed by the business entity name. 

If all entities are being regenerated at once, use “All” instead of the entity name.

Example:

Generate Index Organization

Generate Index Person

Generate Index All

The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_).

Match & Merge

The display name should start by indicating which process is running, followed by the Entity Name. For Match & Merge and Match, add the Match Rule Set. 

For Match & Merge, use prefix “MM”.

For Match only, use “Match”. 

For Merge only, use “Merge”.

For Resetting records, use “Reset”.

Examples:

MM Person Initial Rules

Match Organization USRules

Merge Organization

Reset Person

The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_).

Generate Merge Tasks

The display name should say “Generate Tasks” followed by the business entity name. 

Example:

Generate Tasks Organization

The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_).

Publish Events

The display name should say “Publish to ” followed by the target system name.

Example:

Publish to Salesforce

The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_).

Cloud Data Quality

Cloud Data Quality assets are used in mappings to load data into MDM and are also attached to business entity fields.

To be attached to a business entity field, a Rule Specification must be used. For CDI mappings, all types of DQ Assets can be used.

Suggested naming standards for those assets are listed below.

Object

Display Name

Physical Name

Rule Specification

Object name should begin with “RS_”, and then identify the MDM field name being altered and indicate something about the nature of the check. 

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.

Examples:

RS_org_name_standardized

This rule spec would be attached to the MDM Organization field name for the purpose of standardizing the value. 

RS_phone_number_format

This rule spec would be attached to the phone number field in both the Organization and Person entities to properly format the phone number.

The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_).
Verifier

Object name should begin with “Verify” and then be followed with what is being validated.

Examples:

Verify_address

Verify_email

The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_).
Dictionary

Object name should begin with “Dictionary_” and then be followed by the name of the object which is using it.

If more than one object uses it, then refer to the contents of the dictionary

Examples:

Dictionary_rs_org_name_standardized (for the Rule Spec attached to the org name field)

Dictionary_name_noise_words  (for use by multiple fields)

The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_).
Cleanse

Object name should begin with “Cleanse_” and then be followed by the name of what data element is being cleansed.  Use underscores.  Uppercase first letter only.

Examples:

Cleanse_address_line1

Cleanse_corporate_name

The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_).
Parse

Object name should begin with “Parse_” and then be followed by the name of what data element is being parsed.  Use underscores.  Uppercase first letter only.

Examples:

Parse_full_name

Parse_delivery_addr_line1

The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_).

Profiles

Profiles name should begin with “Profile_”, and then indicate the name of the entity field being profiled. Next, the name should identify the source system and which source object (table) is being used. 

Example:

Profile_address_salesforce_account

The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_).

 

Cloud Data Integration Mappings

In the IDMC platform, MDM SaaS operations rely on assets built in other services – Cloud Data Integration (CDI), Data Quality (CDQ), Cloud Application Integration (CAI) – to get data in and out of MDM. Applying naming standards to those assets will help to identify them as being used with MDM SaaS, versus being used for other applications.

CDI Mappings, Mapping Tasks, Taskflows

CDI Mappings are required to process data in bulk to and from MDM.. Those Mappings are executed using Mapping Tasks and Taskflows. 

Suggested naming standards for those assets are listed below.

Object

Display Name

Physical Name

Mapping

Mapping name should begin with “m_”, and then indicate whether data is going into or out of MDM SaaS by using “in_” or “out_”.  Next, the name should identify the source system and which source object (table) is being used.  

Examples:

m_in_salesforce_account would be the mapping to extract data from the Salesforce source’s account table and bring it into MDM.

m_out_marketo_contact would be the mapping to extract data from MDM and send to the Marketo source’s Contact table.

The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_).

Mapping Task

These should follow the same standards as the Mapping, except the prefix is “mt_” instead of “m_”.

Examples:

mt_in_salesforce_account

mt_out_marketo_contact

The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_)
Taskflow

These should follow the same standards as the Mapping, except the prefix is “tf_” instead of “m_”.

Examples:

tf_in_salesforce_account

tf_out_marketo_contact

The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_)

Cloud Application Integration

Cloud Application Integration assets can be used to create an orchestration workflow for running the MDM SaaS Ingress and Egress processes.

Processes, Service Connectors, App Connectors

Suggested naming standards for those assets are listed below.

Object

Display Name

Physical Name

Process

Process names should begin with “p_”, and then indicate the action that is being performed. Next, the name should identify the source system and which source object (table) is being used. 

Example:

p_FullRun_SalesforceAccount

The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_).

Service Connector

Service Connector names should begin with “svc_”, and then indicate to which system or application it is connecting.

Example:

svc_B360SaaS

The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_).

App Connector

App Connector names should begin with “app_”, and then indicate to which system or application it is connecting.

Example:

app_B360SaaS

The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_).
Service

Service names should be descriptive and the same as the action name as defined in the service connector.

Example:

app_B360_Login

app_B360_Get_Person

app_B360_Search_Org

The system will automatically create a physical name by converting display name to lower case and replacing spaces and dashes with underscores (_).

Table of Contents

Success

Link Copied to Clipboard