Content Types and Records

The older “everything is an item type” explanation is too loose for the current product.

In practice, users need to distinguish between:

• core repository item types
• folder-backed entity subtypes
• connected-account records such as calendar events
• workflow views that are built on top of folders and metadata

The real content model

These categories are not interchangeable.

Core repository items

These are the main operational units most users create directly:

• Folders: structure and permission boundaries
• Files: durable documents and binary content
• Notes: text-first collaborative content
• Task lists: executable work with subtasks and ownership
• Chats: conversational threads
• Emails: stored message records where email is brought into the repository

Folder-backed entities and workflow records

Some important business objects are actually specialized folders or folder-backed records:

• Companies
• Contacts
• Cases

Those appear in dedicated views, but they still live inside the repository’s permission and folder model.

Connected-account records

Some visible records are not ordinary repo items in the same sense:

• calendar events in connected calendars
• live provider mailbox state before it is archived into SynckHub

Teach users to work with those surfaces without pretending they behave exactly like plain files or folders.

In this section

• folders.md
• files.md
• notes.md
• chats.md
• tasks.md
• contacts-and-companies.md
• cases.md
• events.md

Working rule

Start by asking:

• is this normal repository content?
• is this a folder-backed business record?
• is this external provider data shown in SynckHub?

That question matters more than arguing about labels.

Decision rule

Ask:

• does this need a durable collaboration boundary? -> folder or folder-backed record
• does it need document lifecycle and versioning? -> file or note
• does it represent execution with ownership and status? -> task list or case workflow
• is it relationship data? -> contact or company
• is it live provider schedule state? -> calendar event

Common mistakes

• treating companies or contacts as just another note
• treating cases as generic folders with no workflow semantics
• treating calendar events as if they were ordinary repository documents
• teaching every view as if it owns a separate object model