Field-level overrides

The generated mapping is deterministic and full-field, so the common case needs no manual work. Field-level overrides are for the exceptions — the one field in one operation that needs to behave differently from the default. You author them in the UI; there is no mediation script to write.

A field override is the most specific tier of the conversion-option hierarchy:

System default  →  per-Service  →  per-Operation  →  per-Field
                                                       ↑ overrides here

---

What you can override per field

Per-field overrides are exposed as chips on the leaf fields of an operation's mapping. They cover the leaf-level conversion options:

• Date / time (format, custom pattern, timezone, local timezone — all on one chip)
• Numeric handling
• Boolean handling
• Null / empty handling
• Array collapse
• Whitespace handling
• Binary encoding (and the data-URL MIME type)
• Duration
• Required handling
• Field-name casing
• xsi:type discriminator (and the discriminator field name)
• Integer range bounds (OpenAPI spec emission only)
• Validation regexes — a per-field pattern enforced under the active validation mode; emitted into the OpenAPI schema as a pattern.

What cannot be set per field

The body-level options act on the whole response body, so there is no single leaf to attach them to. Set these at the system or operation tier instead:

• Response envelope wrap
• Error / fault shape
• JSON field ordering
• SOAP header propagation
• Upstream failure status (a response-status decision)
• Request / response validation mode (set per service)

See the conversion options reference for each option's available tiers.

---

Request vs response (direction)

For most options a per-field override is a single response-side value. Two options are bidirectional — they carry separate request-side and response-side overrides per field, and both are consulted at runtime:

• Boolean handling
• Null / empty handling

Per-field validation regexes are likewise direction-aware (separate request and response patterns). If you need to split a single-value option by direction for a specific leaf, set the distinction at the operation tier rather than the field tier.

---

How to author an override

1. Open Services → your service → Mapping and select the operation.
2. The request and response contract trees render with the auto-generated mapping. Locate the leaf field.
3. Open the field's override chip and set the option mode (e.g. switch one date field to epoch-millis, or one string field to snake_case).
4. Save. Editing a mapping creates a new immutable revision — the active version is not mutated in place.
5. Verify with the SOAP application test (or REST test) before activating; the test uses the exact runtime conversion path. See Publish & version a service.

Because an override creates a new revision, you can always roll back to a known-good version.

---

What an override affects

A field override changes both:

• the runtime conversion for that field, and
• the generated OpenAPI v3 schema for that field (a casing change renames the property; a validation regex emits a pattern; an integer-range-bounds change emits/omits minimum/maximum).

So the published contract always matches the runtime behavior.

---

Next reads

• Conversion options reference
• Validation modes — the regex enforcement field overrides plug into.
• Generate & review the OpenAPI

---

All Specaria SOAP to REST docs