Understanding project types and forms

Project types are derived from LUMA. The Project Types menu in Platform Administration lists them, and from a selected type you configure the form that shapes its project view.

Reaching this configuration depends on two LUMA services: one provides visibility of the menu, and one is required to open the Form Builder. For the exact permissions, see Platform Administration permissions.

The Form Builder defines how a project view is presented. For a given type view state, it controls which tabs display and in what order. For field tabs, it controls which fields appear, how they are grouped, and the conditional logic that shows or hides them. It also defines role pickers and a tailored briefing experience.

The output of this configuration is a form template: metadata written against a LUMA type view state. The project view reads this metadata and renders the tabs, fields, and layout accordingly. The navigation and content of a project view that has a template defined are therefore derived from the Form Builder, not fixed by the system.

Projects fall into two categories.

A non-content project is the default root project type present in every LUMA instance. It is not a descendant of the content project type.

A content project is a system-level subtype of project, defined as a descendant of Asset: Project: Content Project. It exists to let you render Form Builder templates, control the visibility of project tabs, and keep this configuration separate from your existing project types. A content project can also have its own dedicated project list, distinct from other project types.

Creating a content project is not mandatory. All project types can use the Form Builder and render the template metadata it generates. The content project is the option to choose when you want a clean separation between this configuration and an existing type tree, rather than reworking that tree.

Deliverables-based briefing (DBB) is a briefing approach built on a distinct asset concept: the deliverable.

A deliverable is a system-level subtype of resource, defined as a descendant of Asset: Resource: Deliverable. It is separate from a traditional project resource and provides a tailored experience when briefing. A deliverable has configurable specification fields, a dedicated population experience, and the ability to create child projects from it.

DBB lets you establish deliverable placeholders and their specifications, populate those placeholders, and then manage and evaluate both populated and unpopulated placeholders. These activities map to three deliverable tabs that the Form Builder can add to a view:

DBB is available only where deliverables are configured in LUMA, that is, where asset types descend from the deliverable root. The field-level detail of each tab is covered in the project form tabs reference.

The model follows a clear chain.

A LUMA project type has a type view state. The Form Builder writes configuration against that state as a form template. The project view renders the form template as tabs, fields, and layout. Where deliverables are configured in LUMA, the Form Builder can add the deliverable tabs that make DBB available within the view.

Understanding this chain clarifies the order of configuration: the project type and its view state first, then the form built against it, and, where briefing on deliverables is needed, the deliverables that unlock the DBB tabs.