I thought I had a system for making fields in WeSay, which would then be automatically imported into FLEx, as described here. But just today, I noted that the inability to configure those fields in FLEx is more serious than I had thought. Looking in the FLEx help, one sees:

You cannot change the location or writing system after the custom field is created.

Since custom fields created first in WeSay then imported into FLEx are created in FLEx on import, there is no way to set these options once imported. Complicating this situation, apparently FLEx isn’t taking that (at least writing system) info from WeSay during import. I noticed this when I was moving some data around, and had plural data in an English language field (and this is not an English dictionary…) I went back to WeSay to check the config there; here is the WeSay config for the plural field, above the plural field display in FLEx:

So even though I told WeSay that I just want [nlj] data in this field, on import FLEx set the field as “all analysis, then all vernacular” (which doesn’t seem to match this screenshot, but the point is that I have five language to choose from when inputing data, when I should have just one).
The reason the data is in the ‘en’ field is my fault — I bulk copied to the plural field without checking which writing system I was copying into. But I made this error because I presumed that there was only one language field (this is data, not analysis!) for it to go to. So it is reasonable to imagine others might do so as well, with a bunch of junk language fields that can’t be easily gotten rid of.

Summary

1. This isn’t the end of the world. One can always create the fields again in FLEx, with the right options, then move all the data over with bulk edit. Needing to do so just negates the value of creating the custom fields on import, unless you don’t care what languages will be available to that field.
2. Since WeSay clearly has the correct info, hopefully the FLEx team will see this as a bug, and correct the import to take language choice from WeSay (assuming it can understand that [nlj], in this case, is a vernacular writing system, and the systems for categorizing writing systems in WeSay (which selects on a per system basis) and FLEx (which groups languages in categories of first/all vernacular/analysis only/then the other) can be harmonized and/or made to understand one another.
3. In the mean time, I would advise against importing custom fields from WeSay. We’ll need to take the extra steps to create the fields in each program, and hopefully get it documented clearly enough that each will see the other’s fields the first time around.