It has become clear that we shall need a further level of grouping settings.

The currently implemented profiles group settings into collections targeting a particular context, for example:

When setting up a machine several of these profiles will need to be selected and applied.

For example:

a GBS customer's FileMaker Server, which is used both as a server and a support client, may need

When targeting a GBS customer's FileMaker Server, it will be necessary

Handling Conflicts between multiple Profiles

A (theoretical) example of a potential conflict could be

FM > Preferences > Layout > Always Lock Layout Tools Setting
- Some users want tools always locked
- Some users (me) want them always unlocked
Operating System Show all filename extensions Setting
- Generally, end users want this OFF
- Developers want it ON

When there are conflicting settings in the selected profiles, how should this be handled / dealt with?

Targets

The term Target seems to cover the idea here.

Maybe a new table is needed to define the different Targets

Note:

The Target-Profile-Setting structure does seem to model well the idea that a machine has multiple dimensions of settings, each dimension being modelled in a profile.
It is, of course, possible to do without a Targets table and to define everything in the Profiles table.
This would, however, lead to a lot of redundancy, where identical settings are repeated in many profiles, and it may become hard to manage:
- Should a settings value need to be adjusted (change in policy), it would have to be changed in multiple profiles.