- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thursday
Table name: sn_grc_reg_change_regulatory_feed
Both the classic UI and workspace has the same issue. I tried to add another field as well, its shows the same issue. I added the same field in another table it works fine.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thursday
Hi @vinithavija
Please check whether any ACLs (on both the parent and current tables) are restricting write access. Also, verify the scope in which this field was created and try changing your current scope to match the scope of the target field.
If my answer has helped with your question, please mark my answer as accepted solution and give a thumb up.
Thank You
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thursday
Hi @vinithavija,
From the screenshot, the Subsidiary field is configured as a Reference field pointing to Company [core_company], and the Mandatory option is enabled.
Since the issue occurs in both Classic UI and Workspace, I would suggest checking the following:
Dictionary Entry: Verify the field configuration, especially Mandatory, Read-only, and Reference table.
Dictionary Override: Check whether any override exists for this field on the table or its parent table.
UI Policies / Client Scripts: Check whether any inherited or table-specific scripts are modifying the field.
ACLs: Verify field-level read and write permissions.
Reference Qualifier: Temporarily remove the qualifier and test whether the issue persists.
Application Scope: Ensure the field is created and configured in the correct application scope.
Since the same field works correctly on another table, I would first investigate Dictionary Overrides, inherited configurations, and table-specific ACLs on sn_grc_reg_change_regulatory_feed. Also, try clearing the instance cache after making configuration changes and test again.
Hope this helps, Accept the solution if it assisted you with your question & Mark this response as Helpful.
Regards,
Tarun
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thursday
Hi @vinithavija
Please check whether any ACLs (on both the parent and current tables) are restricting write access. Also, verify the scope in which this field was created and try changing your current scope to match the scope of the target field.
If my answer has helped with your question, please mark my answer as accepted solution and give a thumb up.
Thank You
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thursday
Hi @vinithavija,
From the screenshot, the Subsidiary field is configured as a Reference field pointing to Company [core_company], and the Mandatory option is enabled.
Since the issue occurs in both Classic UI and Workspace, I would suggest checking the following:
Dictionary Entry: Verify the field configuration, especially Mandatory, Read-only, and Reference table.
Dictionary Override: Check whether any override exists for this field on the table or its parent table.
UI Policies / Client Scripts: Check whether any inherited or table-specific scripts are modifying the field.
ACLs: Verify field-level read and write permissions.
Reference Qualifier: Temporarily remove the qualifier and test whether the issue persists.
Application Scope: Ensure the field is created and configured in the correct application scope.
Since the same field works correctly on another table, I would first investigate Dictionary Overrides, inherited configurations, and table-specific ACLs on sn_grc_reg_change_regulatory_feed. Also, try clearing the instance cache after making configuration changes and test again.
Hope this helps, Accept the solution if it assisted you with your question & Mark this response as Helpful.
Regards,
Tarun
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Friday
Hi @Sanjay191 @Tarun Rekandar ,
Thank you for your help. I have created a ACL for that subsidiary column with adding roles (sn_grc_reg_change.manager, sn_grc_reg_change.user) fixed this issue. One of the ACL was blocked the write access to that column.