Features are a way to group sets of functionality that can be enabled or disabled for certain clients. This can depend on things like the contract made with them may not include certain functionalities, if the business doesn't need some of the more complex interfaces you application may allow, or on the contrary there is some very specific vertical domain interface that only a very restrict set of clients understand.

When you mark a field with a feature key you are specifying only when you are generation a solution for a client that has that feature active (as you configured in the client definitions) will generate the code and interface for that field. Good uses for feature keys will allow you to better reuse forms and navigation systems and those effects in you model maintenance should be fairly evident when you analyze that change.

But you need to be careful with certain aspects:

1. You must ensure that the form works correctly both when the field is there and when its not. This increases test complexity. Formulas, validations, field dependency and filtering interaction, and manual code must all be checked for correct behavior in both feature key cases.

2. Feature keys can quickly add up if you abuse them. If your forms need to account for multiple different feature keys complexity can get combinatorial very quickly and run away from your ability to control it.

3. Interface "holes" can become apparent if you don't take care about designing the form to allow both cases of a field existing and not existing. Grouping "featured" field together in groups or tabs and making the whole group disappear is usually a good idea.

4. Don't underestimate the usage of "show when" rules, even if you need to use functions to make complex activation tests. Designing a system to be configurable is preferable to designing a system to only work in one way. Remember that features are static after system deployment, if you need to change them a new deployment will be needed.

As an example:

Good use: Add a research papers list to the Person form and mark its feature key as "University" instead of duplicating the form and maintaining two versions of it.

Bad use: Mark the department balance as a feature of "closed year" when its that is a mutable value of the business. Each time the accounting year closed you would have to redeploy the system, which would make no sense.