--- id: CON-PFM-MTD-003 name: Form and Page Layout feature: FEAT-PFM-MTD-03 product_area: platform module: metadata revision: 1 status: draft product_intent: confirmed implementation_evidence: partially-observed source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f definition: >- A form or page layout is a stored presentation definition for a single purpose, with administration and readership governed by that purpose. owned_by: MOD-PFM-MTD synonyms: - layout definition - record layout - web form (Rhythm 1.0) not_to_be_confused_with: - A category description supplies vocabulary without selecting a presentation. - An Explorer saved view arranges a list rather than an individual record page. facets: - name: Console page layout meaning: A stored staff-facing arrangement for viewing a record. used_for: Presenting individual records to staff. - name: Portal page layout meaning: A stored member-facing arrangement whose consumer availability is a separate question. used_for: Preparing member-facing record presentation. - name: Console form meaning: A staff-entry definition selected independently for creation and editing. used_for: Choosing staff-entry forms for create and edit. - name: Portal form meaning: A member-entry definition retained separately from console forms. used_for: Preparing member-entry presentation. - name: Purpose meaning: The immutable record-category purpose that determines eligibility and access. used_for: Applying the record owner’s access contract. - name: Assignment meaning: An owner-maintained reference selecting a compatible definition for a presentation slot. used_for: Selecting presentations and protecting assigned definitions. relationships: - to: CON-PFM-MTD-001 statement: Presentation kinds require a purpose with the corresponding capability. provenance: test source: >- services-platform:modules/layouts/tests/integration/services/persistence/purpose-capabilities.integration.spec.js#refuses a console form - to: CON-PFM-MTD-004 statement: Custom-object purposes support forms and layouts under object administration. provenance: test source: >- services-platform:modules/layouts/tests/e2e/custom-object-forms.e2e.spec.js#stores a form for the purpose of an active custom object acted_on_by: - CAP-PFM-MTD-008 visible_to: - ACT-PFM-007 - ACT-PFM-009 - ACT-PFM-011 evidence: - 'services-platform at ad3f6a6582843008ed0f5a17b131878d15829af1: docs/layouts.md; modules/layouts/** .' - >- react-console at baf6dae382d6f41dce976c7f848667ccc37e076f: components/forms/management, components/forms/designer, components/layout-designer, lib/forms/storage/console-forms.ts, lib/layout-designer/persistence.ts, lib/configuration/layout-definitions.ts. supersedes: [] --- # Form and Page Layout ## What It Is Forms and page layouts describe how people enter or view a record. A form supports creating or editing information. A page layout organizes a record for reading. Console and portal definitions are separate kinds, allowing the same record category to have different presentations for different audiences. A definition has a name, a permanent purpose and a stored document. Platform preserves that document as opaque content within its contract. Storing a valid document does not establish that every consumer renders every possible configuration or that a portal surface already uses the definition. ## Why It Matters Administrators need to arrange information for the work people perform. Creating a contact can need a smaller form than editing an established member, and a staff record page can need information that a member-facing page should omit. Separate definition kinds and assignments make those choices explicit. Authorization must follow the category whose presentation is being changed. A general configuration label would obscure who controls contact forms or custom-object pages. Purpose-specific access connects administration to the corresponding record owner and keeps unrelated definitions undisclosed. ## How It Works An authorized administrator stores a bounded document under an available purpose. The purpose must support the requested definition kind and cannot be changed after creation. Names and documents have size and shape limits, while updates use version checks and honor locks. The API evaluates purpose-specific permission before exposing or changing a definition. A caller without readership does not discover the definition through direct requests or general lists. Unknown purposes and unrelated wildcard grants do not provide authority to create definitions. Assignments connect an owner’s configuration to an existing compatible definition. References must agree on workspace, kind and purpose. A definition that remains assigned cannot be deleted; administrators first clear or move its uses. Create and edit assignments can select different forms or share one form. ## What It Contains The four presentation kinds are console page layout, portal page layout, console form and portal form. Purpose identifies the category being presented. Assignment identifies the owner-selected location where the definition is used. These facets distinguish stored content from its place in a product workflow. Custom-object forms use the object’s purpose and suitable record access. Draft and active definitions can support configuration, while unavailable or archived objects do not authorize ordinary form use. Native purposes follow their own declared capability and permission mapping. ## What It Is Related To Record types supply the vocabulary and capability eligibility behind a purpose. Custom objects contribute their own purposes and property descriptions. Field definitions and rules inform the controls a form can offer, but a stored layout does not replace service validation of a record write. Assignments belong to the record owner. That boundary allows Platform to protect a shared definition from deletion without deciding which contact type or other owner setting should select it. Consumers remain responsible for rendering and using the selected presentation. ## What Needs Deciding The product should distinguish the stored-definition contract from the rendering features promised by each consumer. Portal consumption and several designer details remain weaker than persistence and authorization evidence. Before design assumes parity between audiences, those surfaces need explicit decisions and acceptance proof tied to the intended presentation behavior.