Is it bad practice to use sys_choice table as choice table or list table for catalog item variables?

[Jay Gamblin]

If so what is the best practice?   A custom table?

This came up because when you define sys_choice values it requires a table and an element which makes sense if you're defining choices for say the incident form/table.   But a variable is not a table.   And discovering that sys_choice values get captured in sets paired by the table/element values means you must handle with caution as not to step on other catalog items that might have also used the sys_choice table as a choice source for say a list collector.

[andrewpilachows]

I think it should be fine as long as the users have read access to the records.   The table name would be minorly inconsequential, and could possibly just select Global table but I don't know what kind of overhead having global choices would create.   The element you can just make up and preface with u_ to make sure you don't have any clashes.   Then you just filter on element.

[peterraeves]

I need the same as OP and this seems to be a valid solution. Does anyone have any comments on this, whether it is good practice to use the global table for this?

Additionally I noticed that you cannot order the values this way and they will be alphabetically ordered.

[Vladimir6]

Two more tips:

1. If you can't make it working through element=u_something try to use elementLIKEu_something.

2. Instead of using text reference qualifier, which can make your variable list loading very long (20 variables takes by me almost 1 minute), get them to the list and use the Update all/Update selected action, so you can build your filter through buttons and fields, which will make the list loading in 3 seconds instead.