# Schema options
## Introduction
Schemas aren't mandatory but they make things much simpler when building process flows. If your flow includes endpoints associated with schemas, any field selector options in process flow shapes are populated with the schema structure - all you need to do is choose the required field.
For example, the [filter shape](https://doc.wearepatchworks.com/product-documentation/process-flows/building-process-flows/process-flow-shapes/standard-shapes/filter-shape/using-regex-for-string-type-filters) below is picking up the schema associated with the Shopify endpoint, configured in the preceding connector shape:
If a process flow uses an endpoint *without* a schema, any field paths defined in shapes must be defined manually.
{% hint style="info" %}
The required schema for your third-party application should be available in the associated API documentation.
{% endhint %}
{% hint style="info" %}
When you add a schema, you can also choose to [apply field tags](https://doc.wearepatchworks.com/product-documentation/developer-hub/connector-builder/building-your-own-connector/4-endpoints/endpoint-options/schema-taxonomy/field-tagging).
{% endhint %}
## Adding a schema
To apply a schema for an endpoint, follow the steps below.
{% stepper %}
{% step %}
**Edit the endpoint schema**
Click the `edit schema` button:
{% endstep %}
{% step %}
**Add the schema for your endpoint**
Paste in the required schema and save changes:
{% hint style="info" %}
If you can't find a schema in your API documentation, you can run the API request in Postman, and then copy/paste the response as the schema.
{% endhint %}
{% endstep %}
{% endstepper %}
## Setting a data path
Use the `data path` field to define the hierarchical level to be used for [field tags](https://doc.wearepatchworks.com/product-documentation/developer-hub/connector-builder/building-your-own-connector/4-endpoints/endpoint-options/schema-taxonomy/field-tagging) and [filters](https://doc.wearepatchworks.com/product-documentation/process-flows/building-process-flows/process-flow-shapes/standard-shapes/filter-shape):
This is particularly important for JSON payloads, where the data structure is nested. Let's take an example below:
Here, all of our data is nested within one, top-level **customers** array object. If you scan down this example, you'll notice that there are two customer objects, each starting with an id for a customer record:
Now let's look at the `data path` field at the bottom of this page:
If we leave this set to `empty`, any subsequent field tags, mappings and filters will work on the basis that the top-level array object is our target. What we'd be saying in this scenario is 'don't treat the nested objects as separate records'.
So, for example, if we went on to apply a filter to match on `first_name` `contains` `bob`, we'd find a match in the second customer object but ALL objects would be returned because we're targeting the top-level array object. This isn't what we want - we need to treat each of the lower-level customer objects as separate records. To do this, we navigate the data path and select the parent object - in this case, its `customers`:
When you save your new data path, you won't see any changes to the schema - but the change will be applied in the [field tagging](https://doc.wearepatchworks.com/product-documentation/developer-hub/connector-builder/building-your-own-connector/4-endpoints/endpoint-options/schema-taxonomy/field-tagging) tab. Here, the schema preview shows the structure that applies as per your selected data path in the **schema** tab.
Show me
When you come to use instances of this connector in process flows and apply a [filter shape](https://doc.wearepatchworks.com/product-documentation/process-flows/building-process-flows/process-flow-shapes/standard-shapes/filter-shape), you'll see confirmation of the selected `data path` in filter settings - for example:
Show me