---
title: What is an Object?
url: https://tideswell.xyz/docs/objects
description: An Object is a kind of record your team defines. Here is what they are for, and when to create one.
---

> Documentation index: fetch https://tideswell.xyz/llms.txt to discover every page before exploring further.

# What is an Object?



An **Object** is a kind of record your team defines. Tideswell arrives knowing about tasks,
purchase orders, suppliers, customers and stock. An Object is how you add the things your
business tracks that nobody could have shipped for you: repairs, sample requests, fabric
trials, press loans, store visits, quality checks.

You will meet the word in two places. **Objects** is a group in the main sidebar, listing
the ones your workspace has. **Settings › Objects** is where an admin builds them.

## What does an Object actually give you? [#what-does-an-object-actually-give-you]

Once you define one, it behaves like any other part of Tideswell rather than like an
attachment bolted on the side. Define an Object called Repairs and you get a Repairs list in
your sidebar, a **New Repair** button, and a record for each repair.

Each of those records can carry whatever information you decide it should. It can be linked
to the supplier and the purchase order it relates to, move through stages your team named,
be commented on and given an owner, keep a history of who changed what, and be restricted so
that only the people who should see it do.

That is the point of the feature. The information stops being something one person maintains
and becomes something the business holds.

## Why not just use a spreadsheet? [#why-not-just-use-a-spreadsheet]

Because a spreadsheet is where most of this starts, and because a spreadsheet cannot connect
to anything.

Fairgreen Golf Co. tracked warranty repairs in a shared sheet for two years. The sheet
knew a customer's name and a fault, and that was the end of it.

It could not say which mill wove the fabric that failed, because the mill lived somewhere
else entirely. Nobody could be stopped from reading the customer's address.

When a repair sat untouched for three weeks, nothing noticed. And when someone asked
"which fabric fails most", the answer took an afternoon of sorting.

As an Object, each of those is ordinary. A repair links to the supplier record it came
from, covered in <Ref to="objects/link-objects" />. Who can open it is a setting, covered
in <Ref to="objects/permissions" />.

The steps it moves through are yours to define, covered in <Ref to="objects/stages" />.
And the question about failing fabric is a filter, not an afternoon.

## When should you create one? [#when-should-you-create-one]

An Object earns its place when the thing you are tracking has most of these:

* **You have many of them.** One-off information belongs in a document, not an Object.
* **Each one has a life.** It arrives, something happens to it, it finishes. That shape is
  what <Ref to="objects/stages" /> exists for.
* **More than one person touches it.** If only you ever look at it, we would leave it in a
  spreadsheet. That is less work and nobody else is waiting on it.
* **It relates to something Tideswell already knows about**, such as a supplier, a product
  or a purchase order. This is where an Object pulls decisively ahead of a spreadsheet.
* **You want to ask questions across all of them.** How many are open, which supplier sends
  the most, how long they take.

Good candidates at a brand like Fairgreen: **Repairs**, **Sample requests**, **Fabric
trials**, **Press loans**, **Store visits**, **Production runs**, **Quality checks**.

## When is something else the better fit? [#when-is-something-else-the-better-fit]

Three things look like Objects and are not.

* **A piece of work somebody has to do** is a task. Tasks already have assignees, due dates,
  priorities and a board. If what you are describing is "somebody needs to do this by
  Friday", use a task.
* **Something you write rather than fill in** is a document. Objects are made of fields with
  answers in them. A brand guideline or a meeting note is prose.
* **Something Tideswell already ships** should stay as it is. Suppliers, purchase orders,
  customers and stock all arrive with logic built around them that a hand-made Object would
  not get. <Ref to="objects/built-in-or-your-own" /> walks through what already exists, so
  you can check before you build.

## Do you need to be an admin? [#do-you-need-to-be-an-admin]

To **build or change** an Object, yes. **Settings › Objects** does not appear at all for
anyone who is not an admin of the workspace.

To **use** one, no. Who can see and edit the records inside an Object is a separate set of
controls, covered in <Ref to="objects/permissions" />, and
<Ref to="concepts/who-can-do-what" /> explains how a person's role turns into what appears
on their screen.

## Read this section in order [#read-this-section-in-order]

The pages below run from deciding whether you need an Object at all, to running one your
team relies on.

Start with <Ref to="objects/built-in-or-your-own" /> to check that what you want does not
already exist. Then read <Ref to="objects/plan-your-fields-first" /> before you build
anything: it is four minutes, and a few of the choices you are about to make are fixed once
you save them. After that, <Ref to="objects/create-an-object" /> and
<Ref to="objects/add-a-field" /> are the build itself.

Once records start arriving, <Ref to="records" /> covers the day to day.