What is a Field | Yext Hitchhikers Platform

What You’ll Learn

In this section, you will learn:

• What a field is
• Examples of fields on some built-in types
• The “field is a field is a field” principle

Fields Overview

As you learned in the Entity Types Module , entities are the core objects stored in Yext Content and fields provide additional information about each entity type.

Each Entity Type comes with a number of Yext pre-built fields and you can add additional custom fields as needed. Remember (as we showed in the Entity Types Module ) there are some fields that are on all entity types – built-in or custom. These include:

• Entity ID (unique identifier)
• Name
• Folder
• Labels

Here are some example fields on some of the built-in Yext types –

Location:

• Name
• Address
• Phone
• Hours
• Description
• Logo
• etc.

Event

• Name
• Start/End Date/Time
• Event Location
• Ticket URL
• etc.

Healthcare Professional

• Name (First, Middle, Last)
• NPI
• Office Address
• Office Phone
• Headshot
• Photo Gallery
• Education
• etc.

Restaurant

• Name
• Address
• Hours
• Description
• Logo
• Attire
• Price Range
• etc.

Job

• Name
• Job Location
• Description
• Keywords
• etc.

Additional fields are also automatically enabled if you are subscribed to certain publishers. For example, if your package includes Google Business Profile, your Location entities will also have fields like Google Cover Photo or Google attributes.

All fields have a few properties:

• A Type, like string, phone, or url
• A Display Name, like “Keywords”, “Main Phone”, or “Description” used to reference the field in the UI
• An API name, like description or c_customfield used to reference the field in the API
• Validation, like maximum character counts, count of items for lists, or aspect ratio for photos

An important tenet of fields in Yext Data Modeling is that “a field is a field is a field”. This means that, once-defined, a field maintains the same properties like Name and Validation no matter where it appears. Fields are often shared between types – like the Description field – but no matter where it appears it will have the same validation, API name, and UX.

In this example, the Name field is present on each of these types and its validation and UI presentation is the same.