Converting Labels to Custom Field (or other), to allow for different use of labels on boards

[rax adaam]

An issue I'm running into is that labels that are useful on one board are not necessarily useful on another board. 

e.g. on our "bug & feature requests" backlog board, we use t-shirt sizes and priorities as labels. These are:

• quick to implement & change (using keyboard shortcut, no need to open edit mode on card);
• very visual.

However, once these cards are sent to our "Sprint Tracking" board, those labels aren't really relevant anymore, and we'd like to be able to have a different set of labels that can be quickly implemented on that board.

Initially, I thought I'd set up a rule that would convert each label to a custom field (so we could still see the t-shirt size & priority, but once they are on our "Sprint Tracking" board, those values won't change, so a custom field is fine); however, this doesn't really address the issue, as the labels are removed *after* the card is imported to the board, and so the label is still saved on the board. i.e. even though we won't ever use a "Sm / Med / Lrg" label on the Sprint Tracking board, because we *will* import cards that (initially) have these labels (which are then converted to custom fields), the label is still saved to the "Sprint Tracking" board's list of labels. 

Does anyone have a good work-around for implementing board-specific labels?

[rax adaam · Accepted solution]

I may have just come up with an idea that would address the issue: instead of implementing the "label to custom field" rule on the destination board, we could implement it on the source board.

As such, we could use the keyboard shortcut to assign a label, but assigning the label would trigger a rule that would replace the label with the equivalent custom field. That way, when the card is shared to another board, there is no label, but the info is preserved. 

Haven't tested this yet, but I don't see any reason, a priori, why this wouldn't work. 

If anyone has another suggestion, always interested to hear. 

ps. I will only mark this answer as "correct" after having tested the above solution. 

[rax adaam]

N.B. the above works well; however, the order of custom fields is not customizable: they appear on the card in the order you create them (which is unfortunate), so if you want them to appear in a particular order on the card front, be sure to create them in that order, from the outset. 

Also, you may want to create one sample of each custom field, to ensure you're satisfied with they way they will be arranged on the card front (e.g. using "Priority" and "T-Size" was too long for my taste, as it frequently resulted in the t-size getting pushed to the next line, on the card front; by shortening them to "P" and "T" they always display next to each other. You want to figure this out *before* setting up all your rules, as the rules are tied to the specific *strings* used for the field name and options (e.g. it is associated with "T-size" not "Custom Field #1" and it is associated with "Sm" not "Custom Field #1, Option #1" which would make for more flexible programming). 

[Aron Kuch]

I made a custom field, of the type 'Select List (multiple choices)'. It took me a while to find the order, but it's under the ... menu on the right of the custom field's list and selected "Context and default value". Under Options there's an "Edit Options" link.
While I suspect you found this years ago, perhaps someone else needs it.