What is the best practice for "lookup" tables when Choice Lists aren't enough?

[Mike Lerch]

As we migrate our legacy data sources of CI information into ServiceNow, we are frequently able to onboard custom attributes by adding columns to the appropriate CMDB table and use the built-in choice list specifications to specify the domain of allowed values.  

However, sometimes we need to have a "lookup" table that has several novel columns, or needs to participate in an m2m relationship.  In those cases my instinct as a data modeler is to create a "custom table" and make a reference to it.  We've been doing that, but it's eating up our very meager license allotment!  Extending sys_choice and adding a couple of columns would be perfect, but it seems that it is no longer one of the exempt tables we can extend 1000 times per the custom table guide , and b) explicitly called out as unsupported in the Best Practices – Choice Lists .

What are you folks doing in cases like this?  Is there something I can extend that I'm missing?  For instance, I think some folks in this situation are extending DL Matcher (which is free), but since I only need a list of values with some extra fields, and not "rules that automatically set one or more field values when certain conditions are met" (i.e. I don't need anything in dl_definition_list, just values in dl_matcher), this feels a little hacky/license-skirting.  Is this just a thing that eats up license allocation for everybody?

(For more info in case it's needed, here's a use case:  we have this special regulatory status we're tracking separate from the usual lifecycle fields.  Business needs the A) the current status on the main CI record and B) the status history with dates in a related list.  We made a mega-simple custom table that's just a list of regulatory statuses values, then added a field in the CI table with a reference to it to satisfy requirement A.  Then we made an m2m table (for free!) with references to the CI and custom table, adding a couple of date columns.  Good 3rd normal form, good referential data integrity, but at the cost of a tiny table that counts toward the license allocation).

[Daniel Borkowi1]

@Mike Lerch , is for the requirement not possible only to use the m2m table? Because you can also add 2 fields additional to the needed reference fields for free. Maybe I did not got it correct. How does the Status custom table looks like? It sounds that this is standard sys_choice having a label and a value - what additional information you store in the custom table?

Btw. using dl_matcher for lookups is fine in my opinion - you don't need to have Lookup Definitions for that. In some cases Decision Tables are also a good place for similar requirements.

Greets

Daniel