Knowing how to create object types is one thing, but knowing when to create one is another. This guide walks you through a simple framework of three questions that will help you decide whether a new object type is the right call, or whether you can get by with what you already have.

Three questions to ask yourself

Before creating a new object type, work through these questions in order:

1. Is it a distinct group of notes?
2. Does this group have distinct properties?
3. Can queries and/or property visibility help instead?

If you answer "yes" to the first two and "no" to the third, a new object type is likely the right choice. But the answer is not always clear-cut. Let's look at two examples to see how the framework plays out in practice.

Example: People, one type or many?

A common question is whether to have a single Person object type, or separate types for friends, family, and colleagues. Let's run through the three questions.

1. Is it a distinct group?

If you are already thinking about splitting people into friends, family, and colleagues, you likely see them as distinct groups. So yes, this passes the first check.

2. Does this group have distinct properties?

Consider the properties you would want for each group. Colleagues might need fields like organization, job title, and work email. Friends might benefit from a gift ideas property. Family members might need birthday or relationship fields.

These groups do have somewhat different properties, which could suggest separate object types. But before jumping to that conclusion, move on to question three.

3. Can queries and property visibility help?

In many cases, the answer is yes. Here's how:

• Property visibility: You can add all the properties you might need to a single Person type, then use visibility settings to show only the relevant ones. Properties you rarely use stay tucked away until you need them.
• Categories: Add a category property (e.g. "Friend", "Family", "Colleague") to distinguish between groups without needing separate types.
• Queries: Set up queries to filter people by category. For example, create a query showing only colleagues in your marketing team, or only friends and family.
• Templates: Create templates for each category (e.g. a "Friend" template that pre-fills the category). This gives you the speed of distinct types while keeping everything unified.

A unified Person type also handles real-life overlap gracefully. When a colleague becomes a friend, or a friend joins your company, you don't need to move objects between types. Just update the category.

Example: A catch-all notes type that outgrows itself

It's common to start with a general-purpose object type like Notes or Pages and use it for everything. Over time, you may notice certain patterns emerging: some notes are clearly about organizations, others about families, and others about projects.

When to stay with one type

If the groups share mostly the same properties and the only real difference is the topic, you likely don't need separate object types yet. Use collections or tags to organize them instead.

When to split

If you find yourself wanting properties that only apply to a subset of your notes, for example industry and company size for organizations, or family members as a linked property for families, it may be time to create dedicated object types.

When you do split, you can use the type conversion feature to move existing objects into their new types without losing content.

Summary

There is no single right answer, and your approach can evolve over time. Here's a quick decision guide:

Remember: you don't need to get it perfect from the start. Capacities is designed to let you restructure as your needs change. Start with fewer types and split them when you have a clear reason to.