API documentation: https://resources.geocom.ch/VertiGIS/VertiGIS_Attribute_Form/1.5.0/interfaces/common_SchemaInterfaces.AttributeFormSchema.html
What Are Schemas?
A schema is the blueprint for your attribute form. It defines:
•Which fields to show (and in what order)
•How fields are grouped and organized
•The form's title and description
•Field behavior (required, read-only, visible, etc.)
One Schema Per Layer
Each layer in your map needs its own schema. The schema name must match the layer name exactly. How you identify layers depends on your map service type:
Feature Service (client-side rendering):
•Layer name comes from the service definition
•Multiple map layers can share the same underlying source
•Example: Subtype group layers can reference one schema
Map Image Service (server-side rendering):
•Layer name matches what appears in the layers list
•Each subtype sublayer needs its own separate schema
•Example: "Water Valves - Gate" and "Water Valves - Butterfly" need individual schemas
Show or Hide Fields
Schemas are selective - you don't need to include every field.
•Fields in schema: Visible and editable in the form
•Fields not in schema: Hidden and won't be modified
Schema Properties
Form-Level Settings
Setting |
Type |
Default |
Description |
Examples |
|---|---|---|---|---|
title* |
string |
- |
Main heading displayed at the top of the form. |
"Edit Water Valve" |
description |
string (Markdown + Arcade) |
undefined |
Text displayed below the title. Supports Markdown formatting and Arcade expressions. |
"Last updated: {$feature.edit_date}" |
fieldTitleLocation |
"above" | "beside" |
"above" |
Controls where field labels appear relative to inputs. |
"above" |
readonly |
boolean | Arcade expression |
false |
Makes the entire form read-only when true or when the expression evaluates to true. |
$feature.status == "Approved" |
Fields marked with * are required.
Organizational Structure:
•groups (mandatory): A list of field groups. Each group acts as a collapsible section containing related fields.
Group Properties
Groups organize fields into logical sections. Each group supports:
Property |
Type |
Default |
Description |
Examples |
|---|---|---|---|---|
title |
string |
undefined |
Group heading displayed above the fields. |
"Physical Properties" "Location Data" "Maintenance History" |
description |
string (Markdown + Arcade) |
undefined |
Text displayed below the group title. Supports Markdown and Arcade expressions. |
"Enter measurements taken during installation" |
fields* |
FormField[] |
- |
Array of field definitions contained within the group. |
[ { ...fieldDefinition } ] |
format |
"collapsible-section" |
"basic-section" |
"fieldset-section" |
"unstyled-section" |
collapsed |
boolean |
Arcade expression |
false |
Controls the group’s initial expanded/collapsed state. |
visible |
boolean |
Arcade expression |
true |
Determines whether the group is rendered. |
readonly |
boolean |
Arcade expression |
false |
Disables all fields within the group when true or when the expression evaluates to true. |
An inspection form could have:
1.Basic Info group (always open, always visible)
2.Damage Assessment group (only visible when condition != "Good")
3.Historical Data group (initially collapsed, read-only)
Sub-Level Schemas
Conditional Schema Switching
Sometimes you need completely different forms based on a field value - different asset types have different attributes.
•subLevelKey (optional | default = undefined): Specifies which field value determines schema selection
•subLevels (optional | default = undefined): A collection of alternative schemas, each triggered by different field values
oCan be nested: Define sub-levels within sub-levels for multi-level conditional forms
Example: A utility company has different asset types in one layer:
•Fire Hydrants (assetType = 1): Show fields for flow rate, barrel size, connection type
•Gate Valves (assetType = 2): Show fields for pressure rating, turns to close, actuator type
•Backflow Preventers (assetType = 3): Show fields for test date, certification number, assembly type
By using subLevelKey: "assetType" and defining three sub-level schemas, users see only relevant fields based on what they're editing.
