Deleting Content Types and Custom Fields

Content Types and Custom Fields: How Objects are Affected

While the Kapost platform is quite customizable, once content is within Kapost and content types and custom field values are associated with that content, there are significant impacts from deletions of some data objects.

This document focuses on the impacts and considerations teams should think through before deciding to delete custom fields and content types.

Deleting Custom Fields and Custom Field Values

If your team determines a particular custom fields or values within the field are no longer useful, those values can be deleted, but once they are deleted, the values and/or fields will NOT appear on content, and cannot be restored without significant, mostly manual, effort. This can affect numerous aspects of the instance’s functionality, including but not limited to gallery collections, search results, and initiatives.

If values are in use, consider the following to reduce data loss:

  • Should that information be captured in another way?
  • How should that information be transferred?
  • Is there a different value to better capture the data?
  • Does a new value need to be created and applied instead?

An alternate option if the team wants to retain a custom field value on existing assets, but not have it appear as an option for new assets, is to archive the value. This prevents data loss, while ensuring future assets will not receive an outdated or unwanted value. Note that archiving is only an option for custom field values, not for the entire custom field.

Note: Consult with your Customer Success Manager or Technical Services to help with deleting these fields.

Before taking the action to delete one of these data objects, please review the following checklist:

  1. Generate a report showing what assets are utilizing these custom fields and/or values. The best way to do this is through Custom Reports, so Content Id can be retrieved. Use the report data to help determine next steps. If a custom field is not used anywhere, it can be deleted without impact to any assets.
  1. Changes or transfers of data should be done BEFORE deleting the field or the value(s). If this involves large changes, reach out to your CSM or IM to engage Kapost resources to transfer this data.
  2. If the data has been deemed no longer relevant or useful, archiving values is not an option, and the data has been transferred appropriately, then it is safe to delete the value or custom field without major disruption to the instance.

Deleting a Content Type

If a content type is no longer serving the team well, it can be deleted. However, if that content type is used for assets, deletions can have major impact on an instance and will require several steps of preparation.

IMPORTANT: Any assets of a content type set for deletion will need to be reassigned to a new content type before deleting the specified content type. Reassigning the content type will prevent those assets from being deleted.

Before deleting a content type, consider if it is necessary to delete. Review this checklist:

  1. Would simply renaming the content type be a solution?
  2. Would adjusting the custom fields assigned to the content type solve the problem? (This removes the custom field from the content type, but does not delete the custom field. Though, it will remove the custom field from any assets it is currently tagged to within the specified content type.)
  3. Would adjusting the workflow steps improve the usability of the content types?

If none of the above options look viable, then investigate what data is in the content type before deleting it. Again, this is because assets created of this content type must be reassigned to another content type before deleting the content type.

  1. Request an audit report from Kapost to view how often this content type has been used over the last six months and all time.
  2. Another option to also generate a custom report to show what assets are within this content type. If this content type does not contain any assets, then the risks are very low in deleting it.
  3. If this content type does contain assets, the user should reassign the content type on these assets before deleting. Workflows of each content type and the existing custom fields need to be considered as part of this decision. If the values within the custom fields or workflow steps need to be retained, consider a content type that is very similar to the one being deleted, or create a new content type that possesses the desired template for workflows and custom fields.
  4. Changing a content type can be done individually on each asset near the bottom on the asset page.
  5. To change the content type on assets in bulk, request assistance from a Kapost employee.
  6. If anyone attempts to delete a content type that contains content, a modal will pop up to prompt that user to make decisions about changes. This serves as a safety net to avoid losing the assets, but Kapost recommends working through these decisions in a planned and careful way before getting to this step.

Caution: IMPORTANT: THIS DOES NOT INCLUDE ARCHIVED CONTENT!

You will need to filter the content catalog to Archived content and identify pieces that are of the content type to delete and change those pieces to the new target content type.

Caution: IMPORTANT: THIS DOES NOT INCLUDE DELETED CONTENT!

Individual content assets are not deleted for good when they are deleted. They can be restored by a superadmin, but if the content type is deleted, any content that was in this content type will changed to "Unassigned". You can display deleted content by filtering in the content catalog.

  1. Another step to consider is to communicate with the team that a content type will be deleted so members will not inadvertently create content in that type.
  2. If steps 1 – 9 have been addressed, and any assets within a content type have been reassigned, it is safe to delete the content type.
  3. When a content type has no content in it and a user attempts to delete it, the modal warning will be quite minimal.

  1. If this is the message displayed, it should be safe to delete the content type without affecting any assets.