- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-13-2023 02:16 PM
Hello developers,
I have a quick question.
In a domain-separated environment, when you create new fields and add them to the task form, should you create and add those fields in the global domain or should they be added in the TOP domain? They system admin wants the developers to work in the TOP domain.
And so far, I've been adding new fields to the order task form in the TOP domain but when I move my update set from Dev to Test, other Default views get created in the global domain but they're all empty.
Am I doing something wrong?
Any guidance will be greatly appreciated!
Best regards,
cnharris1
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-13-2023 04:51 PM
Hi, I was unable to reproduce this in a PDI.
If I add a field to a table while I have my domain set as TOP, the global 'Default view' is updated\pushed to my update-set.
It is only if I alter the 'Default view' view manually in the UI that a Top domain version of the form view is created, and I would consider this expected behavior.
So while you can add a field from any domain - tables\fields are not domain separated,
If you want to manually update the 'Default view', this view is global domain and you should not be updating it from any other domain, unless you want a domain specific version of the 'Default view'.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-13-2023 04:51 PM
Hi, I was unable to reproduce this in a PDI.
If I add a field to a table while I have my domain set as TOP, the global 'Default view' is updated\pushed to my update-set.
It is only if I alter the 'Default view' view manually in the UI that a Top domain version of the form view is created, and I would consider this expected behavior.
So while you can add a field from any domain - tables\fields are not domain separated,
If you want to manually update the 'Default view', this view is global domain and you should not be updating it from any other domain, unless you want a domain specific version of the 'Default view'.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-14-2023 08:35 PM
Hi @Tony Chatfield1 ,
Thanks for your explanation! I just noticed that several developers are adding fields to the same table and updating the order task UI form with those fields (and adding form sections). I'm sure something is crossing somewhere and getting caught in someone's update set, which is creating the extra Default views in the TOP domain when we move our code to another instance. Having the default view in the TOP domain is fine but it's the extra default views in the same domain that's becoming a problem. I think we'll need to address who is altering the UI form and in which domain.
Thanks again for your help,
cnharris1

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-27-2024 01:02 PM
I spent a ton of time trying to understand Forms and domain separation, let me tell you, they're super finicky, and its easy to create a bad reference if you aren't vigilant.
I could type an essay about it. Maybe I should write an article when I have the chance.
The biggest thing that I've found is that it's best to open both the Forms and Form Sections list views to check what forms and sections are at each domain level when you're updating domain separated forms. Filter by table and view in global domain and expand domain scope. You can save yourself a lot of heartache by seeing what's out there in advance.
I've had to do a lot of cleanup over the years, but my form changes are much smoother now.