FaceFlow Developer Overview
FaceFlow Developer Overview
FaceFlow is the structured no-code building core inside PageFace.
From a technical perspective, it is best understood as a system of reusable objects, governed rendering, and clear ownership boundaries rather than as a freeform page editor.
The Core Technical Model
FaceFlow is composed of a small set of object types with distinct responsibilities:
- Variables for lightweight reusable fragments
- Components for reusable section contracts
- Layouts for shared page shells
- Pages for assembled experiences
- Lists for dynamic collection-driven output
- Forms for structured submission workflows
- Reviews for moderated trust content
Each object exists to solve a different level of the website system. When those boundaries remain clear, FaceFlow stays maintainable at scale.
How To Think About FaceFlow
The cleanest mental model is:
Variables -> small reusable fragments
Components -> reusable sections
Layouts -> page shells
Pages -> assembled experiences
Lists -> dynamic archives and collections
Forms -> lead and request workflows
Reviews -> trust and proof workflowsThis is not just a content hierarchy. It is an architectural hierarchy.
Object Boundaries
Use this decision model:
- use a Variable when the reuse unit is small and parameterized
- use a Component when the reuse unit is a full section with an editor-facing schema
- use a Layout when the concern is the page frame around many Pages
- use a Page when assembling a final route or experience
- use a List when content selection and pagination are part of the contract
- use a Form when collecting structured submissions
- use a Review when collecting and publishing governed public feedback
Most technical drift in FaceFlow happens when one object starts taking responsibility for another.
Example System
Layout:
default-site-shell
Page:
/enterprise/
Components:
hero-banner
benefits-grid
demo-request-section
review-strip
Embedded systems:
<div data-form-embed="enterprise-demo-request"></div>
<div data-review-embed="customer-success-reviews"></div>
Variables:
[[site-announcement]]
[[sales-contact-badge]]That example stays maintainable because every concern has a clear home.
Scope and Change Impact
Scope is one of the most important technical concepts in FaceFlow.
It controls whether a reusable section behaves like:
- a site-wide asset
- a layout-family asset
- a page-local asset
When technical users choose the wrong scope, change impact becomes hard to predict. A local section can accidentally become a global dependency, or repeated page content can stay duplicated long after it should have been shared.
Template Layer
FaceFlow templates are authored through Facet.
That means technical users should understand:
- field output
- conditionals
- loops
- filters
- Variable embedding
- safe section composition
Example:
<section class="hero">
<h1>{{ title }}</h1>
{{#if summary}}
<p>{{ summary }}</p>
{{/if}}
[[sales-contact-badge]]
</section>Facet is the template layer. FaceFlow is the structured object system around it.
What Technical Users Should Focus On
When designing with FaceFlow, the most important technical decisions are usually:
- where reuse belongs
- how much schema a section should expose
- whether something should be dynamic or static
- what the real change radius of a shared asset is
- how much of the page belongs in Layout versus Component versus Page composition
Those decisions have more impact on maintainability than any one piece of page content.
Common Technical Mistakes
Avoid these patterns:
- using Components where Variables would be clearer
- using Variables where a true section schema is needed
- pushing page-specific content into the Layout
- creating one oversized Component that tries to solve many unrelated use cases
- treating Lists like a fallback for unclear content architecture
- embedding business workflows without reviewing the full render and moderation path
Recommended Reading Order
That path moves from smallest reusable units to full website assembly and then into the template layer.