Field Rules

What this does

Field rules control how individual fields behave on a Quik! form: which fields are required, which are read-only, which are hidden, which have specific formats, default values, character limits, or conditional logic.

Field Mapping (the previous guide) is about what data goes into fields. Field Rules is about how those fields behave once the form is in front of your user.

When to use this

Common scenarios:

Mark certain fields as required so users cannot submit until they fill them in.
Set a field to read-only when the value comes from your system and should not be edited.
Hide internal tracking fields the user does not need to see.
Apply a format mask to a phone number, date, or tax ID.
Make a field required only when another field has a specific value (conditional required).
Convert a free-text field into a drop-down with a fixed list of options.

If you only need to prefill values without changing field behavior, you do not need this guide. See Field Mapping.

Two places to set field rules

You can set field rules in two places. Both produce the same end result on the rendered form.

Approach	Where	Best for
Field Rules Manager (admin UI)	`https://qcc.quikforms.com/QFE/ManageFieldRules.aspx` in the Quik! Forms Enterprise Manager.	Persistent rules that apply to every form generation from your account. Business analysts can manage without writing code.
Run-time (in your API request)	In the body of your `execute/html` or `execute/pdf` call.	Rules that change based on workflow context, or rules that need to override account-level settings dynamically.

When both exist, run-time rules override account-level rules.

To turn off the Field Rules Manager entirely for a specific call (so only your run-time rules apply), set FieldAttributesManagerOff to true in your request. To test rules that are still in Test status without activating them, set FieldAttributesManagerTest to true.

What you can control

The same rule types are available in both the admin UI and at run-time. Some attributes are only configurable at run-time or only in the Manager. Where it differs, the table notes it.

Rule	What it does
Required	Marks the field with a red outline. Form will not submit until the field has a value.
Semi-Required	First submit attempt is blocked as a reminder. Second submit is accepted even if the field is still empty.
ReadOnly	User cannot edit the value. Useful for system-supplied data.
Visibility	Show, hide, or show-no-print the field. Different from `Hidden` (see below).
Hidden	Adds the field to the form as a hidden HTML input. Used for fields that should travel with submitted data but never appear to the user.
Default Value	Pre-populates the field with a value that the user can still edit.
Format	Display mask applied to the value. `#` for digits, `a` for letters, other characters literal. Example: `(###) ###-####`.
Mask	Displays typed characters as `*****`. Used for sensitive values like SSN.
MaxCharLength	Maximum characters the user can type. Does not limit prefilled values.
BackColor	Background color for the field. Hex code (e.g., `#FFFF00`).
Calc Override	When `true`, prevents Quik! from calculating the field automatically and uses your value instead. Used for calculated fields like `FullName`.
RegEx	Regular expression pattern the value must match.
RequiredByRefField + RequiredByRefFieldValues	Makes the field conditionally required. Only required when another named field has one of the listed values.
DropDownList	Converts a text field into a drop-down with a fixed list of options. Manager-only.
FieldType	Pre-determined field type: `month`, `week`, `time`, or `email`.
AttachFile + AttachTitle	Adds an attachment icon next to the field, with custom popup text.
AltDataButton	Adds an alternate data picker next to the field. See the Alt Data Buttons documentation for usage.
OptionalEsignField	Marks a signature field as optional during e-sign. DocuSign only.

How to set field rules at run-time

There are three ways to set field rules in your API request, each with a different scope.

By full field name

Use this when you want a rule to apply to one specific field on the form. Add the rule attributes directly to the entry for that field in FormFields.

{
  "QuikFormID": "12",
  "HostFormOnQuik": true,
  "FormFields": [
    {
      "FieldName": "1own.FName",
      "FieldValue": "John",
      "FieldRequired": 1,
      "FieldBackgroundColor": "#FFFFC5",
      "MaxCharLength": 50
    },
    {
      "FieldName": "1own.SSN",
      "FieldValue": "123451234",
      "FieldReadOnly": 1,
      "FieldMaskFlag": true,
      "FieldFormat": "###-##-####"
    }
  ]
}

By partial field name (bulk)

Use BulkFieldPropertiesByFieldName to apply the same rule to every field whose name contains the partial string. Common pattern: format every SSN field on the form the same way.

{
  "QuikFormID": "12",
  "BulkFieldPropertiesByFieldName": [
    {
      "FieldName": "SSN",
      "FieldRequired": 1,
      "FieldMaskFlag": true,
      "FieldFormat": "###-##-####",
      "MaxCharLength": 11
    },
    {
      "FieldName": "FName",
      "FieldRequired": 1,
      "FieldBackgroundColor": "#CCC"
    }
  ]
}

FieldName is matched as a substring. SSN will match 1own.SSN, 1ben.SSN, 2own.SSN, and any other field name containing SSN.

By role (bulk)

Use BulkFieldPropertiesByRole to apply rules to every field belonging to a role. Common pattern: hide all Owner 2 fields when only one owner is involved.

{
  "QuikFormID": "12",
  "BulkFieldPropertiesByRole": [
    {
      "RoleName": "1own",
      "FieldRequired": 1,
      "FieldBackgroundColor": "#FFFFC5"
    },
    {
      "RoleName": "2own",
      "FieldVisibility": 2,
      "FieldReadOnly": 1
    }
  ]
}

Leave RoleName blank to apply the rule to every field on the form regardless of role. Example: set every field read-only with one rule.

{
  "BulkFieldPropertiesByRole": [
    { "RoleName": "", "FieldReadOnly": 1 }
  ]
}

Common patterns

Make a field required only when another field has a specific value

A spouse name field that is required only when marital status is Married:

{
  "FormFields": [
    {
      "FieldName": "1spou.FName",
      "RequiredByField": "1own.MaritalStatus",
      "RequiredByFieldValues": "Married"
    }
  ]
}

If marital status is anything other than Married, the spouse field is optional.

Mask a sensitive value

Display SSN as ********* but submit the real value:

{
  "FormFields": [
    {
      "FieldName": "1own.SSN",
      "FieldValue": "123456789",
      "FieldMaskFlag": true,
      "FieldFormat": "###-##-####"
    }
  ]
}

Remove a built-in format

Some fields (SSN, phone) come with automatic formatting. To submit data that uses a different format (international phone, for example), override with an empty string:

{
  "FormFields": [
    {
      "FieldName": "1own.H.Phone",
      "FieldValue": "+11 1234 12345",
      "FieldFormat": ""
    }
  ]
}

Add an attachment uploader to a field

{
  "FormFields": [
    {
      "FieldName": "1own.GOV.IDType",
      "AttachFile": true,
      "AttachTitle": "Please upload a copy of your ID here"
    }
  ]
}

Hide a field entirely

To prevent the user from seeing or interacting with a field, set visibility to hidden (value 2):

{
  "FormFields": [
    {
      "FieldName": "1own.InternalNotes",
      "FieldVisibility": 2
    }
  ]
}

Targeting fields with the Field Rules Manager

The Manager UI offers the same four targeting options:

Full field name for a specific field (e.g., 1own.FName).
Base field name for all fields with that base across all roles (e.g., FName covers all first name fields).
Partial field name for all fields containing the string (e.g., Date covers any field with Date in the name).
Role name for all fields belonging to a role (e.g., own for all Owner fields, or 1own for Owner 1 fields specifically).

Rules saved in the Manager start in Test status. Test them on a form group with the Test Forms button. When you're confident, change the status to Active and save.

Pitfalls

Rules created in code override rules in the Manager. If you set a field as read-only in the Manager and then set it to editable in your run-time request, the field will be editable for that generation. Be deliberate about which layer owns which rules.
Checkbox and radio field rules use the field name without the QuikRadio<FormID> prefix. A checkbox shows up in the DOM as QuikRadio38002.1own.GOV.IDType. The Manager and your API requests should use 1own.GOV.IDType. The checkbox value (e.g., 2 for Passport) goes in the attribute value.
The Manager does not currently support editing existing rules. To change a rule, delete it and create a new one with the desired settings. Then save.
Avoid creating rules for Generic field names (names like txt1.1.10.2). Generic names can change in future form updates, which means your rule may end up applied to the wrong field or no field at all. Only set rules on fields defined in the Quik! Field Definition.
MaxCharLength does not limit prefilled values. It only limits what users can type. A 50-character MaxCharLength does not stop you from prefilling a 60-character value.
Drop-down values appear in reverse order from how they are entered. If you want Income, Balanced, Growth & Income displayed in that order, enter them as Growth & Income, Balanced, Income. To start with a blank value, lead the list with a comma.
Blank records in drop-downs are limited. The field defaults to the first value listed. To start with a blank, use the comma-leading trick noted above.

Continue with these articles to understand the related concepts and workflows:

Field Mapping — See how mapped values interact with form rules and conditional behavior.
Fields and Field Names — Review the field-name structure used across Quik! forms.
Launch a Form — Understand how rules are applied when a form is generated.
HTML vs PDF Execution — Learn how field behavior appears in interactive forms versus generated PDFs.

Field Mapping

Saving Forms