Question on best practises of versioning/releasing Adaptive forms

If you have medium to highly complex Adaptive Forms (particularly those with extensive JavaScript rules) and the forms do not require frequent authoring changes (such as adding or removing fields), it is recommended to maintain them in a Git/Bitbucket repository. This approach provides better version control, code review, collaboration, and deployment consistency.

On the other hand, if you have simple Adaptive Forms that require frequent authoring or content updates directly in the production environment, leveraging AEM's out-of-the-box (OOTB) versioning is a more suitable option. It allows authors to make changes efficiently while retaining version history for rollback and auditing.

Hi ​@kolluax,

Thanks for raising this — it's an important question to get right before scaling up delivery across multiple teams. Here's our recommended approach.

**Content vs. Code: use the right tool for each**
Adaptive Forms are content (JCR nodes), not code, so they shouldn't live in Git. Git remains the right home for custom components, dialogs, client libraries, templates, and pipeline configuration. The authored forms themselves — built by business authors in the editor — are best managed natively in AEM and promoted through packaging/pipeline tools rather than forced into a Git workflow.

**Is on-demand versioning enough on its own?**
Not by itself. Form-level versioning is great for tracking history on a single form and rolling it back if needed, but it doesn't give you:
- Coordinated promotion of many forms across Dev → Stage → Production
- Multi-team governance (ownership, naming, permissions)
- An audit trail across an entire release
- Approval gates before something reaches Production
- Visibility into shared dependencies (fragments, themes, rule sets) used across forms

**Recommended process for scaling across teams**
1. **Environment promotion**, not just versioning – use packaging/Content Transfer Tool (or Cloud Manager content pipelines on AEM as a Cloud Service) to move forms between environments as a repeatable, auditable release unit.
2. **Governance structure** – enforce folder/naming conventions per team, and scope permissions (ACLs) so each team can only edit its own forms. Keep shared assets (themes, fragments, rule sets, templates) in a centralized area with tighter write access, since these are the highest-risk shared dependencies.
3. **Review/approval workflow** before Production – pair versioning with an actual sign-off step, especially for changes touching shared fragments or rule logic.
4. **Reuse via Live Copy / Multi-Site Manager** where teams are producing form variants, to reduce duplication and keep consistency.
5. **Keep code and content in sync** – custom components/templates go through Git + CI/CD; forms are promoted through AEM's own mechanisms. Add a compatibility check so a form doesn't get promoted ahead of the component version it depends on.
6. **Backups separate from versioning** – version history isn't a backup strategy. Plan for environment-level backups or scheduled package exports independent of form versioning.

If you're on AEM Forms as a Cloud Service, it may also be worth checking eligibility for the newer Core Components versioning/commenting/annotation feature, which adds collaborative review directly on the form (currently requested via aem-forms-ea@adobe.com).

Thanks
Pranay