
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-03-2016 09:20 AM
While editing my scoped application in the Studio, I added a Table Column to the Department table (cmn_department). After changing plans, I no longer need that column. There is no easy way to delete it that I can see. So far, in testing on another instance, the only way is to do a GlideRecord delete with setWorkflow(false), but that makes me wonder why the system won't allow it. Will it cause any problems with my scoped application if I force the deletion of the column?
Solved! Go to Solution.
- Labels:
-
Scoped App Development
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-11-2016 12:39 PM
Confirmed that this is a PRB (PRB690378) fixed in HP6. Support will have to delete this for customers who need the columns removed. This is for columns created on non-scoped tables.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-03-2016 09:38 AM
Hi Shannon,
I was able to verify this on Helsinki P4. As near as I can tell, the condition on the Delete Column UI action includes a call to DictionaryUtils().isDeletable() which isn't checking for the condition of a scoped field on a global table properly. I recommend reaching out to support see if there is a known PRB on this. If not, open an incident so we can check it out.
HI Service Portal - ServiceNow

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-03-2016 10:02 AM
Thanks Chuck! I'll contact support.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-03-2016 10:04 AM
Let us know what you find out. I'm curious if there is an underlying problem to fix or just something new to learn.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-08-2016 09:44 AM
Hello All,
This is Chris from the support team that works specifically with scoped apps. Chuck's statement is correct that when a column/table deletion occurs on the system there is a call to the dictionaryutils script include which is preventing users from deleting artifacts on the system. There was a write audit that was introduced as we saw an influx of customer caused data loss where a column was mistakenly deleted which caused catastrophic cascade deletes so that we essentially did was create this write audit script to prevent that. That being said, if a column is created within a scoped application but the column is created on an OOB table there is a condition in place that prevents deletion of this column. Hypothetical reasoning behind this someone wants to delete a custom column on task and then accidentally deletes the OOB state field(surprising but we have seen this done on customer production instances) which would then cascade through the entire TASK hierarchy causing a catastrophic delete. Even as maint users (only support has this role) we cannot delete these columns as it requires the instance be put into developer mode which we as support do not have access to. However, all is not lost, if you need to have a column removed that was created in a scoped application support can perform the deletion for you so long as you are ABSOLUTELY sure the column being specified needs to be removed. This requires a change process that support will execute.
One thing to additionally note is that if you install a scoped app and then try to uninstall the app there may be table/columns artifacts that may be left behind which cannot be removed for this very reason. There was a PRB (PRB689946) where deleting scoped app artifacts for columns/tables created on custom tables did not work but that has since been resolved for releases on GP6 or higher.
The specific scenario here is creating a custom column on an OOB table. This is true whether you create it in a scoped application or in the global scope.
Hope this helps to clear some confusion. I understand that this is counter intuitive but the change was to protect customers from unintentional data loss.
Chris
ServiceNOW Support