Multicurrency choice list implementation

[MalakaSilva]

Hi Community,

I have a requirement to add a Currency Code field to a custom table. The field only needs to store the ISO 4217 alphabetic currency code, for example:

USD
EUR
GBP
LKR
I know ServiceNow has the Currency [fx_currency] table, which contains currency-related information, including currency codes. Standard currency fields also use three-letter ISO currency codes.

My question is:

Is there a standard/best-practice way to populate a custom field with the ISO 4217 currency codes available in ServiceNow?

For example, would it be better to:

Create a Choice field and manually maintain the ISO currency codes, or
Create a Reference field pointing to the Currency [fx_currency] table, or
Use another standard ServiceNow mechanism/API?
The goal is to avoid manually maintaining the complete list of ISO currency codes if ServiceNow already provides a standard way to reuse them.

Any recommendations or best practices would be appreciated.

Thanks!

[musislam · Accepted solution]

Hi MalakaSilva,

Option 2 - reference to fx_currency. Do not hand-maintain a choice list; the table already carries the full ISO 4217 set and ServiceNow maintains it for you.

I checked on an Australia instance to give you real numbers rather than a guess. fx_currency holds 138 rows, with:

- code - the ISO 4217 alphabetic code (USD, EUR, GBP, LKR)

- numeric_code - the ISO 4217 numeric code (840, 978, 826, 144)

- name, symbol, active, description

All four of your examples are there out of the box, LKR included.

Why the reference wins:

The display value on fx_currency is already the code field, so a reference field renders as USD / EUR / GBP / LKR in the UI with no extra configuration - you do not need to touch the display column or build a display value. You also get referential integrity, zero maintenance as ISO changes, and the numeric code and symbol available by dot-walking whenever you need them.

The one gotcha that would otherwise cost you an afternoon:

Only 5 of those 138 are active out of the box - CHF, EUR, GBP, JPY and USD. LKR is in the table but inactive. So if you put an active=true reference qualifier on your field, or anything else filters on active, you will open the picker, see five currencies, and reasonably conclude the table is not fit for purpose. Either activate the currencies you actually need, or leave the qualifier off entirely.

If the column genuinely has to hold the letters:

A reference field stores the sys_id in the database, not "USD". That is normally fine - you dot-walk .code wherever the string is needed and integrations read it the same way. But if the column itself must contain the three characters (flat-file export, an external system reading the table directly), then either:

- keep the reference field and add a read-only string field populated from it by a business rule, so you keep the integrity and still get the literal code in a column, or

- generate sys_choice records from fx_currency with a one-off script and use a plain choice field. It works, but you now own a copy of the ISO list and it will drift from the source. I would only take this route if the first is genuinely blocked.

One thing to rule out since you mentioned standard currency fields: the Currency and Price field types store an amount together with a currency, in the form USD;100.00. If you only want the code and never an amount, they are the wrong tool - sounds like you had already reached that conclusion, but worth stating.

So: reference field to fx_currency, activate the currencies you need, dot-walk .code when you want the string.

If this helps, would you mind marking it as the recommended solution? It helps me keep supporting these platform design questions properly, and it makes it much easier for the next person choosing between a hand-maintained choice list and fx_currency to find a resolved answer in the Community.

Macki | Deloitte AU | Engineer Lead

[MalakaSilva]

Thank you. However, there are similrat tables. I guess you are refering to currency table?