Atlas Forms
The 6-Step Generation Workflow
AI form generation follows a deterministic six-step sequence. Each step builds on the previous one, ensuring the generated form is consistent with the group before a single line of SQL is written.
Step 1 — Receive User Request
The user provides:
- The target Form Group ID (e.g.,
guard-rails) - A description of the new form's purpose (e.g., "A property form for editing IP allowlist rules")
- Optional: a list of specific fields required
// Example invocation
Generate a new form in the guard-rails group.
Purpose: Edit an IP allowlist rule (allow/block specific IP ranges).
Fields required:
- Rule name (text, required)
- IP range (text, required, CIDR format)
- Action (select: Allow / Block)
- Expiry date (date, optional)
- Notes (textarea, optional)
Step 2 — Read the Group Definition
The AI reads the group's FormGroupDefinition to obtain:
formGroupId,categoryId,ownerAppformIdRange— to constrain FormID selectionaiGenerationEnabled— abort if falsedefaultPrimaryUsage— pre-fill PrimaryUsage on the new form
Step 3 — Scan Existing SQL Files
The AI reads all .data.sql files in the group's folder. It extracts:
- All FormIDs already in use — to pick the next available one
- All FormCodes — to follow the naming pattern
- All SchemaJson values — to learn the group's control and section patterns
// Folder scanned
BizFirstFiV3DB/dbo/Data/AtlasForms/GuardRails/
GuardRails_Category.data.sql
Atlas_Forms_13000_GuardRail_List.data.sql
Atlas_Forms_13001_GuardRail_Edit.data.sql
Atlas_Forms_13002_GuardRail_View.data.sql
...
Atlas_Forms_13006_GuardRail_AccessControl_Edit.data.sql
Step 4 — Learn Patterns
From the scanned schemas the AI extracts:
- Section IDs and titles used by peer property forms
- Control types used for similar field purposes across the group
- Binding path patterns (
$json.fieldNamevs$context.pathName) - Action block configuration (Save action name, payload structure, navigation target)
- Validation rule patterns (required fields, common format validators)
Step 5 — Generate the Form Schema and Assign FormID
Using the patterns learned, the AI constructs:
- The
metadatablock: next FormID, FormCode, title - Sections matching peer forms
- Controls: one per field requirement, using the group's established control types
- Actions block: cloned from the group's property form template
- Validation rules: applied to each field per the user's requirements
Step 6 — Write the SQL File
The AI writes a .data.sql file containing the form INSERT with IF NOT EXISTS guard and IDENTITY_INSERT blocks. See SQL File Pattern for the exact format.
Workflow Summary
| Step | Input | Output |
|---|---|---|
| 1. User request | Group ID, purpose, field list | Generation task |
| 2. Read group | FormGroupDefinition | Range, ownerApp, AI flag |
| 3. Scan existing | All .data.sql files in folder | Used FormIDs, FormCodes, schemas |
| 4. Learn patterns | Extracted schemas | Naming, section, control, binding, action patterns |
| 5. Generate schema | Patterns + field requirements | Complete FormSchema JSON + next FormID |
| 6. Write SQL | FormSchema JSON + FormID | Atlas_Forms_{id}_{code}.data.sql |
The Generator Never Modifies Existing Forms
The AI generation pipeline is strictly additive — it only creates new files. It will never modify an existing
.data.sql file. Updates to existing forms must be done manually.