> For the complete documentation index, see [llms.txt](https://www.usemotion.com/help/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.usemotion.com/help/knowledge-management/data-hierarchy/concept-data-hierarchy/use-case.md).

# Use case

## Folder vs Project: When to Use Each

Folders and projects serve different purposes in Motion’s hierarchy. Folders organize at a higher level; projects are where execution happens.

| Use a folder when                                                                                       | Use a project when                                                                                  |
| ------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| You need a **container for related projects**.                                                          | You’re driving **execution toward a specific goal**.                                                |
| Work is grouped by **function, department, or theme** (e.g., *Marketing*, *Finance*, *Q4 Initiatives*). | Work has a **timeline, deliverables, and milestones** (e.g., *Website Redesign*, *Product Launch*). |
| Access needs to be **granted broadly** — everyone in the folder can see the projects inside.            | Access should be **scoped more narrowly** to a single initiative.                                   |
| Metadata is descriptive: labels, owner, high-level scope.                                               | Metadata is operational: due dates, status, tasks, dependencies.                                    |
| The work inside will **continue over time** (a folder may hold multiple ongoing projects).              | The work is **time-bound** — it ends when deliverables are complete.                                |

**Decision rule:**\
👉 *If you’re organizing work thematically or structurally, use a **Folder**.*

👉 *If you’re planning and executing toward an outcome, use a **Project.***

## Cross-Cutting Rules

No matter where you are in the hierarchy — from folders down to subtasks — a few practices apply everywhere. These rules make Motion scalable, searchable, and easier for both humans and AI to navigate.

* **Naming conventions** → Keep names short, consistent, and descriptive. Use patterns your team agrees on (e.g., *Q4-Marketing-Website* vs. *Website Project*). Consistent names improve searchability and AI relevance.
* **Tagging and labels** → Apply tags at the project and task level to group work across folders. Tags add a second dimension of organization beyond hierarchy.
* **Searchability** → Everything in Motion is searchable by title, tags, and metadata. The cleaner your naming and tagging, the faster teammates (and AI) find what they need.
* **Metadata hygiene** → Keep owners, due dates, and statuses up to date. Inaccurate metadata creates friction at every layer.
* **AI alignment** → Remember: hierarchy and metadata are what Motion’s AI uses to ground its outputs. Clean structure = better context = more accurate results.

**Key principle:** Hierarchy organizes the work, but **cross-cutting rules keep it usable at scale.**


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://www.usemotion.com/help/knowledge-management/data-hierarchy/concept-data-hierarchy/use-case.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.