> 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/purpose.md). # Purpose ## Mental Model: How to Think About the Hierarchy Motion’s hierarchy works like an organization chart for your work — moving from broad containers down to specific actions. Each layer has a distinct purpose, and together they create a predictable structure that scales with your team. * **Workspace** → The top-level container for all your team’s work. A workspace is like the company office — everyone belongs here, but not everyone sees everything inside. * **Folders** → Broad categories of work, such as *Marketing*, *Product Development*, or *Customer Success*. Folders group projects by theme or function. * **Projects** → Execution units with goals, deliverables, and timelines. A folder may hold multiple projects (e.g., *Website Redesign* inside *Marketing*). * **Tasks** → Individual pieces of work within a project. Tasks capture specific actions (e.g., *Write homepage copy*). The mental model is simple:\ **Workspace → Folders → Projects → Tasks** Each layer narrows focus: from company-wide visibility at the top, to day-to-day execution at the bottom. ## Relationships: Containment, Links, and Dependencies Objects in Motion don’t exist in isolation. Their value comes from how they relate to one another. There are three primary relationship types to understand: * **Containment** → A structural “belongs to” relationship. * *Example*: A folder contains projects, a project contains tasks. * Think of this as the hierarchy’s backbone — it organizes work into predictable layers. * **Links** → Cross-references between objects that aren’t in the same container. * *Example*: A task in *Marketing* may link to a doc in *Product* for shared context. * Links create flexibility without breaking the hierarchy — connecting work across teams, functions, or folders. * **Dependencies** → A sequencing relationship that defines order. * *Example*: Task B can’t start until Task A is complete (*“Design mockups → Build website”*). * Dependencies allow Motion to model real workflows where timing and handoffs matter. **Summary:** Containment gives work structure, links connect work across boundaries, and dependencies define flow. Together, these relationships make the hierarchy both stable and flexible. ## Metadata: What Applies Where Metadata gives structure to work by adding attributes like owners, due dates, or tags. In Motion, different layers of the hierarchy support different types of metadata. * **Workspace-level metadata** → Global settings such as workspace name, members, and default configurations. Applies everywhere but is rarely adjusted day-to-day. * **Folder-level metadata** → High-level attributes like owners, descriptions, and labels that describe the category of work (e.g., *Q4 Initiatives*). Folders don’t usually carry deadlines but do define scope. * **Project-level metadata** → The richest layer of metadata. Projects support owners, due dates, statuses, tags, and descriptions — the core information needed to manage initiatives. * **Task-level metadata** → Attributes like assignee, due date, effort, priority, and status keep execution on track. This is where work becomes concrete and schedulable. **Guiding principle:** The higher the layer, the more descriptive and structural the metadata. The lower the layer, the more execution-focused it becomes. ## Lifecycle: From Creation to Archive Work in Motion follows a cycle. Each layer of the hierarchy — from project to task — moves through stages that repeat across initiatives. 1. **Creation** → New work is scoped at the right level. A folder is opened for a program, a project is started for an initiative, or a task is created for a deliverable. 2. **Activation** → Metadata like owners, due dates, and priorities bring the object to life. The work is now actionable and visible to collaborators. 3. **Execution** → Tasks are worked on, dependencies are resolved, and progress is tracked. Projects shift status as milestones are met. 4. **Review** → Outputs are checked, approvals are added, and the team ensures goals were met. 5. **Archive** → Completed work is closed and stored, keeping history intact without cluttering current views. 6. **Reference & Restart** → Archived work remains searchable, serving as context for new cycles. Learnings from one project inform the next, and the lifecycle begins again. **Key idea:** Hierarchy isn’t static. Folders, projects, and tasks continuously cycle through creation, execution, and closure — with archives acting as memory that feeds the next round of work. --- # 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/purpose.md?ask=&goal= ``` `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.