Propegating domain element translations to user application

Related products: Software Factory

I often find myself adding notes in code to translate the domain elements to their meaning. Sometimes that means: disable customer VPN to enable network connections to our internally hosted SF, looking up the values and their meaning, and enabling the VPN again to continue troubleshooting the end application.



Would it be a useless option to generate master data tables for the user application based on the domain elements and their translations, as part of code generation? Not just as a comment in the checks-codegroup, but as real tables and data?



I am aware that it is of no use for the end user that already sees the translation in the application, but any application manager or support team would be helped by it.



Developers for sure would be helped, because they do not need to query the SF to find the meaning of the domain elements and instead can join the master data to find the meaning of a value.

To take this a step further: combined with inactive domain elements it would allow for user maintained domain elements (*).

Domain elements have the benefit of enforcing data consistency, but the drawback of needing developer intervention to extend the number of elements. Therefore I often see customers asking to revert a domain with elements to a master table with a prefilter.



Imagine a scenario where domains come with built in support for inactive domain elements. The database value of the element does not have a meaning (other than for ease of mind for the developer), so when requirements describe ten elements, we would create twenty, ten of which inactive and reserved for future use.



Now when the application manager wants to add a new domain value, it will be taken from the reserved values without need for changes to the database.



(*) user maintained domain elements still require developer intervention to update the name and translations of those 'new' elements in the SF/model. That is a solvable problem.

Unfortunately, this idea has not received enough votes. Because we want to keep the focus on ideas that are in high demand in our Community, we are closing this idea.


Updated idea status OpenClosed