Back
Step 3: Forking Custom Field Types
In order to eventually fork your Legacy Rich Text fields, you’ll need a compatible field type to migrate the data to. In this step, you’ll fork any custom field types that are using Legacy Rich Text subfields to one of the new field types.
At the end of this step, you will have created a field type identical to your existing custom field type, but leveraging either Markdown or Rich Text (v2).
If you haven’t done so already, make sure to enable the Fork Fields flow as outlined in the Getting Started section.
1: Check for Eligible Field Types
Navigate to Content > Configuration > Fork Field Types. Here, you’ll see an overview of which field types need to be forked.
If you don’t see any custom field types in the table, this means you aren’t using any custom field types that have a Legacy Rich Text subfield, so you can continue on to the Forking Fields step.
If you do see any field types listed, you will need to fork them.
2: Select Field Types to Fork
Select the checkbox next to the field types you wish to fork, and click the Fork button in the bottom right.
3: Configure Your Forked Field Types
You’ll now be brought to the Forking Details step.
In the table, “Source” refers to your custom field types that are currently using Legacy Rich Text. “Destination” refers to the custom field types that will be created to replace the legacy fields.
In the example below, the Source ID column refers to the ID of the custom field type c_socialPost, and the Source Name column holds the display name of that custom field type (“Social Post”).
In this step, you’ll populate the Destination columns.
You will need to populate all of the following for each field type in the table:
| Column | Definition | Additional Information |
|---|---|---|
| Destination Subfield Type | The type your Legacy Rich Text subfields should be forked to | The Destination ID and Name columns will become available after the Subfield Type is chosen. |
| Destination ID | The ID of the new field type you’re going to create | We’ll pre-populate this input based on your designated Subfield Type and Source ID. Feel free to edit this as you like. Field Type IDs must not be duplicates of any other IDs in the account, and cannot have special characters. |
| Destination Name | The name of the new field type you’re going to create | We’ll pre-populate this input based on your designated subfield and source name. Feel free to edit this as you like. Field type names must be less than 64 characters, and contain only alphanumeric characters, _,-,(,), and spaces. |
Once you are happy with your selections, click Initiate Fork in the bottom right.
4: View Results
Now that you’ve successfully forked a field type, you’ll be brought back to the first screen in the Fork Field Types flow.
You will still see your legacy field types in the left-hand column, but now, you should also see your new field type in the table in the Compatible Field Types column.
When we say a field type is compatible with a legacy field type, we mean that the compatible field types will be offered as a type that you can fork individual custom fields to in the next step.
If you chose not to fork all your field types at once, you can refer back to the Fork Field Types table to see which other field types you need to fork later. You’ll know which ones still need to be forked because they will not have a compatible field type.
Maintaining Field Type Compatibility
Making breaking changes to the source or destination field type will cause those field types to become incompatible. This can happen if:
- Either the source or destination field type is deleted
- A subtype is added to the source type
If two field types become incompatible, you can go through the Fork Field Types flow again. However, this will create another new field type in the process.
5: Discontinue Source Field Types
In order to ensure the source field types are no longer used, we recommend appending something like “Legacy,” “Deprecated,” or “Do Not Use” to the name of the source field type.
We do not recommend deleting your source field types, as this action is irreversible.
You’ve now created new custom field types to migrate your data to! In the next step, you’ll fork individual fields over to the new types you have created.