Built-in vs. Custom Fields
What You’ll Learn
In this section, you will learn:
- The difference between built-in and custom fields
- When to use each
Differences between Built-in vs. Custom Fields
Just like Entity Types, fields can either be:
- Built-in and pre-defined by Yext
- Custom defined by you
Built-in fields will have built-in semantics and destinations, just like Entity Types. For example, Yext knows that the Description field on a Location entity should be the Description that we deliver to Google Maps and display on a location page. Since it’s built in, we don’t need users to tell us what the default behavior should be. We also determine the field’s validation based on that default behavior, like knowing the character limit lengths imposed by publishers.
You’ll recall that on a Location like the Yext headquarters in New York, we have fields like Name, Address, Phone Number, Description and Website. In fact, the built-in Location entity type has over 70 built-in fields!
For Custom Fields, You get to decide what the field means by defining the type yourself and therefore you have flexibility over things like the name, the validation and the multi-language profile behavior. More on those details later.
Where possible, we recommend that you use built-in fields, but we expect every graph to contain custom fields that make it unique to each Brand. Some custom fields are used purely for organizational or internal purposes (like keeping track of a store’s square footage or documenting the data source for an Entity), while others are meant to be consumer facing (like Promotions on Pages).
|Built-in Field||Custom Field|
|Yext defines the fields, which have built-in semantics and destinations||Customer can create the fields based on their needs|
|Delivered to Listings|
|Compatible with Pages|
|Compatible with Answers|
|Can control type||(only on creation)|
|Can control name and API name|
|Can control multi-language behavior|
|Can control validation|
|Can control custom field groupings|