Fields define the columns of your entry tables. You're completely free to define the fields you need in your tables. Click Create Field in the upper right corner to create a new field. Drag & drop the fields to change the order. Right-click a field to duplicate or delete it.

The Slug of the field determines how the field is saved in the database and how you can access the field value on the entry:

$vacancy = table('vacancies')->first();

// Fields can be accessed by their slugs

// Each table also has 3 system fields

Field Types

Each field has a certain type, which determines what type of data the field can contain. All field types are listed below. Most of the time, you can change an existing field from one type to another.


A Text field contains plain text, without newlines.

You can insert the value in a view as follows. The value will automatically be escaped for HTML characters (which is default Blade behavior):

{{ $vacancy->title }}


A Textarea field contains plain text, with newlines. When you insert the value as above, the newlines will not be visible on the resulting page, because newlines must be converted to <br /> tags in HTML in order to become visible. You can use our @nl2br directive for this, which will do the conversion and escaping automatically:


Rich Text

A Rich Text field contains styled text, resulting in HTML code. Rich Text fields are automatically cast to an HtmlString object (provided by Laravel), so you can just do the following and it will just work as expected:

{{ $vacancy->text }}

We recommend using the prose classes provided by the @tailwindcss/typography plugin:

<div class="prose">
    {{ $vacancy->text }}


A Date field contains a date and is cast to a Carbon object, which you can use to do formatting or perform calculations:

{{-- Output: 30/04/2021 --}}
{{ $vacancy->date->addDays(2)->format('d/m/Y') }}

You can query the field as follows, with the use of the now() helper:

table('vacancies')->where('date', '>=', now()->subDays(2)->startOfDay())->get();


A Time field contains a time. Note that times are not converted to Carbon objects, so you'll get a string when accessing it:

{{-- Output: 15:35:00 --}}
{{ $vacancy->time }}

You can use our carbon() helper to convert the string to a Carbon object:

{{-- Output: 17:35:00 --}}
{{ carbon($vacancy->time)->addHours(2)->format('H:i:s') }}

Date & Time

A Date & Time field contains a combination of date & time. Just like Date fields, the result is always a Carbon object:

{{-- Output: 30/04/2021 15:35 --}}
{{ $vacancy->date_time->addDays(2)->format('d/m/Y H:i') }}

Note: to have correct values in your database, make sure the timezone in your user account is set correctly.


When you create a Boolean field, you will get a switch in the entry form. The result will always be 1 or 0.

Querying boolean fields works as follows:

{{ table('vacancies')->where('published', 1)->get() }}


Mostly slugs are used to create URLs. You can also use slugs to create unique handles to entries to use in your code.

Slug fields have 2 properties:

  • The value is slugified automatically, which means all special characters, uppercase letters, spaces... are converted. So My Pretty FiancĂ© becomes my-pretty-fiance.
  • The value must be unique for the table, so two entries with the same slug are not allowed.

Slug fields also have a Source attribute, which can contain a combination of fixed text and other fields. Type @ to insert a field. However, a source is not required:

  • If you don't provide a source, each slug must be filled in by hand. When you fill in a slug that already exists in the table, an error will be shown.
  • If you do provide a source, it works as follows:
    • If the field is empty, the source will be used to generate a slug automatically. If the slug already exists, it will make sure the slug is unique, for example by adding a -1 suffix. This also means that you can always make an existing slug empty and save the entry, to trigger the automatic generation.
    • If the field is not empty, the field will be checked for uniqueness. So you are still able to provide a slug yourself, or to change an existing slug, but it must be unique.
    • Existing slugs will never change automatically, even if the source changes, or the values of the fields used in the source change.


Just like Slug fields, Computed fields have a Source attribute, which can contain a combination of fixed text and other fields. Type @ to insert a field.

Computed fields cannot be changed by hand, and are always automatically generated by using the source.


A Geo field contains latitude and longitude coordinates. If you fill in the Address attribute, geocoding is used to determine the coordinates automatically. However, you can always change the coordinates by hand if they're not 100% correct (which happens sometimes with geocoding). Make the coordinates empty to trigger the geocoding again.

The Address attribute can contain a combination of fixed text and other fields. Type @ to insert a field. Typically, your table will have address, zip and city fields and a Geo field with address @address, @zip @city.

In your code, you can use the built-in near scope to query the results. The results will always be sorted from the nearest location to the furthest:

// Search around coordinates
table('locations')->near([50.8363129, 3.2834973])->get();

// Or use plain text to search near a location
table('locations')->near('Brussels, Belgium')->get();

// Optional second argument is a radius in km to search in
table('locations')->near('Brussels, Belgium', 30)->get();


Order fields contain a number which is auto-incremented. New entries will get the highest number. When you change the order of an existing entry, all other entries will be renumbered automatically.

If you have an order field, you can use it in your code:


Why do we deal with orders like this, and not with arrows or dragging?

  • From our experience, it is the fastest way to deal with orders, especially if you have a lot of entries. Just change the number and it's done.
  • Furthermore, this technique allows for multiple order fields. Imagine you have a table with products, which is used to make a product overview, but also to show some highlighted products on the homepage. For such situations, you can create 2 order fields: order_in_overview and order_on_homepage.


You can link any table to another table with Relation fields. The result is exactly the same as creating relationships between models in Laravel.

You can create both single and multiple relations:

// Single relation: returns an entry from the `brands` table

// Multiple relation: returns a collection with entries from the `categories` table

When you check the Define Inverse Relation switch, an inverse relation will be created on the linked table. This allows you to also access the data in the opposite way in your code:

// Single relation exists from `products` => `brands`
// The inverse relation defines `brands` => `products`

// Multiple relation from `products` => `categories`
// The inverse relation defines `categories` => `products`

You can also eager load relationships, just like in Laravel:

// Eager load the brand along with the products

// Or get only the products that have a brand

// Or query extra stuff on the related brands, for example all products
// that have a brand with a title starting with 'e'
    ->whereHas('brand', function ($query) {
        $query->where('title', 'like', 'e%');


Asset fields allow to upload files. By default, one file can be uploaded. You can allow multiple files in the field by checking Multiple. In that case, you can reorder them with drag & drop.

Take a look at the Assets section for all info about assets.


Page fields allow you to link entries to a page. Behind the scenes, it's in fact a relation to the page table.

Previous topic
← Tables
Next topic
Scopes →