Skip to main content

Extensions And Schema

This page explains how admins and integrators define schema-driven behavior in SVRunner. Use it when designing custom metadata structures, validation logic, and dashboard-facing extension behavior.

When To Use An Extension​

Use an extension when you need:

  • structured custom fields on assets or asset blocks
  • validation rules beyond simple naming or tagging
  • dashboard filters tied to schema data
  • file validation behavior
  • project-specific UI behavior for custom content types

Do not use an extension when a simple tag or naming convention is enough.

Extension Structure​

The existing extension model uses a schema-driven object structure.

The earlier internal docs describe a pattern where the top-level extension property identifies the custom data object and that property contains the custom fields.

Common supported schema building blocks include:

  • object
  • string
  • number
  • boolean
  • array
  • enum
  • $ref
  • default

UI-Oriented Schema Fields​

The existing extension docs describe several UI conventions used by the product, including:

  • ui:widget
  • ui:hidden
  • ui:sequenceFilterable
  • ui:fieldDescription
  • ui:thumbnail
  • ui:labelPrefix

These fields are important because the schema drives not just storage, but also the operator experience.

Extension Schema Editor Stub screenshot: extension schema editor with one realistic schema example. Save final image at packages/docs/screenshots/configuration-extension-schema-editor.png.

Conditional Logic​

Schema composition can be used to create conditional UI behavior.

The previous extension notes show patterns using:

  • allOf
  • if
  • then

This is useful when certain fields should only appear for specific programming modes or content types.

Rules, Filters, And Validation​

In the current UI, extension configuration includes:

  • schema editing
  • rules
  • filters
  • file validation
  • permissions

That makes extensions a combined configuration surface for:

  • content structure
  • operator UI behavior
  • automation-facing filtering
  • upload constraints

File Validation​

Use file validation when extension-backed assets must meet specific media constraints or file expectations.

This is especially valuable when operators are uploading content that must conform to strict technical requirements.

Extension Resulting Asset Form Stub screenshot: resulting operator-facing asset form paired with the schema example. Save final image at packages/docs/screenshots/configuration-extension-asset-form.png.

Practical Guidance​

Prefer Clear Schemas​

Good extension schemas are:

  • readable
  • documented
  • consistent across content types
  • limited to the complexity the site actually needs

Test The Full Workflow​

When changing an extension, test:

  • creating a new asset or asset block
  • editing an existing one
  • validating files if relevant
  • filtering content in the UI
  • any dashboard filter behavior driven by the extension

Keep The Operator View In Mind​

An extension is successful only if operators can use it reliably. If the schema is too complex to understand during normal scheduling work, simplify it.