Review Developer Docs
Review Developer Docs
Reviews are structured models for collecting, moderating, and rendering public feedback in FaceFlow.
They allow technical teams to manage reputation-sensitive content as governed website output rather than as unmanaged freeform testimonials.
Core Responsibility
A Review model is responsible for:
- configurable review models
- structured rating fields
- public submission capture
- moderation and verification policy
- embeddable display output
- publication control
This makes Reviews suitable for trust-driven website sections that need both public visibility and operational control.
Core Review Model
A Review model usually combines:
- core review identity fields
- rating fields
- optional custom rating dimensions
- moderation settings
- verification behavior
- presentation and output settings
In practice, the Review layer defines both what feedback can be collected and what approved feedback can be published back to the website.
Conceptually:
{
"name": "customer-success-reviews",
"fields": [
{ "name": "author_name", "type": "text", "required": true },
{ "name": "rating", "type": "rating", "required": true },
{ "name": "review_title", "type": "text", "required": true },
{ "name": "review_content", "type": "textarea", "required": true }
],
"settings": {
"moderation": "required",
"verification": "optional"
}
}Submission and Publication Flow
At a high level:
- a Review model is defined centrally
- it is embedded into a Page through a Component
- visitors submit feedback
- moderation and verification rules are applied
- approved entries are rendered back into the website experience
Conceptually:
review widget render
-> visitor submission
-> pending review state
-> moderation / verification
-> approved review publishedThis is why Reviews should be treated as governed public content, not just another input form.
Rating Structure
Review models can support:
- overall rating
- review title
- review content
- custom rating dimensions for more structured feedback
Example:
overall_rating
service_rating
communication_rating
value_ratingUse extra dimensions only when they improve trust and interpretation.
Review Model Example
A technical review should be able to inspect the model shape clearly:
{
"name": "service-review",
"fields": [
{ "name": "author_name", "type": "text", "required": true },
{ "name": "rating", "type": "rating", "required": true },
{ "name": "review_title", "type": "text", "required": true },
{ "name": "review_content", "type": "textarea", "required": true }
],
"settings": {
"moderation": "required",
"verification": "optional"
}
}This helps teams review what is being collected, what is required, and how much moderation load the model is likely to create.
Moderation and Verification
Moderation and verification are central to Review design.
Technical teams should decide:
- whether entries require approval
- whether additional verification is needed
- who owns publication decisions
- how reputation-sensitive content should be handled
The higher the reputation risk, the stronger the controls should usually be.
Embedding Reviews
Reviews are typically embedded into page sections through Components.
A common embed marker is:
<div data-review-embed="service-review"></div>Example section:
<section class="customer-proof">
<header>
<h2>What customers say</h2>
</header>
<div data-review-embed="customer-success-reviews"></div>
</section>This keeps review collection and display reusable while allowing the Page to place trust content where it has the most impact.
Fixed vs Field-Backed Embeds
There are two common embed patterns.
Use a fixed managed review model id when the template should always render one specific Review model:
<div data-review-embed="customer-success-reviews"></div>Use a field-backed embed when a Component exposes a reviewSelect field and authors should choose the managed Review model at authoring time:
<div data-review-embed="{serviceReview}"></div>Decision rule:
- fixed embed -> one stable trust workflow owned by the template
- field-backed embed -> reusable Component with author-selectable review workflow
Integration Pattern
The clean runtime path is:
Review model
-> Component embed via reviewSelect or explicit data-review-embed marker
-> Page composition
-> public submission, moderation, and approved display outputThat keeps reputation-sensitive workflow logic centralized instead of scattering it across one-off page markup.
Operational Guidance
Good Review design usually favors:
- one Review model per business context
- clear moderation ownership
- structured rating dimensions only where they add real value
- a submission experience short enough to preserve quality
- a publication model that supports trust instead of noise
If a Review model becomes too broad, quality and moderation usually become harder to manage.
Rating Contract Guidance
Keep the rating model proportional to the public workflow.
Typical patterns:
- simple trust section -> overall rating + title + review body
- service-quality workflow -> overall rating plus a small number of dimensions such as service, communication, or value
If a short public flow needs too many rating inputs, submission quality and completion rate usually drop.
Technical Guidance
- separate Review models by business context
- align moderation and verification policy with reputation sensitivity
- keep public review collection short enough to maintain submission quality
- treat published review content as governed output
- review collection, moderation, and display together as one workflow
Anti-Patterns
Avoid:
- one giant Review model used for unrelated business contexts
- too many rating dimensions for a short public flow
- publishing without clear moderation ownership
- treating Reviews like unmanaged testimonials pasted into Components
- designing the input flow without reviewing the display and approval model
Example Build Pattern
Review model:
customer-success-reviews
Component:
review-strip
Embed:
<div data-review-embed="customer-success-reviews"></div>That pattern keeps trust content reusable and governed.