Skip to main content

​
The Two Levels of Objects

Not all work is a flat to-do list. Some initiatives are large and complex, requiring multiple levels of detail. To model this, Luklak allows you to define two levels for your Object Types: Standard and Sub-Object. This structure is the foundation for creating the strict, built-in Parent-Child Relationships in your data model, which is the primary method for breaking down large pieces of work into smaller, manageable parts.

​
Defining the Levels

🧊 Standard Object

A Standard Object is a top-level, independent entity. It can exist on its own without needing a parent. Every hierarchy must start with a Standard Object.

Examples: 🧊 Project, 🧊 Epic, 🧊 Customer Request.

🧊︎ Sub-Object

A Sub-Object is a child entity that is nested under a Standard Object. It cannot exist on its own and is always part of a parent-child relationship. Its purpose is to break down the parent’s work.

Examples: 🧊 Task (as a child of 🧊 Project), 🧊 User Story (as a child of 🧊 Epic).

​
When to Use Sub-Objects: The Architect’s Decision

Choosing to structure your Object Types as a Standard/Sub-Object hierarchy is a key architectural decision. This pattern is the ideal choice when:
  • The work has a natural hierarchy: A Project is naturally composed of Tasks.
  • The child item cannot exist alone: A Task without a Project is meaningless in this context. The child is fundamentally a component of the parent.
  • You need a true work breakdown structure: This is the primary use case for tracking the completion of a larger initiative by measuring the progress of its constituent parts.
[Image Placeholder: A diagram showing a ‘Project’ Object Type at the top (labeled ‘Standard Object’). Below it are ‘Task’ and ‘Milestone’ Object Types, both nested under and pointing to the Project (labeled ‘Sub-Objects’).]

​
How It Works in Practice

When you define this hierarchy in your 📋 Function, it directly impacts the user experience in the ⏹️ Space:
  • Automatic Linking: When a user creates a 🧊 Task (Sub-Object) from within a 🧊 Project (Standard Object), the two are automatically and permanently linked in a parent-child relationship.
  • Dedicated UI: The parent 🧊 Project Object will have a built-in “Sub-objects” section in its detail view. This is where users can see, manage, and create all of its child 🧊 Tasks in one convenient place.
[Guidejar Placeholder: A tutorial showing a user viewing a ‘Project’ Object. They click on the ‘Sub-objects’ tab, which shows a list of existing ‘Tasks’. They then click a ’+ New Task’ button within this section to create a new, automatically linked Sub-Object.]
Architect’s Tip: If the “child” item can and should exist independently, a flexible Object Picker Field is a better choice for creating the relationship.

​
What’s Next?

You now understand how to create built-in hierarchies by defining Object levels. To learn about other, more flexible ways to connect your Objects, explore our complete guide to Object Connections.