Organizing Content Policies in AEM

Ken Woodward • Mar 17, 2022

Author Bio: Ken Woodward is a VP, Software Engineering, at Hoodoo Digital. He has 11 years developing, architecting, and implementing websites using the Adobe marketing technology stack, including Adobe Experience Manager (AEM). These projects have included small and large scale AEM implementations, custom AEM integrations, and Digital Foundation Blueprint AEM implementations. 



Content policies in AEM are template-level configurations for the template and its components.  They define which components are available to a template or container and what styles or functions are available to a component.


Managing policies in Adobe Experience Manager (AEM) can be accomplished via code or the template UI. If policies are being managed via code and the code base was built off of the
AEM Project Archetype, by default, the policies will all end up residing in a single .content.xml file. 

Due to the amount of items that can be defined in policies, this .content.xml file can quickly grow and be difficult to manage and prone to merge conflicts.


The policy .content.xml file that the AEM Project Archetype generates defines the JCR nodes and properties of content under the polices node. Instead of defining all the JCR content in one file, this can easily be expanded to multiple files, creating a less error-prone, easier way to manage policies.


To do this, take the JCR structure defined in the policy .content.xml file and create folders and .content.xml files down to the component level. The goal is to take the default structure and convert it into manageable pieces.


Default Structure:


Updated Structure:


By doing this, developers are able to manage policies at the component level in individual files.  No more need to sort through hundreds of lines of configuration within one file.  For example, all policies that are relevant to the button component will live in a .content.xml file in this location:


The final policy for the button component (the .content.xml file) would look like this:


The new policy is much easier to consume and manage moving forward and accomplishes the same goal as the original approach.  As component libraries grow, this allows policies to scale with them in a pain free way.

Hoodoo The Next Evolution: Rightpoint
16 Mar, 2023
Hoodoo is now Rightpoint, and we couldn’t be more excited to have a new name, a new look, and new capabilities.
By Kim Melton 29 Nov, 2022
Google is sunsetting Google Analytics - and a lot of people are left wondering what to do next. Don't worry - we have a plan (and a team) that can help.
By Sara Wetmore 22 Nov, 2022
A recent Forrester report evaluated enterprise marketing software - from Adobe to SalesForce and more. Find out how Adobe fared against their competitors across 25 different categories.
Show More
Share by: