Portal Community

Step 1 — Schema Validation

Extract the JSON schema from the SQL file and run it through parseSchema(). This catches structural errors before the form reaches the database:

// Quick validation script — run in a Node.js REPL or test file
import { parseSchema } from '@atlas-forms/schema-js';
import { readFileSync } from 'fs';

const sql = readFileSync('Atlas_Forms_13008_GuardRail_IpAllowlist_Edit.data.sql', 'utf-8');

// Extract the JSON string between the N' and ' markers
const match = sql.match(/N'(\{[\s\S]+\})'\s*\)/);
if (!match) throw new Error('Could not extract SchemaJson from SQL file');

const rawJson = JSON.parse(match[1].replace(/''/g, "'"));

// parseSchema throws if the schema is invalid
const schema = parseSchema(rawJson);
console.log('Schema is valid. Controls:', schema.controls.length);

Step 2 — ID Uniqueness Check

// Verify the FormID is not already used
// Run against a refreshed dev database before committing

SELECT COUNT(*) AS [Count]
FROM   [dbo].[Atlas_Forms]
WHERE  [FormID] = 13008;
-- Expected: 0 (the ID must not exist yet)

Step 3 — Binding Path Verification

For each { source: "$json" } binding, verify the path exists in the API response schema for this entity. For { source: "$context" } bindings, verify the path is available in the workflow context at the time this form is presented:

// Check each binding in the generated schema
schema.controls
  .filter(c => c.binding)
  .forEach(c => {
    console.log(`${c.id}: ${c.binding.source}.${c.binding.path}`);
  });

// Output:
// ruleName:   $json.ruleName
// ipRange:    $json.ipRange
// action:     $json.action
// expiryDate: $json.expiryDate
// notes:      $json.notes

// Verify against the API response DTO:
interface IpAllowlistRuleDto {
  ruleName:   string;    // ✓
  ipRange:    string;    // ✓
  action:     string;    // ✓
  expiryDate: string;    // ✓ (ISO 8601)
  notes?:     string;    // ✓
}

Step 4 — Action Configuration Check

// Verify action endpoints exist in the backend
// The AI derives endpoint paths from the group pattern — confirm they are correct

schema.actions.forEach(action => {
  if (action.type === 'submit') {
    console.log(`Submit endpoint: ${action.config.endpoint}`);
  }
  if (action.type === 'navigate') {
    console.log(`Navigate to: ${action.config.target}`);
  }
});

// Output:
// Submit endpoint: /api/guardrails/ip-allowlist/save
// Navigate to: GuardRail_List

// Manual check:
// - GET/POST /api/guardrails/ip-allowlist/save exists in the backend
// - GuardRail_List resolves to FormID 13000 in the router

Full Pre-Deploy Checklist

CheckMethod
Schema parses without errorsRun parseSchema() on extracted JSON
FormID is unique in the databaseSQL SELECT COUNT(*) = 0
FormID is within the group's rangeVerify 13000 ≤ 13008 ≤ 13099
FormCode follows the group naming patternCompare to peer FormCodes
All $json binding paths match the API DTOCross-reference with backend DTO/schema
All $context binding paths are available at runtimeCheck workflow context documentation
Action endpoint URLs are implemented in the backendCheck with backend team
Navigation targets resolve to existing FormIDsVerify FormCode in Atlas_Forms
IDENTITY_INSERT ON/OFF present in SQL fileOpen file, verify visually
IF NOT EXISTS guard present and keyed on correct FormIDOpen file, verify visually
File added to the group's deploy scriptOpen Deploy script, verify :r line
Screenshots placed (if any listed in readme.txt)Check readme.txt
Visual Review in Atlas Forms Studio After deploying to a dev database, open the form in Atlas Forms Studio using Form ID lookup. Studio renders the form in design mode, letting you verify layout, label text, control types, and section structure visually before promoting to staging.