Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.encoreos.io/llms.txt

Use this file to discover all available pages before exploring further.

Feature ID: FW-60
Status: 📝 Planned
Spec: FW-60-form-prefill-smart-defaults.md
Plan: FW-60-form-prefill-smart-defaults-PLAN.md
Last Updated: 2026-03-22 (submission shape / carry-forward contract)

​
Overview

FW-60 adds configurable prefill rules and smart defaults to the forms stack. It consumes platform auth/session context and reads domain data through normal Supabase queries (RLS-enforced). It does not add new cross-core foreign keys or direct core-to-core imports in application code: entity targets for entity_record are resolved by table name + ID from URL/context, with isolation enforced by RLS on those tables.

​
Integration Points (from Spec)

DependencyPatternPurpose
FW-01 (Form Builder)Intra-coreForm and field definitions; rule configuration UI
FW-02 (Form Submissions)Intra-corePersist prefilled_fields on submit
FW-05 (Multi-Page Forms)Intra-coreCarry-forward across pages/drafts
FW-15 (Field Lookups)Intra-core / PlatformRelated patterns for data-backed fields; optional shared validation
FW-19 (Data Query)Intra-coreConceptual alignment: whitelisted tables for workflow queries; prefill uses same allowlist discipline for entity_record
PF-02 (RBAC)PlatformPermissions for configuring rules vs. using forms
PF-08 (Platform Forms)Platform Layer@/platform/forms renderer integration for prefill application
PF-01 (Orgs & Sites)PlatformContext defaults (site_id, org scope)
Domain tables (RH, HR, CL, etc.)Data (RLS)entity_record sources — no direct core imports; queries only

​
Platform Layer Usage

  • Consumes: useCurrentUser() / session context for context prefill; Supabase client for entity and previous-submission reads.
  • Provides: Prefill evaluation used by form renderer and builder preview; stored rules in fw_form_prefill_rules.
  • Data flow: Resolver loads rules for form_id → evaluates by priority → merges into field default values → on submit, persists provenance in fw_form_submissions.prefilled_fields.

​
Submission shape (carry-forward)

Current platform insert (useFormSubmission): persists submission_data JSONB (field keys → values) and does not set custom_fields by default. Carry-forward “same entity” queries should filter prior fw_form_submissions rows with submission_data->><entity_param> = <resolved_uuid>. For that to work across renewals, forms should include a hidden field whose field_key matches entity_param, or (Phase 2) the submit path must merge entity context into custom_fields under a reserved key — see spec § “Carry-forward and entity context (data contract)”.

​
Security and Tenant Isolation

  • All rules are scoped by organization_id; RLS on fw_form_prefill_rules uses fw_has_org_access.
  • Entity record fetches run as the current user; RLS on source tables determines visibility. No service-role bypass for end-user form load. Batched entity_record reads (grouped per allowlisted table) must use that same user session for every query in the batch so results match RLS and what the user would see when opening the source record directly.
  • Prefill rule configuration JSONB holds no PHI — only table/column names, parameter keys, and priorities.

​
Events and APIs

  • Events: No new domain events required for MVP. Optional future: extend fw_form_submitted payload metadata if product needs downstream prefill audit in event consumers (defer unless required).
  • APIs: No new public HTTP API; client-side resolution + existing submission APIs.