Skip to main content
P
prasanth_s
Level 2
May 7, 2026
Solved

Global component policies across sites

  • May 7, 2026
  • 3 replies
  • 61 views

Requesting solution/approach for using and maintaining global component policies across multiple sites. Current project using common components across sites and policies are maintained in below path

/conf/global/settings/wcm/policies/…button

The requirement is to use the same button component style policy for the project specific template placed under

/conf/myproject/settings/wcm/template/my-template/

Is there any way to map the common policies for site specific templates without duplicating and maintaining the same policy under project /conf so that we can see style policy icon in editor?

Cross conf reference is possible ?

 

Thanks in advance!

Best answer by chaudharynick

Hi ​@prasanth_s 

Yes, cross-conf reference is possible. You do not need to duplicate policies across your project folders.

AEM natively handles this through the Sling Configuration (Sling Conf) fallback mechanism. Because editable templates and policies use Context-Aware Configurations under the hood, AEM will automatically resolve global policies if they are mapped correctly.

Here is the approach to implement and maintain this.

How the Fallback Mechanism Works

When AEM looks for a policy (or any configuration) for a site that has cq:conf="/conf/myproject", it searches in a specific order:

  1. /conf/myproject

  2. /conf/global

  3. /apps

  4. /libs

If AEM does not find the mapped policy in /conf/myproject/settings/wcm/policies/..., it will automatically fall back and successfully retrieve it from /conf/global/settings/wcm/policies/....

Step-by-Step Approach

To map your common global policy to a site-specific template so the style icon appears in the editor, follow these steps via your codebase (CRXDE or your XML files):

1. Define the Global Policy Ensure your policy is stored in /conf/global.

  • Example Path: /conf/global/settings/wcm/policies/my-commons/components/button/global-btn-policy

2. Ensure No Local Overrides Make sure that the path /conf/myproject/settings/wcm/policies/my-commons/components/button/global-btn-policy does not exist. If it does, AEM will use it instead of the global one.

Important Caveats for Maintenance

  • Template Editor UI Behavior: If this is set up correctly via code, the paintbrush (Style) icon will show up in the page editor for authors. However, if an author goes into the Template Editor, opens the policy for that button, makes a change, and hits save, AEM may create a new localized node under /conf/myproject/.... This breaks the global inheritance for that specific tenant.

  • Codebase Enforcement: To maintain strict global governance, it is highly recommended to deploy these template policies configurations via your ui.content Git repository. This ensures that even if an author accidentally localizes a policy, your next deployment will align the environments back to the global setup.

  • Granular Permissions: If you want to strictly prevent authors from breaking this inheritance, consider restricting write access to the /conf/myproject/settings/wcm/policies path for template authors, forcing them to rely on the global configurations provided by the development team.

3 replies

G
Adobe Employee
goelsAdobe Employee
Adobe Employee
May 8, 2026

Hi ​@prasanth_s ,
 

“Is there any way to map common policies to site-specific templates without duplicating the same policy under project /conf?”
Answer: Try putting the policy in /conf/global and bind your project templates to it via the Template Editor. The template will reference the global policy; you don’t need a copy under /conf/myproject.

“Is a cross-conf reference possible?”
Answer: Cross‑/conf in the sense of “/conf/siteA reading directly from /conf/siteB” is not supported. The supported sharing mechanism is via the inheritance chain that includes /conf/global, /apps, and /libs.

P
prasanth_sAuthor
Level 2
May 8, 2026

Thanks ​@goels for the solution suggestion.

chaudharynick
chaudharynickAccepted solution
Level 4
May 8, 2026

Hi ​@prasanth_s 

Yes, cross-conf reference is possible. You do not need to duplicate policies across your project folders.

AEM natively handles this through the Sling Configuration (Sling Conf) fallback mechanism. Because editable templates and policies use Context-Aware Configurations under the hood, AEM will automatically resolve global policies if they are mapped correctly.

Here is the approach to implement and maintain this.

How the Fallback Mechanism Works

When AEM looks for a policy (or any configuration) for a site that has cq:conf="/conf/myproject", it searches in a specific order:

  1. /conf/myproject

  2. /conf/global

  3. /apps

  4. /libs

If AEM does not find the mapped policy in /conf/myproject/settings/wcm/policies/..., it will automatically fall back and successfully retrieve it from /conf/global/settings/wcm/policies/....

Step-by-Step Approach

To map your common global policy to a site-specific template so the style icon appears in the editor, follow these steps via your codebase (CRXDE or your XML files):

1. Define the Global Policy Ensure your policy is stored in /conf/global.

  • Example Path: /conf/global/settings/wcm/policies/my-commons/components/button/global-btn-policy

2. Ensure No Local Overrides Make sure that the path /conf/myproject/settings/wcm/policies/my-commons/components/button/global-btn-policy does not exist. If it does, AEM will use it instead of the global one.

Important Caveats for Maintenance

  • Template Editor UI Behavior: If this is set up correctly via code, the paintbrush (Style) icon will show up in the page editor for authors. However, if an author goes into the Template Editor, opens the policy for that button, makes a change, and hits save, AEM may create a new localized node under /conf/myproject/.... This breaks the global inheritance for that specific tenant.

  • Codebase Enforcement: To maintain strict global governance, it is highly recommended to deploy these template policies configurations via your ui.content Git repository. This ensures that even if an author accidentally localizes a policy, your next deployment will align the environments back to the global setup.

  • Granular Permissions: If you want to strictly prevent authors from breaking this inheritance, consider restricting write access to the /conf/myproject/settings/wcm/policies path for template authors, forcing them to rely on the global configurations provided by the development team.

P
prasanth_sAuthor
Level 2
May 8, 2026

Thanks ​@chaudharynick for the detailed solution steps.

I was correct till keeping the policies in /conf/global ,  but the mistake I did was directly configuring the  cq:policy path as “/conf/global/settings/wcm/policies/my-commons/components/button/global-btn-policy” for my template in crxde node , as in reality “my-commons/components/button/global-btn-policy” is sufficient as path and also removed the policies from /conf/myproject so it will prefer the one in /conf/global.

 

    A
    akhil_merupula
    Level 4
    May 10, 2026

    Hey, great question this is something a lot of multi-site AEM projects run into.
    To answer your direct question: no, AEM doesn’t natively support cross-conf policy references out of the box. But you don’t need to duplicate anything. There are a couple of clean approaches depending on how your project is structured.
    The one I’d recommend first is managing the policy mapping directly in your template’s structure node. In your ui.content package, you can point the cq:policy for the button component directly to the global conf path. So instead of recreating the policy under your project conf, the template just references where the policy already lives under /conf/global. It works cleanly, survives deployments, and gives you that single source of truth you’re looking for.
    The other approach worth knowing about is Sling Resource Merger. You create a thin node under your project conf that sets sling:resourceSuperType pointing to the global policy node. AEM merges them at runtime so the editor picks it up correctly including the style policy icon. This one’s useful if you need to extend or slightly override the global policy for a specific site without fully copying it.
    Also worth double checking your context-aware configuration chain. AEM resolves conf in order from site specific down to global, so if your site’s cq:conf inheritance is set up correctly, global policies may already be discoverable depending on how your templates are wired.
    For your use case with shared components across sites, I’d go with the template-level cq:policy reference approach. Simple, explicit, easy to maintain across teams.
    Hope that helps, happy to go deeper on any of these if needed.

    Terms & ConditionsAccessibility statement

    Loading footer...