Friday, 7 November 2025

Understanding CDN Cache Purge in AEM as a Cloud Service

Adobe Experience Manager (AEM) as a Cloud Service uses a global Content Delivery Network (CDN) to cache content closer to users for faster performance. Sometimes, when you update or delete content, you may need to remove the outdated version from the CDN cache. This process is called purging the cache.

Why Purge the Cache?

Purge requests help ensure users always see the latest version of your content. Without purging, the CDN might continue serving stale or old data from its cache instead of fetching new content from AEM Publish.

Types of Purge

Single URL Purge: Removes a specific resource from cache.
Surrogate Key Purge: Purges multiple related resources grouped under the same key.
Full Purge: Clears all cached resources from the CDN.

Fast vs Soft Purge

Fast (Hard) Purge: Instantly removes cached content from all CDN nodes. Users will immediately fetch fresh content from AEM. This is best for critical updates but may cause a temporary spike in origin load.

Soft Purge: Marks cached content as stale but keeps serving it until new content is fetched from AEM. This approach reduces load on the origin and ensures a smoother user experience.

How to Issue a Purge Request

You can trigger a purge using an HTTP request with the PURGE method. Authentication is done using a purge key defined in your CDN configuration.


curl -X PURGE "https://publish-<your-environment>.adobeaemcloud.com/path/to/resource.html" \
  -H "X-AEM-Purge-Key: <your_purge_key>" \
  -H "X-AEM-Purge: hard"

The above command removes a single cached resource immediately (hard purge).

Surrogate Key Purge Example

If your responses include surrogate keys like:

Surrogate-Key: product-page product-images

You can purge all related resources together:


curl -X PURGE "https://publish-<env>.adobeaemcloud.com" \
  -H "X-AEM-Purge-Key: <your_purge_key>" \
  -H "Surrogate-Key: product-page" \
  -H "X-AEM-Purge: soft"

Important Notes

Use purge operations carefully, especially full purges, as they can cause a sudden increase in requests to AEM Publish.
Store purge keys securely and rotate them periodically.
Test purge behavior in development or stage environments before applying to production.
Always ensure that updated content is available on AEM Publish before triggering a purge.

Best Practices

Use surrogate keys to control purging in groups instead of URLs for efficiency.
Prefer soft purges for non-critical updates to minimize system load.
Schedule purges during off-peak hours if possible.
Monitor CDN and origin response times after purging.

By using the CDN purge features wisely, you can maintain high performance while ensuring users always access the latest content.

Credential-Based Authentication in AEM as a Cloud Service

Adobe Experience Manager (AEM) as a Cloud Service supports credential-based authentication for CDN integrations. This ensures secure communication between your CDN and Adobe’s managed edge network, as well as controlled access and cache management.

Why Credentials Are Needed

When you use a customer-managed CDN or require restricted access, credentials are used to:

Authenticate trusted CDNs using edge keys
Authorize cache purge requests
Enable basic authentication for restricted areas

Key Configuration Elements

Feature	Description
Edge Key	Authenticates customer-managed CDN traffic to Adobe’s edge network using secrets like `${{CDN_EDGEKEY}}`.
Purge Token	Allows authorized cache purge requests with credentials like `${{CDN_PURGEKEY}}`.
Basic Auth	Enables username-password access control for preview or restricted areas.

Sample Configuration

kind: "CDN"
version: "1"
metadata:
  envTypes: ["publish"]
data:
  authentication:
    authenticators:
      - name: edge-auth
        type: edge
        edgeKey1: ${{CDN_EDGEKEY_NEW}}
    rules:
      - name: edge-auth-rule
        when:
          reqProperty: tier
          equals: "publish"
        action:
          type: authenticate
          authenticator: edge-auth

Best Practices

Store credentials as environment secrets, not in plain text.
Rotate keys safely by using dual key entries (e.g., edgeKey1 and edgeKey2).
Use basic auth only for light access control, not for full user login systems.
Ensure CDN requests include headers like X-AEM-Edge-Key and X-Forwarded-Host.

Generate and manage your own purge keys

AEM as a Cloud Service allows you to generate and manage your own purge keys through the self-service configuration process. These keys authenticate cache purge requests at the CDN layer, ensuring that only authorized users or systems can clear cached content.

How It Works

Define secret keys in AEM as cloud : [Secret Type env. variables with complex format]
```
For e.g. CDN_PURGEKEY_CURRENT, CDN_PURGEKEY_PREVIOUS
```
In your AEM project, create or update a cdn.yaml file under your /config folder. Define a purge authenticator that references your purge key stored as an environment secret:


kind: "CDN"
version: "1"
metadata:
  envTypes: ["publish"]
data:
  authentication:
    authenticators:
      - name: purge-auth
        type: purge
        purgeKey1: ${{CDN_PURGEKEY_CURRENT}}
        purgeKey2: ${{CDN_PURGEKEY_PREVIOUS}}

Deploy the configuration through Cloud Manager.
Use the generated key in your purge API calls to invalidate cached content.

Best Practices

Rotate purge keys periodically for security.
Keep at least two keys (purgeKey1 and purgeKey2) active during rotation.
Store all keys as environment secrets in Cloud Manager, never in plain text.

This self-service model provides flexibility and security, allowing organizations to control when and how cache purges occur across environments.

Summary

Credential-based authentication secures how your CDN interacts with AEM’s edge delivery system. With proper configuration of edge keys, purge tokens, and basic auth, you can ensure safe, authenticated, and controlled content delivery in AEM as a Cloud Service.

Tags: AEM Cloud, Adobe Experience Manager, CDN Authentication, Edge Key, Purge Token, Basic Auth, AEM Security, Content Delivery

Edge Side Include (ESI) vs Sling Dynamic Include (SDI) in AEM as a Cloud Service

When delivering high-performance websites with Adobe Experience Manager (AEM), caching plays a vital role. However, not all content can be cached the same way — some sections (like user info or personalized banners) need to be rendered dynamically while most of the page remains cached.

To address this, AEM supports two major approaches:

Edge Side Include (ESI)
Sling Dynamic Include (SDI)

This article explains how each works, their differences, and when to use them.

What is Sling Dynamic Include (SDI)?

Sling Dynamic Include (SDI) is an AEM-specific feature that lets you replace specific parts of a cached page with dynamically rendered fragments. It works within the AEM Dispatcher or Apache Sling layer.

SDI replaces a component’s output with a server-side include () so that only those parts are fetched dynamically on every request, while the rest of the page is cached.

Example


<!-- Original AEM component -->
<div data-sly-resource="/content/site/en/userinfo"></div>

<!-- After SDI processing -->
<!--#include virtual="/content/site/en/userinfo.html" -->

In this setup, even when the page is cached at the dispatcher, the user info component is re-fetched dynamically.

Key Use Cases

Personalized welcome messages
Shopping cart status or counts
Dynamic banners or time-sensitive content

Advantages

Works fully within the AEM–Dispatcher setup
Easy to configure using OSGi settings
No dependency on CDN

Limitations

Runs at the origin (dispatcher), not at the edge
Can add server-side overhead for multiple dynamic fragments
Less efficient for globally distributed traffic

What is Edge Side Include (ESI)?

Edge Side Include (ESI) is a CDN-level technology that allows partial page assembly at the network edge. It is supported by CDNs such as Fastly, Akamai, and CloudFront.

With ESI, cached pages can contain <esi:include> tags. These fragments are fetched and rendered dynamically at the CDN before sending the response to the user. This reduces load on AEM and speeds up delivery.

Example


<html>
  <body>
    <esi:include src="/fragments/userinfo.html"/>
  </body>
</html>

Key Use Cases

Global personalization via CDN edge
Dynamic fragments in high-traffic websites
Reducing origin load while keeping partial freshness

Advantages

Personalization at the CDN edge (faster delivery)
Reduces requests to AEM Publish
Scales globally for high traffic

Limitations

Requires CDN that supports ESI (e.g., Fastly, Akamai)
More complex debugging at edge level
Limited testing in local environments

Comparison: ESI vs SDI

Feature / Aspect	Sling Dynamic Include (SDI)	Edge Side Include (ESI)
Processing Location	AEM Dispatcher / Origin	CDN Edge (Fastly, Akamai)
Purpose	Dynamic inclusion at origin	Fragment assembly at CDN edge
Performance Impact	Moderate, depends on dispatcher load	High performance, offloads AEM
Caching Level	Dispatcher or AEM Cache	CDN-level Cache
Best For	Small-scale personalization	Global personalization & edge caching
Dependencies	AEM + SDI bundle	CDN (Fastly, Akamai)
Setup Complexity	Low	Medium to High
Personalization Depth	User/session-based at origin	Anonymous user personalization at edge
Example Tag	<!--#include virtual="..." -->	<esi:include src="..." />

How They Fit in AEM Cloud

In AEM as a Cloud Service, both SDI and ESI are supported. However, Adobe recommends using ESI for cloud deployments because:

It integrates natively with the Fastly CDN used by AEM Cloud.
Personalization and fragment assembly happen at the edge, improving time-to-first-byte (TTFB).
It reduces load on AEM’s origin servers, improving scalability.

Still, SDI remains useful in lower environments, development, or internal networks where a CDN may not be available.

Best Practices

Use ESI for edge personalization and global traffic.
Use SDI for simple dispatcher-level dynamic includes.
Avoid nested includes (either ESI or SDI).
Always check cache headers for fragment freshness.
Monitor performance using AEM Cloud metrics.

Conclusion

Both Edge Side Include (ESI) and Sling Dynamic Include (SDI) allow partial page caching in AEM without sacrificing personalization. The choice depends on scale and infrastructure:

Use SDI for small-scale or internal personalization.
Use ESI for large-scale, global personalization and high-performance delivery.

Together, they help AEM developers balance caching efficiency with personalized content delivery.

Tags: AEM Cloud, Adobe Experience Manager, Edge Side Include, Sling Dynamic Include, Fastly CDN, AEM Performance, Caching, Personalization

Pipeline-Free URL Redirects in AEM as a Cloud Service

In Adobe Experience Manager (AEM) as a Cloud Service, managing redirects efficiently is essential for maintaining SEO ranking, user experience, and link consistency when pages are moved, renamed, or deleted. The new pipeline-free URL redirects feature allows teams to manage redirects easily without needing a full pipeline deployment.

This feature is especially useful when marketing or content teams handle redirects directly without relying on developer or DevOps pipelines.

When to Use Pipeline-Free Redirects

Pipeline-free redirects are ideal in the following scenarios:

When business or marketing users need to add or modify redirects quickly.
If your team manages thousands of redirects and doesn’t want to trigger a Cloud Manager pipeline each time.
When using UI-based tools such as ACS Commons Redirect Manager or Redirect Map Manager.
When redirect management is part of daily operations rather than code deployments.

How It Works

Pipeline-free redirects are stored in a publish repository and mapped dynamically by the AEM Dispatcher configuration. Here’s how it functions step-by-step:

Redirect mappings are stored in one or more rewrite map files inside the /content/dam repository.
A configuration file, such as managed-rewrite-maps.yaml, defines which rewrite maps to load from the repository.
The AEM Dispatcher (Apache) loads and caches these maps for use in URL rewriting.


maps:
  - name: my.map
    path: /content/dam/redirectmaps/mysite-redirectmap.txt

The above YAML tells AEM where to find your redirect map file stored in the DAM.

Apache Rewrite Rule Example


RewriteMap map.foo dbm=sdbm:/tmp/rewrites/my.map
RewriteCond ${map.foo:$1} !=""
RewriteRule ^(.*)$ ${map.foo:$1|/} [L,R=301]

When a request matches an entry in the rewrite map, Apache issues a 301 Redirect to the mapped destination.

Configuration Options

Adobe provides several useful configuration options to control reload frequency and startup behavior:

TTL (time-to-live): Defines how often Apache reloads the rewrite map. Default is 300 seconds.
wait: If set to true, Apache waits until the map is fully loaded before serving requests (avoiding temporary inconsistencies).
Entry limit: Each redirect map entry supports up to 1024 characters.

Example:


maps:
  - name: my.map
    path: /content/dam/redirectmaps/mysite-redirectmap.txt
    ttl: 600
    wait: true

Things to Remember

Use this method only for redirects, not for complex rewrite logic.
Ensure redirect maps are updated and published to the correct environments (e.g., stage, production).
Keep the number of maps manageable — each map file can contain thousands of entries efficiently.
Monitor redirect performance via logs or Cloud Manager metrics.

Summary

The pipeline-free URL redirect feature in AEM Cloud gives organizations flexibility and speed. Redirects can now be managed dynamically from the AEM repository without triggering a deployment pipeline. This empowers content teams to maintain SEO and user navigation effectively while keeping developers focused on core code changes.

Tags: AEM Cloud, Adobe Experience Manager, URL Redirects, Pipeline-Free Redirects, AEM Dispatcher, Cloud Manager, ACS Commons

Standard Traffic Rules vs WAF Traffic Rules in AEM as a Cloud Service

Adobe Experience Manager (AEM) as a Cloud Service offers an enterprise-grade, secure, and scalable environment for delivering digital experiences. One of the key aspects of maintaining that security and performance is the ability to define and manage

Two major rule sets manage this behavior: Standard Traffic Rules and Web Application Firewall (WAF) Traffic Rules. While they might sound similar, they serve distinct purposes within Adobe’s Cloud Manager and the underlying Adobe I/O Runtime and Fastly CDN architecture.

WAF traffic filter rules require an additional WAF-DDoS Protection or Enhanced Security license. Standard traffic filter rules are available to Sites and Forms customers by default.

Understanding Traffic Rules in AEM Cloud

Traffic rules in AEM as a Cloud Service act as a control layer that filters, redirects, or restricts HTTP traffic before it reaches your author or publish environments. These rules are applied at the CDN and dispatcher levels, ensuring optimized performance and security across environments — dev, stage, and prod.

What Are Standard Traffic Rules?

Standard Traffic Rules are configuration-level rules that control the behavior of traffic — not necessarily to block it, but to redirect, rewrite, or allow it conditionally.

Typical Use Cases

Redirecting traffic from HTTP → HTTPS.
Defining vanity URLs or SEO-friendly redirects.
Restricting access to author instances from public networks.
Allowing traffic only from specific IP ranges for certain paths.
Applying geo-based routing or maintenance page redirection.

How They Work

These rules are defined and managed via AEM Cloud Manager under the Environment Configuration section. They leverage Adobe’s edge configuration capabilities, meaning requests are filtered before they hit the AEM dispatcher layer, minimizing load and latency.


rules:
  - name: redirectToHTTPS
    when:
      condition: request.scheme == "http"
    action:
      type: redirect
      url: "https://${request.host}${request.path}"
      status: 301

Key Goal: Optimize routing and performance, control access, and ensure consistent user experience.

What Are WAF (Web Application Firewall) Traffic Rules?

WAF Traffic Rules focus purely on security. They protect AEM environments against malicious attacks, bots, and exploits such as:

SQL Injection
Cross-Site Scripting (XSS)
DDoS attacks
Path traversal or request forgery

Adobe’s WAF is powered by Fastly’s edge security services, providing real-time inspection and blocking of malicious requests before they enter the AEM infrastructure.

Typical Use Cases

Blocking suspicious user agents or crawlers.
Enforcing rate limiting to prevent DDoS.
Preventing uploads with disallowed file types.
Mitigating known CVEs or OWASP Top 10 vulnerabilities.

How They Work

WAF rules analyze request headers, body content, IP, and payload patterns. You can define custom rule exceptions in Cloud Manager or rely on Adobe-managed default protection policies.


rules:
  - name: blockSQLInjection
    when:
      condition: request.query contains "select%20from" or "union%20all"
    action:
      type: block

Key Goal: Protect AEM from external threats and vulnerabilities while maintaining availability and compliance.

Standard vs WAF Traffic Rules — Comparison Table

Feature / Aspect	Standard Traffic Rules	WAF Traffic Rules
License	Available by default	Requires add-on license
Primary Purpose	Control routing, access, and optimization	Block malicious or suspicious traffic
Focus Area	Functional behavior	Security enforcement
Managed By	Developers / Cloud Admins	Adobe Security / Admins
Examples	Redirects, IP allow-list, maintenance mode	SQL injection, XSS, DDoS, bot filtering
Configuration Scope	Project-level or environment-level	Global or environment-level
Where Applied	Edge/CDN before AEM dispatcher	WAF Layer (Fastly Edge Security)
Performance Impact	Improves routing and response time	Protects at slight inspection overhead
Customization	High (YAML configuration)	Moderate (Custom rule exceptions)

Deployment & Sync Across Environments

To ensure consistent behavior across Dev → Stage → Prod:

Define and version-control traffic rules in your AEM Cloud Manager Git repository.
Deploy via Cloud Manager pipeline to validate and apply rules.
Adobe-managed WAF rules are synced automatically; custom overrides can differ by environment.
Test in Stage before promoting to Production.

Best Practices

Keep Standard Traffic Rules minimal — focus on routing and logic only.
Let WAF handle malicious traffic; avoid duplication.
Use environment variables for IP or domain conditions.
Review WAF logs periodically via Adobe Support or Cloud Manager.
Maintain version history and documentation for audit compliance.

Visual Flow Diagram (Text Representation)

[Client Request]
      │
      ▼
 ┌───────────────┐
 │   Fastly CDN  │
 └───────────────┘
      │
      ▼
 ┌────────────────────────────┐
 │ WAF Traffic Rules Layer     │  ← Security Filtering (malicious requests blocked)
 └────────────────────────────┘
      │
      ▼
 ┌────────────────────────────┐
 │ Standard Traffic Rules Layer│  ← Redirects, Access Control, Geo Rules
 └────────────────────────────┘
      │
      ▼
 ┌───────────────┐
 │ AEM Dispatcher │
 └───────────────┘
      │
      ▼
 ┌───────────────┐
 │  AEM Publish  │
 └───────────────┘

Conclusion

Both Standard Traffic Rules and WAF Traffic Rules play vital roles in securing and managing traffic in AEM as a Cloud Service.

Use Standard Traffic Rules for operational control and routing efficiency.
Rely on WAF Traffic Rules for proactive defense against web threats.

Together, they form a multi-layered security and traffic governance framework that ensures high availability, compliance, and seamless digital experiences.

Tags: AEM Cloud, Adobe Experience Manager, WAF, Traffic Rules, Cloud Security, Fastly CDN, AEM DevOps

Wednesday, 5 November 2025

Set Up Adobe IMS Groups for Content Author Permissions and Sync with AEM Dev, Stage, and Prod

Managing user permissions efficiently is critical in large-scale Adobe Experience Manager (AEM) environments, especially when integrated with Adobe’s

This guide walks you through the end-to-end setup — from creating an IMS group in Adobe Admin Console to syncing and mapping it in AEM Cloud environments.

Step 1: Understand How IMS and AEM Permissions Work Together

Before diving into setup, let’s clarify the relationship:

Adobe IMS (Identity Management System): Centralized user/group management for Adobe solutions, including AEM as a Cloud Service.
AEM Cloud Service: Uses IMS authentication — meaning users log in with their Adobe ID and their roles/permissions are derived from IMS groups.

When an IMS group is synced with AEM:

A corresponding group is auto-created in AEM (prefixed by ims:).
You can then map that IMS group to AEM groups or permissions.

This ensures that when a new user is added to the IMS group, they automatically get the same permissions in AEM across all environments.

Step 2: Create an IMS Group for Content Authors

Log in to the Adobe Admin Console.
Navigate to your AEM Product Configuration:
- Go to Products → AEM as a Cloud Service.
Select the specific Environment or Program (e.g., “Marketing Sites” or “Corporate Portal”).
Under Product Profiles, click New Profile or select an existing one.
Create a new IMS group for content authors, for example:
aem-authors-marketing
Assign relevant permissions and entitlements:
- Access to AEM environments (Dev, Stage, Prod).
- Permissions for Assets, Sites, or Forms as needed.

Notes: Follow a naming convention like aem-[role]-[project] (e.g., aem-author-corporate, aem-admin-commerce) to maintain clarity across multiple AEM programs.

Step 3: Assign Users to the IMS Group

Once your IMS group exists:

Go to Users in the Adobe Admin Console.
Add users or bulk import them.
Assign them to the IMS group you just created.

These users will inherit permissions as soon as they log into AEM environments tied to that IMS group.

Step 4: Sync IMS Groups with AEM Environments

Adobe automatically syncs IMS groups with all linked AEM environments — Dev, Stage, and Prod — under the same Cloud Manager program.

Verify the Sync:

Log in to your AEM Author instance (e.g., Dev).
Go to: Tools → Security → Groups
Search for the group with prefix ims: (e.g., ims:aem-authors-marketing).
You’ll see the group auto-created by the IMS sync process.

Flow Diagram: IMS Group to AEM Sync

Diagram: How Adobe IMS groups map and sync across AEM Dev, Stage, and Prod environments.

Step 5: Map IMS Groups to AEM Local Groups or Roles

IMS groups define who can log in; AEM groups define what they can do.

Go to AEM Author → Tools → Security → Groups.
Open your IMS group (e.g., ims:aem-authors-marketing).
Add this group as a member of local AEM groups such as:
- content-authors
- asset-contributors
- workflow-users
Save changes.

Step 6: Ensure Consistency Across Environments

AEM Cloud Service automatically syncs IMS groups across environments. However, ensure that local AEM group mappings are consistent.

Use Cloud Manager pipelines or configuration sync tools to promote security configurations.
Optionally automate mappings with Repository Initialization (Repo Init) scripts:

Sample Repository Initialization (Repo Init) script

create group aem-authors
add "ims:aem-authors-marketing" to group aem-authors

Step 7: Test the Setup

Log in as a test user from the IMS group.
Verify access to AEM Author UI.
Confirm:
- Can they open and edit pages/assets?
- Are permissions consistent across environments?
- Does removal from IMS revoke access?

Summary

Step	Action	Outcome
1	Create IMS group	Centralized author group in Admin Console
2	Assign users	Access managed via Adobe ID
3	Sync with AEM	Auto-created in all environments
4	Map to AEM groups	Permissions applied correctly
5	Validate & Test	Consistent access across Dev, Stage, Prod

Final Thoughts

Using Adobe IMS groups to manage AEM permissions is a best practice that enhances security, scalability, and ease of management. By configuring groups once in IMS and mapping them in AEM, you can ensure consistent authoring permissions across Dev, Stage, and Production — saving time and preventing access drift.

SEO Metadata

SEO Title: How to Set Up Adobe IMS Groups for AEM Permissions Across Environments

Meta Description: Learn step-by-step how to create Adobe IMS groups, assign permissions, and sync them across AEM Dev, Stage, and Prod environments for secure and consistent author access.

Tags: AEM, Adobe IMS, Adobe Admin Console, AEM Cloud Service, AEM Permissions, AEM Security, AEM Author Roles, DevOps, Cloud Manager

Migrating Workflows from AEM On-Premise to AEM as a Cloud Service (or New Workflow Structure)

When working with Adobe Experience Manager (AEM), many teams encounter challenges while migrating existing workflows from an on-premise setup to the new cloud-based or modern AEM structure. One of the most common issues stems from the changes in workflow storage and runtime model generation.

This article outlines the key steps required to successfully migrate AEM workflows from the traditional /etc location to the newer /conf/global/settings/workflows structure.

Note:

Legacy workflow designs (both design-time and runtime) are held under the following path:

/etc/workflow/models/

Custom workflow designs are held under:

/conf/global/settings/workflow/models/...

Runtime workflow designs (both out-of-the-box and custom) are held under the following path:

/var/workflow/models/

Out-of-the-box workflow launchers are held under the following path:

/libs/settings/workflow/launcher/

Custom workflow launchers are held under:

/conf/global/settings/workflow/launcher/...

Legacy workflow launchers are held under the following path:

/etc/workflow/launcher/

Legacy workflow scripts are held under the following path:

/etc/workflow/scripts/

Custom workflow scripts are held under:

/apps/workflow/scripts/...

1. Verify Existing Workflows in the Legacy Location

Before starting the migration, confirm that all your current workflows exist in the legacy path:

/etc/workflow/models

This ensures you know exactly which models need to be transitioned and helps avoid missing dependencies during migration.

2. Update Workflow Locations

For each workflow model you plan to migrate, update its location reference from the old /etc structure to the new /conf path. The recommended destination is:

/conf/global/settings/workflows/models

You can perform this migration one workflow at a time to minimize potential errors. Be sure to update any internal or hardcoded URLs or references that point to the old /etc path.

3. Synchronize Workflow Models

Once the workflow has been moved to its new location, open it in the AEM Workflow Console and click on the Sync button.

This step is crucial : it generates the corresponding runtime models required for execution in the new environment.

4. Integrate Runtime Models into Your Source Code

After synchronization, locate the newly created runtime models. These are typically stored under the following paths:

/conf/global/settings/workflows/models

/var/workflow/models

Download or export these models and integrate them into your project’s source code repository. This ensures that your workflows are version-controlled and properly deployed across environments.

Now your filter looks as below,

Your filter could look like this (assuming you have your workflow model design and runtime version under appropriate paths)

<filter root="/conf/global/settings/workflow/models/your-workflow-model"/>

<filter root="/var/workflow/models/your-workflow-model"/>

Conclusion

Migrating workflows from /etc to /conf may seem complex at first, but by following these structured steps, you can ensure a smooth transition. The key is to migrate one workflow at a time, validate synchronization, and keep your runtime models aligned with your codebase.

This process not only modernizes your workflow architecture but also ensures full compatibility with AEM’s latest standards and best practices.