CSM- identifying the risks associated with not using the OOTB Contact table (customer_contact)

[AlokS]

Hi All,

From customer have been suggested to create a custom "Customer Contact" table instead of utilizing the existing OOTB Contact table (customer_contact) for the following reasons:

Want asked us to build a custom "Customer Contact" table instered on going with OOTB Contact table (customer_contact) table due to following reasons :

1. Customer do not wish to include unregistered customers in the OOTB Contact table.
2. Internal users also function as customers, and they share the same email address in both the User and Contact tables, which causes issues since their SSO is dependent on the email address.

Please help us in identifying the risks associated with not using the OOTB Contact table (customer_contact) and opting to develop a custom Customer Contact table.

[Dan682Lee]

Hello!

Building a custom Customer Contact table instead of using the OOTB customer_contact table risks losing built‑in integrations, creating duplicate or inconsistent data, adding maintenance overhead, and limiting compatibility with upgrades or third‑party apps. While it may solve issues like excluding unregistered customers or handling internal users with shared emails, it sacrifices standard functionality and increases long‑term complexity. A safer approach is usually to extend or configure the OOTB table rather than replace it. 

[vaishali231]

hey @AlokS 

These following  risks associated with this -

OOTB CSM features may break
Many CSM functions (Case creation, contact lookups, portal “My Cases”, account-contact relationships) are built to work with customer_contact. Custom table will need extra scripting.

Higher upgrade risk
Future ServiceNow upgrades enhance customer_contact. Custom tables won’t automatically get these updates - more regression testing + fixes after upgrades.

More portal & access customization
CSM portal security and case visibility rules expect standard Contact model. Custom table increases risk of access issues and extra development.

Integration complexity increases
Email-to-case, APIs, and integrations often assume customer_contact. Custom table requires custom mappings and maintenance.

Reporting limitations
OOTB dashboards/reports may not work, requiring custom reporting.

Data duplication & maintenance overhead
You may end up managing contacts across sys_user, customer_contact, and the custom table - duplicates and sync issues.

*************************************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh

[vaishali231]

hey @AlokS 

Hope you are doing well.

Did my previous reply answer your question?

If it was helpful, please mark it as correct ✓ and close the thread . This will help other readers find the solution more easily.

Regards,
Vaishali Singh