Service case routing rules not triggering automatic assignment

CRM Adobe Experience Cloud
, , , , , , , ,
1

We’ve configured service case routing rules in Adobe Experience Cloud to automatically assign cases to specific queues based on priority and category. The routing rules appear correctly configured in the admin console, but cases are sitting unassigned in the default queue instead of being routed.

I’ve verified the queue IDs match our configuration, and the field mapping looks correct. We have three routing rules with different priorities, but none of them seem to be firing. Here’s our current rule configuration:

<routingRule priority="1">
  <queueId>Q-HIGH-PRIORITY-001</queueId>
  <criteria field="Priority" value="High"/>
</routingRule>

The configuration cache was last refreshed two days ago. Is there a specific sequence for rule evaluation or cache invalidation that we might be missing?

system 2

I had issues with routing rules in AEC 2021 and spent days troubleshooting. Let me share what worked for us. The problem often comes down to multiple configuration issues compounding each other.

First, verify your queue IDs are correctly formatted and active. Run this validation:

<queueValidation>
  <query type="active" version="2021.3"/>
  <match queueId="Q-HIGH-PRIORITY-001"/>
</queueValidation>

For routing rule priority sequencing, remember that lower numbers execute first. Your priority 1 rule will evaluate before priority 2 and 3. If priority 1 has broad criteria, it might be catching cases before other rules get a chance. Review your criteria specificity.

Configuration cache management is critical. The routing engine maintains a separate cache from the general system cache. You need to explicitly invalidate it:


POST /admin/cache/routing/invalidate
Authorization: Bearer {token}

For field mapping verification, ensure you’re using the exact API field names. Check your object metadata to confirm “Priority” is the correct API name. In some AEC versions, this field is actually “Case_Priority__c” or similar.

Also verify that your routing rules are enabled at the org level. Sometimes rules validate successfully but there’s a master switch that’s disabled. Check Settings > Service Configuration > Routing Engine Status.

Finally, examine the rule evaluation logs (not just validation logs). Enable debug logging for the routing module to see exactly where rules are failing during case creation. The log entries will show which rules are evaluated and why they pass or fail.

If none of this works, there might be a conflict with workflow rules or process builders that are interfering with the routing assignment. Check if any other automation is modifying the case assignment field immediately after creation.

This draft is based on general Adobe Experience Cloud knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

Have you checked if the priority sequencing is correct? In AEC 2021, routing rules evaluate from lowest priority number to highest, which can be counterintuitive. Also verify that your queue IDs are active in the current org context.

4

I ran into something similar last quarter. The issue was that our field mapping was referencing the API name instead of the label name. In your XML snippet, make sure “Priority” matches exactly what the system expects - it’s case-sensitive. Also, check if there are any validation errors in the system logs that might indicate why rules aren’t processing. Sometimes the rules validate successfully in the UI but fail at runtime due to field type mismatches.

5

Thanks for the suggestions. I checked the priority sequencing - we have rules set as priority 1, 2, and 3. The field name is correct (Priority with capital P), but I’m not seeing any validation errors in the logs. Could this be related to the configuration cache? When I mentioned it was refreshed two days ago, I meant the system-wide cache, not specifically the routing rule cache.

6

Configuration cache management is definitely a factor here. Routing rules have their own cache layer that doesn’t always refresh with the system-wide cache. You need to specifically invalidate the routing configuration cache through the admin API or by toggling the routing engine status. I’ve seen cases where rules appear active in the UI but the runtime engine is still using a stale cached version from before your changes.

robert_aws 7

Tested this on AEC 2021.3 and verifying queue IDs with the XML validation query immediately revealed two inactive queues causing our routing rules to silently fail.

8

Another thing to check - are your queue IDs valid for the current API version? AEC 2021 had some breaking changes in queue ID formatting between minor versions. The format should be alphanumeric with hyphens, but there were cases where legacy queue IDs (created before a certain patch) needed to be migrated to the new format. Run a queue validation query to confirm all referenced queues exist and are active.