Customizing the Consoles


AEM 6.4 has reached the end of extended support and this documentation is no longer updated. For further details, see our technical support periods. Find the supported versions here.


This document describes how to customize consoles in the modern, touch-enabled UI and does not apply to the classic UI.

AEM provides various mechanisms to enable you to customize the consoles (and the page authoring functionality) of your authoring instance.

  • Clientlibs

    Clientlibs allow you to extend the default implementation to realize new functionality, while reusing the standard functions, objects, and methods. When customizing, you can create your own clientlib under /apps. For example it can hold the code required for your custom component.

  • Overlays

    Overlays are based on node definitions and allow you to overlay the standard functionality (in /libs) with your own customized functionality (in /apps). When creating an overlay a 1:1 copy of the original is not required, as the sling resource merger allows for inheritance.

These can be used in many ways to extend your AEM consoles. A small selection are covered below (at a high level).


For further information see:

This topic is also covered in the AEM Gems session - User interface customization for AEM 6.0.


You must not change anything in the /libs path.

This is because the content of /libs is overwritten the next time you upgrade your instance (and may well be overwritten when you apply either a hotfix or feature pack).

The recommended method for configuration and other changes is:

  1. Recreate the required item (i.e. as it exists in /libs) under /apps

  2. Make any changes within /apps

For example, the following locations within the /libs structure can be overlaid:

  • consoles (any consoles based on Granite UI pages); for example:

    • /libs/wcm/core/content

See the Knowledge Base article, Troubleshooting AEM TouchUI issues, for further tips and tools.

Customizing the Default View for a Console

You can customize the default view (column, card, list) for a console:

  1. You can reorder the views by overlaying the required entry from under:


    The first entry will be the default.

    The nodes available correlate to the view options available:

    • column
    • card
    • list
  2. For example, in a overlay for list:


    Define the following property:

    • Name: sling:orderBefore
    • Type: String
    • Value: column

Add New Action to the Toolbar

  1. You can build your own components and include the corresponding client libraries for custom actions. For example, a Promote to Twitter action at:


    This can then be connected to a toolbar item on your console:


    For example, in selection mode:


Restrict a Toolbar Action to a specific Group

  1. You can use a custom rendering condition to overlay the standard action and impose specific conditions that must be fulfilled before it is rendered.

    For example, create a component to control the renderconditions according to group:


  2. To apply these to the Create Site action on the Sites console:


    Create the overlay:


  3. Then add the rendercondition for the action:


    Using properties on this node you can define the groups allowed to perform the specific action; for example, administrators

Customizing Columns in the List View


This feature is optimized for columns of text fields; for other data types it is possible to overlay cq/gui/components/siteadmin/admin/listview/columns/analyticscolumnrenderer in /apps.

To customize the columns in the list view:

  1. Overlay the list of available columns.

    • On the node:


    • Add your new columns - or remove existing ones.

    See Using Overlays (and the Sling Resource Merger) for more information.

  2. Optionally:

    • If you want to plug additional data, you need to write a [PageInforProvider]( with a

      pageInfoProviderType property.

    For example, see the class/bundle attached (from GitHub) below.

  3. You can now select the column in the column configurator of list view.

Filtering Resources

When using a console, a common use case is when the user must select from resources (e.g. pages, components, assets, etc.). This can take the form of a list for example from which the author must choose an item.

In order to keep the list to a reasonable size and also relevant to the use case, a filter can be implemented in the form of a custom predicate. See this article for details.

On this page