And why not use a relationship?
If you use a script or calculation to load the values in a global field, you can display the entire field and set up an on object enter trigger to perform a script to determine what text was clicked and then your script can enter that data in the appropriate field or do whatever other action you want it to perform with that user selected value.
#This should only be done on a text field of type calculation so that entry can be permitted, but changes to its data prevented
Set Variable [$Cursor ; Value: Get ( ActiveSelectionStart ) ]
Set Variable [$Start ; Value: Max ( Position ( YourTable::YourCalcField ; ¶ ; $cursor ; -1 ) + 1 ; 1 ) ]
Set Variable [$End ; Value: Let ( E = Position ( YourTable::YourCalcField ; ¶ ; $cursor ; 1 ) ; E + not E * ( Length ( NoData::cgWindowNames ) + 1 ) ) ]
Set Field [YourTable::YourTargetField ; Middle ( YourTable::YourCalcField ; $Start ; $End - $Start ) ]
If you need to use an actual value list, calculations that refer to global fields or that are otherwise unstored/unindexed will not workas a source of values, you'd have to copy that data into an indexed text field. If you use a script to copy the entire list of values into a text field of a single record field, you script can dynamically load different lists by altering the values listed in this single field. (Values separated by returns in a single text field are presented as separate values in a value list that displays values from the same field.)
The reason why I don't think relationship will work in my case is because I have many layouts with "Accounts" Table displaying company infomation and has no relationship to the users (meaning assigned employees to each account).
The idea is that when creating an invoice, I wanted to have a dropdown list of salespeople, and customer service so that there are records of which employees are assigned to that perticular order.
So, I guess my question would be, a calculation conditional list wouldn't be the best case?
You may not have a relationship now, but I don't see why you can't add them. The same criteria any script or calculation would use to isolate the specific values for your list would seem to be the same information you could use to construct the needed relationship. And yes, it sometimes requires defining more than one version of the same conditional value list to support the different relationships from different parent tables you may need to work with. Though in this case, you describe different layouts based on the same "Accounts table" so this may not be necessary here.