Back
Step 7: Transitioning to Your New Fields
Depending on how you were leveraging your Legacy Rich Text fields, you’ll need to update any systems that write to and read from those fields, as well as certain aspects of the field configuration. You will also need to discontinue using your legacy fields.
Manage New Fields and Update Integrations
Below is a table of places where the source field may be referenced, and whether they are updated automatically when the new field is forked:
| Item | Updated Automatically? | Additional Information |
|---|---|---|
| Entity field configurations | No | Reconfigure any relevant entity types to display the new field under Content > Configuration > Entity Types > Field Configuration. |
| Entity templates | No | Reconfigure any entity templates that reference a legacy field or field type under Content > Configuration > Entity Templates. |
| Embedded fields | No | If the source field is used as an embedded field anywhere (i.e., in Page Builder, or within the body of another field), you will need to update these references to embed the new field. |
| References to other embedded fields | Yes | If the source field contains other embedded fields, we will migrate those embedded fields over to your new field. For example, if you fork the rich text field “Product Description,” and that field references another field called [[productName]], your new forked “Product Description” field will also contain that reference to the [[productName]] field. |
| Field validation | Yes | If the source field had any validation rules, the new field will have the same validation. |
| Translations | No | Reconfigure translations on the new field under Content > Configuration > Fields. |
| Field computations | No | Reconfigure field computations on the new field under Content > Configuration > Fields. Note that while Markdown fields currently support computed field values, Rich Text (v2) does not. |
| Upstream integrations | No | This is any source that writes data to the new field, such as: Connectors, Entities Management API, and upload configurations. |
| Downstream integrations | No | This is any source that reads data from the new field, such as: Search, Pages, and API integrations, including Content Delivery API. |
See the next sections in this guide for steps on Managing Upstream Integrations and Managing Downstream Integrations.
Discontinue Legacy Fields
When you forked your Legacy Rich Text fields to your new fields, we took your data at that point in time, and converted the format to match the new field type.
If you continue to edit the legacy source fields after forking (instead of editing data in the new fields), the new field will not automatically pick up the edited data.
You will also want to ensure all users on your Yext account do not continue editing data in legacy fields, and only use the new fields moving forward. If a source field is edited after it is forked, you can resolve this by refreshing the field.
Mark Legacy Fields Inactive
We do not recommend deleting your Legacy Rich Text fields, as this action is irreversible. Instead, we recommend you clearly designate the old fields as inactive.
You can designate your Legacy Rich Text fields as inactive by:
- Removing permissions from the field (i.e., View, Request Edit, Edit) to hide it from users
- Editing the display name of the field to append something like “Legacy,” “Deprecated,” “Do Not Use,” etc.
- Modifying the entity field presentation to hide it in a section on the entity that is collapsed by default
- Toggling off the Visible on Add option in the field configuration (if it is toggled on)