Purpose of the "Identification number" field on Customer Account

[luishuallpa]

Hi everyone,

I'm reviewing the out-of-the-box Identification number field (identification_number) on the Customer Account (customer_account) table.

From the dictionary, it appears to be a simple String field with no reference, choice list, calculated value, or obvious business logic associated with it.

I'm trying to understand whether this field has any specific OOTB purpose in CSM or other ServiceNow applications.

Specifically:

• Is this field used by any standard CSM processes, integrations, or workflows?
• Is it intended to store a legal/business identification number (e.g., VAT, EIN, etc), or is it simply a generic identifier?

Context: In our implementation, we need to store an identifier for Customer Accounts that is not always numeric. For example, we have financial institution identifiers (FIIDs) such as BPPR, FFSB, EURO, C001, etc. Since this field is a String, we're considering using it to store these values instead of creating a custom field. Before doing so, we'd like to confirm whether using this OOTB field for that purpose could conflict with any standard ServiceNow functionality.

Any documentation or experience with this field would be greatly appreciated.

Regards.

[Siddhesh Jadhav · Accepted solution]

Hi @luishuallpa 

From what I've seen, identification_numberon the customer_account table is essentially an OOTB String field with no special platform behavior attached to it. I haven't come across any standard CSM processes or workflows that rely on this field out of the box.

It appears to be provided as a generic external/business identifier, so organizations often use it for values such as VAT numbers, EINs, company registration numbers, or other enterprise-specific identifiers. Since it's a String field, it can also accommodate alphanumeric values.

For your FIIDs (e.g., BPPR, FFSB, EURO, C001), the field would technically work without any issues from a data type perspective.

The only consideration I would have is the business meaning. If the FIID is the primary identifier for the Customer Account in your organization, then reusing the OOTB identification_number field seems reasonable. However, if you expect to store a legal/business identifier (VAT, EIN, etc.) in the future as well, I'd lean toward creating a separate custom field for the FIID to keep the data model clear.

Before reusing the field, I'd also recommend doing a quick search in your instance (Business Rules, Flows, Script Includes, Client Scripts, etc.) for identification_number to make sure no customizations or installed applications are already using it.

Overall, I don't believe there's any OOTB CSM functionality that would conflict with using this field, but it's always worth validating within your own instance and plugins.

Thanks and regards
Siddhesh Jadhav

I hope this helps! If it answers your question, please consider marking it as Helpful and Accepted so it can assist other community members as well.