A model consists of properties, which can be different data types, for example, a free text, a lookup, or a number field. It's like a database table, except the data is often imported into your model from an external data source. This table shows an example structure of a model.
After you create your model and add your properties, you can input values into your properties. The values related to each other are part of the same record or instance. This table shows an example of a model with four instances, each with its own unique ID. Each property has a specific data type, for example, a name, email address, lookup, and free text.
Applaud uses the unique instance ID to show the relevant property values when adding content to a page. So, for example, if you want to create an employee directory, you need to decide which information you want to show about employees, such as Name, Job, Department, and so on. Then, when you select a person's name, you can have another page open to see the other relevant data just for that person. This image shows the instance ID for this person's record in the model. It's how Applaud knows to show only the other property values in this instance in the detail block on this page.
Model relationships
You can link models and create a relationship to use more than one model's data in the same function, for example, when adding content blocks to pages or using the models' properties in a workflow step. You can see a model's relations on its Schema page. The relations describe how the models interact with each other.
See our example
If we want to design a simple Expense claim app, we could have a Person model, an Expense claim model, and a Currency model. Then we would need to link them using relationships.
Person model and Expense claim model relationship
|
Firstly, let's look at the relationship between the Person and Expense claim models. For example, what's the least number of expense claims a person could make? And what are the most? |
|
|
A person might never make an expense claim, or they could make numerous expense claims. To illustrate this, we use the "zero or many" notation. |
|
|
Now, let's consider the reverse relationship. An expense claim can only ever have one person. To illustrate this, we use the "one (and only one)" notation. |
|
Expense claim model and Currency model relationship
|
Now let's look at the relationship between the Expense claim and Currency models. |
|
|
An expense claim must have at least one currency item but could have many Currency items on the claim. To illustrate this, we use the "one or many" notation. |
|
|
In the reverse relationship, currency types can exist with no one making an expense claim, or a person can make an expense claim with many currencies. To illustrate this, we use the "zero or many" notation as we did previously. |
|
Inverse relationships
You can link a model back to itself, which creates an inverse relationship. For example, you can add a foreign-key type property to a model and choose the model to which you're adding the property. Applaud requires you to give the inverse relationship a name. For example, if you add a foreign key type property to the Person model and call it "Manager," you can call the inverse relationship "Direct reports."
Inverse relationships are beneficial when calling APIs because you can retrieve data such as:
- /person/123/manager - get the person's manager
- /person/123/direct-reports - get a person's direct reports
Tasks you can perform here:
- Create a new model
- Add a property to your model's schema
- Use HTTP API methods to interact with data in your model's properties
- Add an access control policy
- Import new or updated data into your model
- About model data exports
- Create a workflow
See more:
- About a model's schema
- About a model's API
- About access control policies
- About model data imports
- About model data exports
- About model workflows