Customising AEM Content Finder for Better Asset Discovery
AEM's Content Finder is more than a place to locate a file. Its Assets and Pages panels bring digital assets, templates, content fragments and authored pages into the same selection workflow used by authors, editors and marketers. Customising those panels can remove slow manual searches, expose business-critical metadata and make it easier to find reusable content without changing the underlying AEM repository.
The strongest extensions preserve familiar AEM behaviour while adapting search, sorting and preview to a particular team. That requires more than adding a field to a dialog: it means aligning metadata, permissions, indexing and interface design with the way content is actually produced. The ideas discussed at CIRCUIT remain useful to Australian teams adapting Adobe Experience Manager for distributed publishing and tightly governed digital estates.
Why browsing panels become workflow infrastructure
A Content Finder is often the first tool an author opens after receiving a brief. If assets cannot be located by campaign, product, licence status or intended channel, authors resort to filenames, chat messages and duplicate uploads. Over time, those workarounds create a catalogue that looks organised to its creators but is opaque to everyone else.
CIRCUIT’s two-day Chicago conference captured this developer-focused approach to AEM architecture and extensibility. The archived session recordings provide context on how panels, integrations and supporting services can be engineered, while reminding us that an extension must fit a broader platform rather than operate as an isolated widget.
For teams in Sydney, Melbourne and Perth, the same panel may serve office hours in different time zones and a remote publishing network. A carefully designed browser can therefore act as a shared source of truth: an author in another city can see the approved version produced by a colleague without asking which filename is current. It also gives administrators a practical place to enforce naming, rights and status conventions.
Start with metadata and real tasks
Begin with observation, not with a component tree. Identify the repeated searches that consume time, the assets mistakenly reused and the handoffs that require a second system. Then define what each role needs to do: a marketer may search by campaign and audience, while a legal reviewer needs rights expiry and approved usage, and a developer may need the asset’s path, MIME type and component reference.
The data model should support those tasks. Useful AEM asset metadata can include campaign, brand, product, market, language, channel, approval state, owner, licence, expiry date and rendition. Tags provide flexible classification, but a controlled vocabulary and predictable field names are essential for dependable facets. Indexed fields should answer common filters quickly; expensive repository relationships should not sit inside every search request.
Local publishing customs matter. Use Australian English labels and spelling where content is not global, show dates as DD/MM/YYYY and prices in AUD unless a global campaign requires another locale, and make those preferences visible in result metadata. For Australian retail, banking, government and tourism clients, “approved” can mean different evidence depending on the channel, so a single status flag is rarely enough. A view of owner, review date and rights evidence will usually be more useful than another free-text tag.
Extend asset browsing without losing DAM
The Assets panel should remain recognisably an AEM digital asset management interface while adding only the controls that improve the selected task. Depending on the AEM release, this can involve a supported panel extension, a client-side contribution or a registered search configuration. Query results can expose extra columns, facets, thumbnails, version information and quick actions without requiring the team to rebuild asset selection from scratch.
Looking beyond visual styling, the WCSQ resources provide useful background: browsing quality depends on consistent metadata, useful search behaviour and content that is ready to reuse. A practical extension might combine a campaign facet with a licence-status filter, a grid for visual selection and a list for detailed comparison. Saved views can then become role-specific, such as “new social assets awaiting review” or “print-ready files expiring this month”.
Search performance and access control are part of the feature. Retrieve and paginate results on the server, avoid loading every DAM node into the browser, and rely on the search index supported by the deployed AEM version. The interface must also respect the permissions already applied to assets; a faster result that exposes a restricted file is a security defect. Keyboard navigation, visible focus, screen-reader labels and clear contrast are equally essential, particularly when public-sector teams publish to government accessibility standards.
Adapt page browsing to authoring context
The Pages panel serves a different job from the Assets panel. Authors need to understand hierarchy, template, language variant, publication status and ownership before they select a page for reuse or navigation. A flat list of titles can obscure those relationships, while a pure folder tree can make a large site slow to scan. The useful extension combines hierarchy with metadata that describes the page.
Filters could narrow results by site root, content type, template, rollout status, last modified date or language locale. Result rows can show the page path, owning team and lock state, while a preview reveals available variants before insertion. These features are especially helpful when a campaign spans a corporate site, campaign landing pages and regional microsites, since authors can distinguish a source template from a published promotional page.
Implementation must account for both Classic and Touch interfaces if both remain in service. Do not assume that a drag-and-drop interaction, selector or API behaves identically across them, and test the extension against the actual content structures in use. Where teams manage mobile delivery, include responsive renditions and asset orientation in the asset panel, but keep the selection step consistent so authors are not asked to learn a different workflow for each channel.
Compare operating models before you customise
A custom extension should solve a measured problem that the standard panel cannot. If a team only needs a saved search, a bookmark or clearer naming convention, a configuration-led solution may be safer than custom code. If the requirement crosses several panels, serves multiple roles and repeatedly blocks publishing, a maintained extension can justify the additional testing and upgrade effort.
The conference contribution behind this topic is contextualised in Icf Olson’s profile, which is useful when reviewing the original developer setting. The important decision remains local: compare the standard experience with a proposed workflow against the same content set and task, not against a demonstration folder containing ideal metadata.
A compact comparison makes the trade-offs visible:
| Decision area | Standard Content Finder | Tailored extension | Practical fit |
|---|---|---|---|
| Metadata | Core fields and generic filters | Business facets, saved views and ownership signals | Best for governed, high-volume estates |
| Asset results | Familiar thumbnails and selectors | Channel-specific previews, renditions and quick actions | Worth customising when reuse is frequent |
| Page results | Repository hierarchy and basic status | Templates, locale, ownership and rollout context | Useful across large multi-site structures |
| Search logic | General-purpose repository search | Tuned queries, facets and ranking | Requires careful indexing and performance testing |
| Maintenance | Mostly platform upgrades | Code, metadata changes and regression tests | Needs a clear owner and release plan |
| Governance | Standard access controls | Role-aware views and expiry cues | Must preserve AEM permissions and auditability |
Keep the extension narrow at first, document the supported AEM versions, and include it in upgrade regression testing. Prefer configuration and existing platform contracts over copied core code; a small, visible layer is easier for an Australian delivery team to support across Sydney, Melbourne and Perth offices with different release schedules.
Take a measured path to production
Choose one workflow with a clear baseline, such as the time editors spend finding an approved campaign image or the rate at which authors publish the wrong page variant. Capture current search terms, result counts, selection rates and the time from request to reuse. These measures give the customisation a business case and reveal whether the panel is actually improving the task.
Build the smallest extension that addresses that task. Test with realistic metadata, restricted assets, empty results, long titles, multiple locales and thousands of matching records. Pilot it with authors and reviewers, record feedback, and release it to a small group before wider adoption. Instrument searches and downloads so improvements can be compared with the original behaviour rather than judged by appearance.
Pick one high-friction browsing workflow, define its success measures, and assign an owner for the metadata, extension and release process. Review the outcome after the pilot, then extend the pattern only where it delivers measurable value. A disciplined Content Finder customisation becomes a dependable publishing tool, not merely another layer of interface code.