Hi Tejo,

One of the ways to do this is to have a (base) table that contains some information about Free fields. These Free fields can have a subject, a label and a data type for instance. But to keep it simple, you can create a base table holding the following:

• Tenant
• Label

Then create another table that will hold the configuration:

• Tenant
• Label
• Value

Then create View that will show rows for each Label (set-up Free field). Let this use a Formlist.

• Tenant
• Label
• Value

Code for the View would look similar to this:

select 
    base.tenant_id,
    base.label_text,
    conf.set_value
from free_field base
left join free_field_configuration conf
  on base.tenant_id  = conf.tenant_id
 and base.label_text = conf.label_text

This will then show an X amount of records for the Tenant based on the amount of base Free fields. Any configured values will be shown if given. Using a Handler or Instead-of trigger will allow you to write the inputted values into the configuration table. This configuration table can be hidden as you will only show the view. 

In this example, the Formlist may not be necessary, but once you would like to add complexity in the form of multiple data type support, you'll need a Layout procedure to hide certain fields base on the datatype for example. Then a Formlist is needed.

(label text can be made multi-lingual by adding another table that holds the translation)

Hope this gives some inspiration 

Another option would be to add a freelabel_xx expression field with a label control before each of the freefield input fields, that retrieves the value of the label from a configuration table.

Thanks Jasper, I got this working in a form, but in a grid I can’t fix the column-names

@Mark Jongeling thanks for the inspiration  never used formlist before. Is there a reason why a formlist is always editable? The fields should be fixed for some users

Could it be that the Auto-edit setting is turned on for the Subject?

Using Auto-edit and Auto-save for Formlists is usually what is more user-friendly but I can understand that in some cases it should be read-only.

You can use Role rights and/or Layout logic to prevent certain fields from being editable in specific cases.

Hi @Tejo van de Bor, did the answers of Mark and Jasper provide enough inspiration for you to make a good solution?

hi @Jeroen van den Belt , I think that the formlist is a rather complex solution for something that could be easily fixed if the translations for those extra fields could easily be changed for the endproduct in a ISV customers’ environment.

But I guess that is not supported at this time? To change translations in IAM or better still in the endproduct?

Hi Tejo,

Translations for columns are loaded from the model that is either present in SF or IAM. The way the Windows GUI/Indicium loads the model cannot take into account any end product model overrides.

What Jasper and I suggested is utilizing the Formlist in combination with columns that use a Label control. This will allow you to basically show data (field) as it were a Label like the GUI would supply. The Grid component can only show Labels of columns like how they were specified in the model.

The Formlist is currently the only way of making Free extra fields work.

What could be interesting is an option to override app translations from IAM for specific apps.

However this would probably be difficult if you want to keep overrides when deploying a newer version. What should happen with them etc...

That sounds like a great Idea to create here on the Community. My vote you'll have

There you go: