Forum Discussion

Qrew Member

4 years ago

Too many entries in multi-select text field. Need solutions, please?

I have an app for project managers. When they create an activity, they can assign that activity to a project team member or other resource. The Assigned To field in the Activities table is a multi-sel...

Relationships

Tables and fields

MichaelTamoush

Qrew Captain

4 years ago

TL/DR: Link to a formula field with less choices, then change the formula field to all the choices.

You can trick the system. In your resources table, make another field 'Resource Name for MultiSelect'. This should be a formula text.

Link your multiselect to this field. AFTER you have it linked and saved, make your formula in the new field you created [Resource Name].

Now you will have all the choices.

The trick is, any time you want to edit and save the original multi select field, it will give you that error. So the process in the future is, comment out the formula field so there are 0 choices (or you can make the formula whatever you want, so long as its under 100 choices), edit and save your multi select field, un-comment your formula field.

------------------------------
Michael Tamoush
------------------------------

MarkShnier__You
Qrew Legend
4 years ago
In the long run, a better approach is to have a many to many relationship. One Resource has many Resource Activity Assignments. And one Activity has many Resource Activity Assignments. There is a technique that I could help you implement which would allow you to quickly add resources to a particular activity.

------------------------------
Mark Shnier (YQC)
mark.shnier@gmail.com
------------------------------
- PaulEaston
  Qrew Assistant Captain
  3 years ago
  Sorry for the thread necro, but I'm running into a similar issue. I have a Requests table and the end-users want to be able to associate a request with prior requests. So I created a multi-select text field that looks up from the Request ID# field.
  
  I understand that the kludge recommended here is not considered best practice, but when I'm only dealing with one table, how would I set this up properly? Do I have to create Request Numbers table that uses pipelines to populate all existing Request ID#s? Then another table to allow for many-to-many? It feels more complicated and result in duplicate data that is only created to create a lookup field?
  
  ------------------------------
  Paul Easton
  ------------------------------