One way you can achieve this is by using a look-up table instead of domain elements. By adding a default non-locked look-up prefilter to filter out the old values and disabling the look-up popup, the user interfaces will still be able to translate old values while preventing the user to select them.

Please note that through the Indicium API, it will still be possible to insert and update rows using the old values. You might want to add some business logic to prevent that. (Which, by the way, would be more difficult when using deactivated domain elements.)

---

I think you also need to consider what legacy you want to create. By adhering to this requirement, you will create legacy and have to maintain both new and old elements for years to come.



The more robust solution is to migrate all the old elements (the ones no longer valid) to the new values. I'm almost certain you could make a mapping in order to come up with the right plan for migration. Short term, this is a bit more work, but if you disregard this, and situations alike, it will come back to haunt you.

---

@Jasper , @Robert Jan de Nie



I know, this could be resolved by changing the domain of the field to a same type (e.g. integer), create a table, but also a translation table and accompanying view that shows things in the users language, possibly a instead_of_trigger on the view is needed when users should also be able to change data. A lot of things to be build when a domain with elements.



For instance, who would build a table/translation/view/trigger when initially a status of an order can only be

• status 1
  
• status 2
  
• status 3
  

according to the user requirements.. And months or years later "status 2" may no longer be used, but historic data still needs to be displayed as "status 2", Normally I wouldn't think twice about whether to create a lookup table for such a field, or create it as a domain with elements when building the applications initial version... Who would?



Thinking like this one could completely get rid of domains with elements (and additional translations). Because I can't see what the business wants in a couple of years.... Users and customers sometimes get different opinions or ideas I've noticed the last few decades...

---

Users and customers sometimes get different opinions or ideas I've noticed the last few decades...

---

As a work around you could write a default procedure which empties out the field (domain with elements) when the user select a value which is not longer active (You can even use a table to determine which element is no longer active.).



When you empty out you can also create a popup message explaining that this value is no longer active to help the user.

---

@Robbert van Tongeren



If a domain-element pre-filter kind of solution is not an option to build into the SF, than that is probably a workaround.... A bit difficult to explain to (new) users of the application however that "They may not choose certain values in a dropdown".



Either that, or going for a table/translation/view/trigger solution. But I bet I won't be the only one walking in the domain-element trap for years to come....

---

I'm fully with @htimmermans on this one. One of the great human abilities is the concept of ‘voortschrijdend inzicht’ (a bit hard to translate properly to English, but let's call it ‘progressive insight’). Coupling that with the concept of Low Code/Thinkwise to be flexible and future-proof, it should be straightforward to mark an element as Active/Inactive. Lookup tables and pre-filters seem like overkill for the average status or type kind of domain and workarounds are ugly.

@Jasper Wouldn't it be quite plain and simple to add a checkbox in the SF where we can mark Elements as Active/Inactive (default to Active), and ensuring the Inactive ones no longer show up in the Dropdown? 

---

Adding a checkbox in the Software Factory metamodel is indeed quite simple, but this functionality must then of course also be developed for the Windows, Web and Universal GUI and the Indicium service tier.

There are a lot of great ideas on the community, but unfortunately we don’t have the capacity to take them all up. The number of votes, combined with the required effort and the added value of an idea, really helps us to select the best.

---

The following idea has been merged into this idea:

All the votes have been transferred into this idea.

---

As the Domain (elements) Variant Idea is merged with this one, I guess it's better to add a similar suggestion here:

Instead of the Variant Idea, it would be great to be able to use the Layout procedure on domain Elements. We often have situations (especially on status fields) were a user is only allowed to use certain element values or to move it from one element to one other element. The availability of a given element would be based on User permissions or current status (for example: if current status is A, you can only change it to B, and if current status is B you can only change to A or C, but not D). Now if it were possible to show/hide certain Elements in the Layout procedure we wouldn’t have to work with workarounds like creating two similar Domains and using Layout logic to determine which one to show. Maintaining two (or more) similar Domains with Elements is both risky and ugly. 

It would be good enough if somehow the Layout procedure recognizes Domain with Element type of fields and we can write logic on each individual Element within that Domain.  

Anyone else seeing the value of this addition?

@Jasper is this something that can be covered as part of this Idea and can be squeezed in the upcoming 2021.2 release, or would it need its own Idea?

---

Hi Arie,

If it is necessary to filter the values in a combo based on context, we often turn to lookups instead of domain elements. You have to add business logic anyway, and filtered lookups using for example expression filter fields provide the most flexibility. You can also add prefilters to limit the options based on the user’s authorization profile.  

If you still think your idea should be implemented, feel free to create a separate idea for it as it is not trivial to implement.

---

Created an Idea here: 

 

---

The upcoming 2021.2 release will include the option to deactivate domain elements for a project version. Deviation per variant is scheduled for the 2021.3 release.

Updated idea status Working on it! → Next release

---

Updated idea status Next release → Completed

---