}
{caption && !thumbnail && {caption}{src && Select the image to view it full size.}}
;
};
Imagine a team delivering a website for Relio. The client, the website
project, and the people involved have different details, but the team needs to
see how they relate. Kato gives each item a record and connects those records.
## The building blocks
| Building block | What it answers | Example |
| ---------------- | -------------------------------------------- | -------------------------------------- |
| **Object** | What kind of thing are we tracking? | Projects |
| **Attribute** | What do we need to know about it? | Name, status, target date |
| **Record** | Which specific item is this? | Relio website |
| **Relationship** | What is it connected to? | The project’s client |
| **View** | Which records and details do we need to see? | Active projects, sorted by target date |
Attributes are also called **fields** in the API. They describe the values a
record can hold, including text, dates, choices, and links to other records.
## Follow one piece of work
The Projects object defines the details you collect for every project. A record
holds those details for Relio's website. A relationship connects that project
to its client, and a view helps your team focus on projects that are still active.
Changing the view changes what you see. Editing a record changes the underlying
information wherever that record is shown.
## Work through the Relio example
Suppose your workspace tracks clients and their projects. You want to know
which projects are active and which client each belongs to.
1. Use a **Clients** object for client records. Add **Relio** as one record.
2. Use a **Projects** object for project records. Add **Relio website** as
one record, with its own status and target date.
3. Give Projects a **Client** relationship pointing to Clients. Link the
Relio website record to the existing Relio client record.
4. Create a Projects view that filters for your active status and shows the
target date. You now have a focused view without creating another object.
5. Create tasks for actions such as revising the brief. Link them to the project
rather than turning every action into another project record.
The result is a connected structure: the client can remain in your workspace
while individual projects and tasks move through their own lifecycles.
## Know which change you are making
| Change | What it affects |
| ---------------------------------- | ------------------------------------------------- |
| Add a Target date attribute | The structure available to records in that object |
| Set a target date on Relio website | That record's value |
| Hide Target date from one view | The presentation of that view |
| Link Relio website to Relio | The connection between those two records |
A frequent source of confusion is trying to fix a presentation problem by
changing the structure. If a table feels crowded, hide unnecessary columns in
the view. You do not need to remove the underlying attributes.
## Check your understanding
If you wanted to track another Relio project, would you create a new
workspace, an object, or a record? In this example, create another **record**
in Projects and link it to the same client. You only need another object when
you are tracking a distinct kind of thing with a different structure.
## Start with a small structure
Use the objects already in your workspace where they fit. Add attributes for
information your team will maintain, then connect records that need shared
context. Add another object when you need to track a distinct kind of thing.
Decide when an object, an attribute, or a view is the right fit.
## Related topics
- [Bring your data into Kato](/documentation/importing-data.md)
- [Connect related records](/documentation/data/relationships.md)
- [Changelog](/changelog.md)
- [Choose what to track](/documentation/data/objects.md)
- [Design useful attributes](/documentation/data/attributes.md)
: