Hey Swarup, there are a number of different ways to architect this to avoid code changes for basic updates like you described. Really depends on the requirements and if everything needs to be dynamic or just the common stuff.

1. For text updates it is recommended to use either UiText (https://docs.q2developer.com/api_references/q2_sdk/db/db_objects/ui_text.html) for SSR extensions or use Tecton's localization setup (<q2-loc></q2-loc> or the tecton.sources.loc )

When you use UiText or Tecton's loc we have ways to easily make changes to the strings without changing code. It also sets you up to support multiple languages and have the strings for the correct language loaded automatically.

2. For other configuration changes... we would recommend putting these options in Wedge Address configs. Wedge address configs are also easily changable by the Innovation Studio team. There are other places in the DB to store values if they need to be specific to other objects (user, customer, account, etc).

3. You could take it a step further and make the entire page dynamic. Moving all the elements of a "tile" to the config object and building the page dynamically based off the config.

4. Once #1, #2 and/or #3 are done, a central form for the UI could be built to customize the configuration values and edit the DB. Note that FI's will start to have access to edit the Tecton strings using a tool called Q2-Config. This is not yet rolled out but once that is done anything that uses the Tecton string setup will be changable. You will not be able to create a central form to edit Tecton strings, those dont live in the DB.