- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-18-2017 09:01 AM
Long time ago a custom table was created, and it does not look like it is being tracked as changes to not appear in the update set. I read that you should extend the table from the Application File table at creation for this to work (Track an application table in Update Sets ). Is there a way to start tracking the custom table, even after it was created?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-19-2017 08:45 AM
Hey Chuck, I found the answer by going to the table.
It seems there is a UI Action called 'Track in Update Sets'. After clicking that, the records started showing in the customer update list!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-18-2017 09:04 AM
No. You can't add a custom table that is already created in an update sets.
But I think, there should already be an update set in your production, using which it was applied.
Search the table as keywork in sys_update_xml
Please mark this response as correct or helpful if it assisted you with your question.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-18-2017 10:45 AM
Hi Peter,
I'm not clear on this one. Are you looking to track changes to the table (fields, ACLs, etc) in the update sets or the records that the table contains?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-19-2017 01:03 AM
I want to track the records inside the new table. It's a configuration kind of table that was created.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-19-2017 08:23 AM
No. You can't add a custom table that is already created in an update sets.
But I think, there should already be an update set in your production, using which it was applied.
Search the table as keywork in sys_update_xml
Please mark this response as correct or helpful if it assisted you with your question.