After reading this article, you'll know:

Think of a schema model as a temporary storage model that structures the data it receives to parse it to other functionalities in your application. It can store multiple values for a single property, and unlike regular models, schema models cannot be configured directly.

They can be used as objects within regular models, allowing you to store multiple items for a single property. This is particularly useful for saving data from questionnaires or other forms where multiple responses are possible for a single question. You can also view the schema models like objects in Javascript. They work the same way, a schema model holds data like an object in Javascript.

Schema models can also be used to map API responses, read this article to find more information about that. In this case, they can be used to convert the response structure into a format that is compatible with your regular models. Just like normal models, schema models support CRUD (Create, Read, Update, Delete) functionalities. This means that you can easily update the capitalization of properties to match your desired format.

There are three options when creating a new model. To create a schema model select the schema model tab. Give the schema model a proper name, you can then add properties to the schema model like you would with a normal model.

Whilst adding properties to a schema model, you might notice that schema models don't support all the property types that a normal model does.

It only allows for the following property kinds:

The reason that this is the case is because under the radar when you use a schema model in an action it only uses the values above. Meaning that there's no need to have all the other kinds available within a schema model.

If you want to add multiple properties in one go, make sure to use the 'quick add properties' functionality.

If you want to save the response from an API using a schema model with a specific property kind, like a date or time, then you'll need to parse this yourself to save it in another model. You can do this by creating a custom action step, or by installing a step from the block store that parses it for you. Schema models themself don't work with any properties outside of the checkbox, number with decimals, number, or text properties. A date or a website URL will use the text kind.

Since schema models aren't the same as regular models, their relations are also different. Schema model relations can only be connected to other schema models and can only connect one way (unlike regular model relations that work back and forth).

The reason these relations only work one way is because they are only used to define the relation before actually processing it in your application.

Example:

Let's say you are importing user and project data from an external source, the User API.

When retrieving data from the User API, you are also importing the projects that your user is connected too. Your User schema model will have a Has many relation to the Project model, implying that when you are processing the data, the relation between the objects is automatically created.

If you want to import data the other way around, using the Project API, you would have to create a new relation via the Project schema model, in which one project belongs to one user (Has one).

Look into our HTTPS step article to find out more about setting up a connection using schema models.

Now we know, that schema models are temporary storage models that structure data for various functionalities in an application. They can be used to map API responses and support CRUD functionalities.

Relations in schema models are one-way connections to other schema models, with the only options being Has many and Has one relationships.