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?

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?

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 Link one Object to another. Who can open it is a setting, covered in Who can see and edit an Object.

The steps it moves through are yours to define, covered in The stages a record moves through. And the question about failing fabric is a filter, not an afternoon.

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 The stages a record moves through 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?

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. Decide between a built-in record and your own Object walks through what already exists, so you can check before you build.

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 Who can see and edit an Object, and How to work out who can do what in your workspace explains how a person's role turns into what appears on their screen.

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 Decide between a built-in record and your own Object to check that what you want does not already exist. Then read Plan your fields before you add them 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, Create an Object and Add a field and pick the right type are the build itself.

Once records start arriving, Working with records covers the day to day.