Encore Health OS Platform Terminology Glossary

Version: 1.2.0
Last Updated: 2026-02-05
Status: Active Purpose: Unified glossary of data-related terms to eliminate confusion between similar concepts.

See Also: PF/FW Documentation Review for detailed analysis of terminology overlap.

Form Wizard (FW-31)

Also called: Multi-step form, guided form, wizard mode form
NOT the same as: Module Wizard (PF-41) Purpose: Multi-step data capture interface built on FW-01 forms with step validation, progress tracking, and draft persistence. Storage:

Config: fw_forms.wizard_config JSONB
Steps: fw_form_pages.step_config JSONB
Progress: fw_form_submissions.wizard_progress JSONB

Scope: Form-specific, extends multi-page forms with wizard behavior. Example:

Resident intake wizard (5 steps of questions)
Employee satisfaction survey with conditional sections
Multi-part compliance assessment

Use When:

You have a complex form that benefits from step-by-step guidance
Data goes to fw_form_submissions (form submissions table)
Users need to save/resume progress on data capture

See: FW-31 Spec

Module Wizard (PF-41)

Also called: Business wizard, configurable wizard, onboarding wizard
NOT the same as: Form Wizard (FW-31) Purpose: Configurable business process wizard for module-specific workflows like onboarding, payroll, and admissions. Storage:

Templates: pf_wizard_templates table
Executions: Module-specific tables (e.g., hr_onboarding_instances)

Scope: Organization-wide, supports custom step components per module. Example:

Employee onboarding wizard (HR module)
Resident admission wizard (RH module)
Payroll run wizard (HR module)

Use When:

Building a business process (not just data capture)
Data goes to module-specific tables (not form submissions)
Steps require custom React components (not just form fields)
Organizations need to customize the wizard flow

See: PF-41 Spec

Wizard vs Form Quick Reference

Aspect	Form Wizard (FW-31)	Module Wizard (PF-41)
Purpose	Data capture	Business process
Data Storage	`fw_form_submissions`	Module-specific tables
Step Types	Form fields only	Form, Custom, Review
Customization	Field configuration	Full step customization
Use Case	Surveys, intake forms	Onboarding, payroll

Workflow Template (FW-28)

Also called: Automation template, workflow pattern, reusable workflow
NOT the same as: Document Template (PF-64), Form Template, Spec Template Purpose: Pre-built workflow automation pattern that can be cloned and customized. Storage: fw_workflow_templates table Scope: Organization-wide, can be shared via marketplace. Example:

“Employee Onboarding Workflow” template
“Invoice Approval” workflow template
“Incident Response” automation template

Use When:

Creating reusable automation patterns
Sharing workflow best practices across organizations
Quickly starting new automations from proven patterns

See: FW-28 Spec

Document Template (PF-64)

Also called: Letterhead template, policy template, letter template, PDF template
NOT the same as: Workflow Template (FW-28), Form Template, Spec Template Purpose: Structure template for printable documents (policies, letters, reports) with letterhead and sections. Storage:

Templates: pf_document_templates table
Letterheads: pf_letterheads table
Approval Chains: pf_approval_chain_templates table

Scope: Organization-wide, supports system starter templates. Example:

Healthcare Policy Template (CARF-aligned sections)
Standard Business Letter template
Compliance Report Cover template
Employee Offer Letter template

Use When:

Generating printable PDF documents
Needing consistent branding (letterhead, footer)
Documents require approval workflows
Exporting policies, procedures, or formal letters

See: PF-64 Spec

Form Template (FW-01)

Also called: Reusable form, form pattern, clonable form
NOT the same as: Document Template (PF-64), Workflow Template (FW-28) Purpose: Form definition marked as a template that can be cloned to create new forms. Storage: fw_forms table with settings.is_template = true Scope: Organization-wide for cloning. Example:

“Standard Incident Report” form template
“Monthly Assessment” form template
“Satisfaction Survey” form template

Use When:

Creating reusable form structures
Quickly creating new forms from proven patterns
Sharing form designs within an organization

See: FW-01 Spec

Spec Template (Developer)

Also called: Documentation template, spec boilerplate, markdown template
NOT the same as: Document Template (PF-64), Workflow Template (FW-28), Form Template Purpose: Markdown template files for writing specifications and documentation. Storage: specs/_templates/ directory Scope: Developer tools, not stored in database. Example:

SPEC_TEMPLATE.md - Feature specification template
WIZARD_SPEC_TEMPLATE.md - Wizard specification template
TASKS_TEMPLATE.md - Task breakdown template

Use When:

Writing a new feature specification
Documenting a wizard UX design
Creating implementation plans

See: Template Index

Wizard Template (PF-41)

Also called: Module wizard template, business wizard template
NOT the same as: Workflow Template (FW-28), Document Template (PF-64) Purpose: Reusable wizard configuration that defines steps, validation, and flow for module wizards. Storage: pf_wizard_templates table Scope: Organization-wide (custom) or system-wide (starter templates). Example:

“Standard Employee Onboarding” wizard template
“Resident Admission” wizard template
“Payroll Run” wizard template

Use When:

Organizations need to customize wizard flows
Creating standardized business processes
Sharing wizard patterns across sites

See: PF-41 Spec

Template Quick Reference

Template Type	Purpose	Storage	Use Case
Workflow Template	Automation patterns	`fw_workflow_templates`	Reusable automations
Document Template	Printable PDFs	`pf_document_templates`	Policies, letters, reports
Form Template	Clonable forms	`fw_forms` (is_template)	Reusable form structures
Wizard Template	Business wizards	`pf_wizard_templates`	Onboarding, payroll
Spec Template	Documentation	`specs/_templates/`	Writing specifications

Form Submission PDF Export

Also called: Submission PDF, form-to-PDF, submission export
NOT the same as: Document Template (PF-64), Signed PDF (FW-33) Purpose: Convert a form submission’s field data into a downloadable PDF document, optionally using organization letterhead and document template formatting. Implementation:

Hook: useFormSubmissionPdf from @/platform/forms
Template hook: useGenerateTemplatedPdf from @/platform/templates
Signed hook: useSignedPdfGeneration from @/cores/fw/hooks (FW-33, for forms with signature fields)

Scope: Any form submission can be exported as a PDF. Example:

Export an incident report submission as a branded PDF with letterhead
Download a completed intake form as a PDF for filing
Generate a signed consent form PDF with captured signatures

Use When:

Users need a printable version of a form submission
Submissions need to be shared as PDFs externally
Compliance requires PDF records of form data

See: Template Selection Guide

Letterhead (PF-64)

Also called: Organization letterhead, branding template
NOT the same as: Document Template (defines document structure) Purpose: Organization-specific header and footer configuration (logo, name, address, confidentiality notice) applied to PDF documents. Storage: pf_letterheads table Example:

“Formal Letterhead” with logo, address, and confidentiality footer
“Internal Memo” with minimal branding
“Confidential” with watermark

See: PF-64 Spec

Custom Field Definition (PF-16)

Also called: Custom field, entity extension, org-specific field
NOT the same as: Form Field, Object Field, Field Configuration Purpose: Define metadata schema for extending existing entities with organization-specific data. Storage: Definitions in pf_custom_field_definitions, values in custom_fields JSONB column on entity tables. Scope: Organization-wide, applies to all records of the target entity. Example:

Adding badge_number to hr_employees
Adding external_case_id to rh_residents
Adding retention_days to fw_forms

See: Custom Fields Use Case Guide

Form Field (FW-01)

Also called: Field, form input, form element
NOT the same as: Custom Field Definition, Object Field Purpose: Define a field within a form for data capture. Storage: fw_form_fields table. Scope: Form-specific, applies to one form only. Example:

“First Name” field in an intake form
“Incident Date” field in an incident report
“Rating” field in a satisfaction survey

See: Forms Use Case Guide

Entity Field Configuration (PF-17)

Also called: Field config, field visibility, field rules
NOT the same as: Custom Field Definition (PF-16 defines fields, PF-17 configures their behavior) Purpose: Control visibility, required status, and ordering of fields on existing entities. Storage: pf_entity_field_configs table. Scope: Organization + Entity + Context (e.g., role-based visibility). Example:

Hide salary from non-admin users
Make department_id required for managers
Reorder fields in employee profile

See: Field Configuration Use Case Guide

Object Field (PF-24)

Also called: Custom object field, object attribute
NOT the same as: Custom Field Definition (though they share pf_custom_field_definitions) Purpose: Define fields for a custom object type. Storage: pf_custom_object_fields (links to pf_custom_field_definitions). Scope: Custom object-specific. Example:

license_number field on “Clinical Licenses” custom object
vehicle_vin field on “Fleet Vehicles” custom object

See: Custom Objects Use Case Guide

Lookup Field (FW-15)

Also called: Table lookup, dynamic dropdown, referenced field
NOT the same as: Picklist (static), Form Options (form-specific) Purpose: Form field that pulls options dynamically from a database table. Storage: fw_form_fields.settings JSONB with lookup configuration. Scope: Real-time from database, respects RLS. Example:

Department dropdown from hr_departments
Employee selector from hr_employees
Site selector from pf_sites

See: Forms Use Case Guide

Data Object (PF-23)

Also called: Object, entity, table metadata
NOT the same as: Custom Object (PF-24 creates new objects, PF-23 provides metadata view) Purpose: Metadata representation of any entity (core or custom) for browsing and discovery. Storage: pf_object_metadata table. Scope: Organization-wide view of all objects. Example:

hr_employees as a data object in the Object Browser
rh_residents as a data object
Custom objects also appear as data objects

See: Data Manager Use Case Guide

Custom Object (PF-24)

Also called: User-defined object, custom entity, org-specific object
NOT the same as: Data Object (metadata view), Form (data capture interface) Purpose: Create new entity types beyond core Encore Health OS objects. Storage:

Definitions: pf_custom_objects
Fields: pf_custom_object_fields
Records: pf_custom_object_records

Scope: Organization-specific. Example:

“Clinical Licenses” to track staff certifications
“Training Classes” to track training sessions
“Fleet Vehicles” to track company vehicles

See: Custom Objects Use Case Guide

Form (FW-01)

Also called: Data capture form, submission form, workflow form
NOT the same as: Custom Object (entity type), Data Object (metadata) Purpose: Data capture interface for one-time submissions, often with workflow. Storage:

Definitions: fw_forms
Fields: fw_form_fields
Submissions: fw_form_submissions

Scope: Organization-specific. Example:

Resident intake form
Incident report form
Employee satisfaction survey

See: Forms Use Case Guide

Picklist (PF-15)

Also called: Dropdown values, reusable options, org-specific values
NOT the same as: Form Options (form-specific), Lookups (table-based) Purpose: Organization-scoped dropdown values reusable across forms and entities. Storage:

Lists: pf_picklists
Items: pf_picklist_items

Scope: Organization-wide, reusable. Example:

Employment status: Full-time, Part-time, Contractor
Priority levels: Low, Medium, High, Critical
Incident types: Fall, Medication Error, Behavioral

See: Picklists Use Case Guide

Form Options (FW-01)

Also called: Static options, inline options, form-specific values
NOT the same as: Picklist (reusable), Lookups (table-based) Purpose: Static dropdown options specific to one form field. Storage: fw_form_fields.options JSONB. Scope: Form-specific, not reusable. Example:

Yes/No for a specific question
Satisfaction ratings 1-5 for this survey only
One-off categories not used elsewhere

See: Forms Use Case Guide

Lookup Options (FW-15)

Also called: Table lookup, dynamic options, referenced values
NOT the same as: Picklist (static, org-managed), Form Options (form-specific) Purpose: Dynamic dropdown options pulled from database tables in real-time. Storage: Configuration in fw_form_fields.settings JSONB. Scope: Database-level, respects RLS, auto-updates. Example:

Departments from hr_departments
Employees from hr_employees
Sites from pf_sites

See: Forms Use Case Guide

Quick Reference Table

Term	System	Purpose	Storage	Reusable?
Custom Field Definition	PF-16	Extend existing entity	`custom_fields` JSONB	✅ Org-wide
Form Field	FW-01	Form data capture	`fw_form_fields`	❌ Form-specific
Field Configuration	PF-17	Control field behavior	`pf_entity_field_configs`	✅ Org-wide
Object Field	PF-24	Custom object structure	`pf_custom_object_fields`	❌ Object-specific
Lookup Field	FW-15	Dynamic form dropdown	`fw_form_fields.settings`	✅ Any form
Data Object	PF-23	Object metadata view	`pf_object_metadata`	N/A (metadata)
Custom Object	PF-24	New entity type	`pf_custom_objects`	✅ Org-wide
Form	FW-01	Data capture interface	`fw_forms`	✅ Org-wide
Picklist	PF-15	Reusable dropdown	`pf_picklists`	✅ Org-wide
Form Options	FW-01	Static form dropdown	`fw_form_fields.options`	❌ Form-specific
Lookup Options	FW-15	Dynamic table dropdown	`fw_form_fields.settings`	✅ Any form

Common Confusion Pairs

Custom Fields vs Form Fields

Custom Fields: Add metadata to existing entities (employees, residents)
Form Fields: Define structure of forms for data capture

Custom Objects vs Forms

Custom Objects: Create new entity types with CRUD operations
Forms: Create data capture interfaces with submissions

Picklists vs Lookups

Picklists: Static values managed in Settings, org-specific
Lookups: Dynamic values from database tables, auto-updates

Data Objects vs Custom Objects

Data Objects: Metadata view of any entity (browse/discover)
Custom Objects: New entity types created by organization

Field Configuration vs Custom Fields

Field Configuration: Control visibility/behavior of existing fields
Custom Fields: Add new fields to entities

Form Wizard vs Module Wizard

Form Wizard (FW-31): Multi-step data capture using forms, data goes to fw_form_submissions
Module Wizard (PF-41): Business process guidance with custom components, data goes to module-specific tables

Workflow Template vs Document Template

Workflow Template (FW-28): Reusable automation patterns for workflow builder
Document Template (PF-64): Structure for printable PDF documents with letterhead

Form Template vs Document Template

Form Template (FW-01): Clonable form structure for data capture
Document Template (PF-64): Printable document structure for policies, letters, reports

Form vs Document Template (Most Common Confusion)

Form (FW-01): Collects data from users → stored in fw_form_submissions
Document Template (PF-64): Formats data for printable PDF → stored in pf_document_templates
Connection: Form submissions can be exported as PDFs using PF-64 letterheads via useFormSubmissionPdf
Forms and Document Templates are complementary — forms capture, templates present

Wizard Template vs Spec Template

Wizard Template (PF-41): Database-stored wizard configuration for business processes
Spec Template: Markdown files in specs/_templates/ for writing documentation

Decision Trees

”Which wizard system should I use?"

I need a multi-step guided experience:
│
├─ Is it primarily for data capture (forms)?
│   └─ YES → Use Form Wizard (FW-31)
│       └─ Enable wizard mode on a multi-page form
│
└─ Is it for a business process (onboarding, payroll)?
    └─ YES → Use Module Wizard (PF-41)
        └─ Create wizard template with custom step components

"Which template type should I use?”

I need to create a template:
│
├─ For automating workflows?
│   └─ Use Workflow Template (FW-28)
│
├─ For generating printable documents (PDFs)?
│   └─ Use Document Template (PF-64)
│
├─ For creating reusable form structures?
│   └─ Use Form Template (FW-01)
│
├─ For business process wizards?
│   └─ Use Wizard Template (PF-41)
│
└─ For writing specification documents?
    └─ Use Spec Template (specs/_templates/)

PF/FW Documentation Review - Detailed analysis of terminology overlap
Forms/Templates/UX Review - Forms vs Templates analysis and recommendations
Template Selection Guide - Decision guide for template types
Clarity Analysis (Condensed) - Feature comparison
Use Case Guides - Integration patterns
Template Index - Spec template reference

Last Updated: 2026-02-05

Architecture

Development

Database

Testing

Migration

Operations

Governance & Security

Platform Internals

Documentation Index

​Wizard-Related Terms

​Form Wizard (FW-31)

​Module Wizard (PF-41)

​Wizard vs Form Quick Reference

​Template-Related Terms

​Workflow Template (FW-28)

​Document Template (PF-64)

​Form Template (FW-01)

​Spec Template (Developer)

​Wizard Template (PF-41)

​Template Quick Reference

​Document & PDF-Related Terms

​Form Submission PDF Export

​Document Template (PF-64) — see Template-Related Terms above

​Letterhead (PF-64)

​Field-Related Terms

​Custom Field Definition (PF-16)

​Form Field (FW-01)

​Entity Field Configuration (PF-17)

​Object Field (PF-24)

​Lookup Field (FW-15)

​Object-Related Terms

​Data Object (PF-23)

​Custom Object (PF-24)

​Form (FW-01)

​Option-Related Terms

​Picklist (PF-15)

​Form Options (FW-01)

​Lookup Options (FW-15)

​Quick Reference Table

​Common Confusion Pairs

​Custom Fields vs Form Fields

​Custom Objects vs Forms

​Picklists vs Lookups

​Data Objects vs Custom Objects

​Field Configuration vs Custom Fields

​Form Wizard vs Module Wizard

​Workflow Template vs Document Template

​Form Template vs Document Template

​Form vs Document Template (Most Common Confusion)

​Wizard Template vs Spec Template

​Decision Trees

​”Which wizard system should I use?"

​"Which template type should I use?”

​Related Documentation

Wizard-Related Terms

Form Wizard (FW-31)

Module Wizard (PF-41)

Wizard vs Form Quick Reference

Template-Related Terms

Workflow Template (FW-28)

Document Template (PF-64)

Form Template (FW-01)

Spec Template (Developer)

Wizard Template (PF-41)

Template Quick Reference

Document & PDF-Related Terms

Form Submission PDF Export

Document Template (PF-64) — see Template-Related Terms above

Letterhead (PF-64)

Field-Related Terms

Custom Field Definition (PF-16)

Form Field (FW-01)

Entity Field Configuration (PF-17)

Object Field (PF-24)

Lookup Field (FW-15)

Object-Related Terms

Data Object (PF-23)

Custom Object (PF-24)

Form (FW-01)

Option-Related Terms

Picklist (PF-15)

Form Options (FW-01)

Lookup Options (FW-15)

Quick Reference Table

Common Confusion Pairs

Custom Fields vs Form Fields

Custom Objects vs Forms

Picklists vs Lookups

Data Objects vs Custom Objects

Field Configuration vs Custom Fields

Form Wizard vs Module Wizard

Workflow Template vs Document Template

Form Template vs Document Template

Form vs Document Template (Most Common Confusion)

Wizard Template vs Spec Template

Decision Trees

”Which wizard system should I use?"

"Which template type should I use?”

Related Documentation