Managing Custom Fields
If your app needs to store data in the Yext Knowledge Manager on a per-location basis that is not included in the existing data models, your app can take advantage of custom fields. Custom fields are configurable fields that can be added to a Yext account, allowing customers or apps to store custom data for each location. Custom fields have built-in support for a number of data types, as well as configurable field validation.

Custom Fields are attributes on the Location object in the API, and they are retrievable and settable as any native Location field. For example, your app might want to store data from an external platform in a custom field, or it might need a custom field to store a primary key for an external system. In these cases, your app would create a new Custom Field definition on the account and then use the new custom field to store data in each Location object.

Custom Field Behavior

In order to protect customers and other apps from potentially harmful behavior, apps can be restricted to certain custom field behavior. These restrictions affect apps’ abilities to create, update, and delete Custom Field definitions on a Yext account. Note that regardless of this setting, apps can always read and/or write to any custom field if it has access to the Locations endpoints. To enable your app to create, update, and delete Custom Field definitions, you will need to set a Custom Field Behavior in your “App Settings” page. The behavior you choose depends on your scenario:
  • Your App does not need to create/update/delete Custom Field definitions (default)
    • Custom Field Behavior: Choose “Disabled”. Your app will still be able to read and/or write to custom fields with the Locations endpoints.
  • Your App will always be Private
    • Custom Field Behavior: Choose “Enabled for all fields”. Your app will be able to use the Custom Fields endpoints to create, update, or delete any Custom Field definition on an account.
  • Your App will be submitted to the App Directory
    • Custom Field Behavior: Choose “Enabled for fields with prefix”. Your app will be able to use the Custom Fields endpoints to create, update, or delete Custom Field definitions on an account, only if the custom field’s name begins with your specified Custom Field Prefix.
ENABLED FOR ALL FIELDS If you choose “Enabled for all fields”, your App will not be eligible for submission to the App Directory.
CANNOT BE EDITED AFTER SUBMISSION Your Custom Field Behavior cannot be edited after your App has been submitted or published to the App Directory.

Custom Field Prefixes

Your Custom Field Prefix should be a short, unique customer-facing string between 3 and 50 characters. This string will usually contain the name of the external platform your App is integrating with (e.g., “Zendesk”, “Salesforce”, or “HubSpot”). If your Custom Field Behavior is “Enabled for fields with prefix”, all Custom Field definitions you manage in your app must start with this string.

For example, if your Custom Field Prefix is “ExampleCo”, you can only create, update, and delete Custom Field definitions that have names like “ExampleCo ID”, “ExampleCo Ticket Queue”, etc. Note that the Custom Field Prefix does not prevent your app from retrieving and setting other custom field values on the Location, regardless of prefix.
CANNOT BE EDITED AFTER SUBMISSION Your Custom Field Prefix cannot be edited after your App has been submitted or published to the App Directory.