Skip to main content

Versioning Overview

Updated

Versioning, also known as SmartVersioning, enables the creation of concurrent versions of applications and forms that share a single set of underlying custom fields. Versioning begins with a core fieldset that contains all fields across all application and form versions, even fields that are no longer used/deprecated. Each version captures a snapshot of the underlying fieldset at a specific point in time, allowing multiple versions of the same set of fields to exist in a single location.

When a new version is created, Versioning captures a snapshot of the current fieldset, which becomes the foundation for the new version. This enables system administrators to test and use a new version before deploying it, without altering previous versions or requiring a separate test-to-production environment.

Who: System administrators

When to Use Versioning

Use Versioning when:

  • An application or form needs to change without affecting previously submitted records.
  • A progress report or form needs to change without affecting previously submitted records.

↑ Back to top

Key Concepts

Core Fieldset

The core fieldset is the complete set of fields available across all applications and forms. It encompasses all fields across all application and form versions. The core fieldset should include all fields including ones that are no longer used. Fields should not be deleted if they are not used going forward, but should always remain in the core fieldset. The fields in the core fieldset are used for all list views/reports and searches. New versions are built from the baseline, and new fields should be added to the baseline first so they become available to all versions when the next snapshot is taken.

⚠ WARNING  Always verify which version is active before deleting fields. The active version is shown in the Version combo box in the upper right corner of the Custom Fields page.
⚠ WARNING  Deleting fields from the core fieldset removes those fields from all associated applications and forms. Subsequent snapshots will not include the deleted fields, and previously stored values for those fields will no longer be accessible.

↑ Back to top

Snapshot

A snapshot is a copy of the baseline captured at a specific point in time. Taking a snapshot establishes the baseline for a version. A snapshot does not activate a version; the version must be explicitly activated before it applies to new submissions.

↑ Back to top

Baseline

A baseline, or baseline version, is the version created by taking a snapshot of the core fieldset before any other versions exist. Existing UTA/module records are batch updated to the baseline version, which is then made the active version.

↑ Back to top

Version

A version is a named instance of a fieldset configuration for an application or form. It is a subset of fields from the core fieldset. Versions can exist concurrently. The active version determines which fields are displayed to users for new submissions. Previous versions remain accessible for historical records.

↑ Back to top

How Versioning Works

The general process for versioning follows this order:

  1. Create a baseline version by taking a snapshot of the core fieldset.
  2. Batch update existing UTA/module records to the baseline version.
  3. Make the baseline version the active version.

↑ Back to top

Benefits of Versioning

  • Reduces the effort required to manage changes to forms and applications.
  • Enables easy creation, modification, and testing of forms before deployment.
  • Preserves the values and appearance of previous forms so System administrators can access earlier versions in their original format.
NOTE  Configuring Versioning requires system administrator access.

↑ Back to top

Resources

For more information about Versioning, see:

↑ Back to top

Helpful Links