> ## 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.

# Form Prefill & Smart Defaults — Integration

> Feature ID: FW-60 Status: \U0001F4DD Planned -form-prefill-smart-defaults.md Plan: FW-60-form-prefill-smart-defaults-PLAN.md Last Updated: 2026-03-22 (submi…

**Feature ID:** FW-60\
**Status:** 📝 Planned\
**Spec:** [FW-60-form-prefill-smart-defaults.md](../../../specs/fw/archive/FW-60-form-prefill-smart-defaults.md)\
**Plan:** [FW-60-form-prefill-smart-defaults-PLAN.md](../../../specs/fw/archive/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)

| Dependency                       | Pattern               | Purpose                                                                                                                   |
| -------------------------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| FW-01 (Form Builder)             | Intra-core            | Form and field definitions; rule configuration UI                                                                         |
| FW-02 (Form Submissions)         | Intra-core            | Persist `prefilled_fields` on submit                                                                                      |
| FW-05 (Multi-Page Forms)         | Intra-core            | Carry-forward across pages/drafts                                                                                         |
| FW-15 (Field Lookups)            | Intra-core / Platform | Related patterns for data-backed fields; optional shared validation                                                       |
| FW-19 (Data Query)               | Intra-core            | Conceptual alignment: whitelisted tables for workflow queries; prefill uses same allowlist discipline for `entity_record` |
| PF-02 (RBAC)                     | Platform              | Permissions for configuring rules vs. using forms                                                                         |
| PF-08 (Platform Forms)           | Platform Layer        | `@/platform/forms` renderer integration for prefill application                                                           |
| PF-01 (Orgs & Sites)             | Platform              | Context 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.

***

## Related Docs

* [CROSS\_CORE\_INTEGRATIONS.md](./CROSS_CORE_INTEGRATIONS.md)
* [PLATFORM\_INTEGRATION\_LAYERS.md](./PLATFORM_INTEGRATION_LAYERS.md)
* [FW-02-form-submissions.md](../../../specs/fw/archive/FW-02-form-submissions.md)