Question on best practises of versioning/releasing Adaptive forms | Community
Skip to main content
K
kolluax
Level 4
July 14, 2026
Solved

Question on best practises of versioning/releasing Adaptive forms

  • July 14, 2026
  • 3 replies
  • 56 views

We are about to scale of adaptive forms delivery and expecting a lot of forms ready to be deployed into Production. My questions are around how to source control these forms, i was thinking since these are content we should not be keeping them in GIT (?).

 

I know versioning is offered as a on demand feature, would that be enough ? we will have multiple teams delivering different forms, wanted to build a robust/effective process. Any recommendations or advises will be of great help.

    Best answer by Pranay_M

    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

    3 replies

    D
    davidwarner
    Level 2
    July 15, 2026

    For scaling Adaptive Forms across teams, Git-based source control is usually the better option. Built-in versioning helps, but Git provides better governance, history, and deployment control. A simple CI/CD process with clear ownership will help keep things manageable as forms grow.

    K
    KaramjeetKa
    Level 2
    July 17, 2026

    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.

    P
    Adobe Employee
    Pranay_MAdobe EmployeeAccepted solution
    Adobe Employee
    July 20, 2026

    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

    Terms & ConditionsAccessibility statement

    Loading footer...