CJM-124396: Add messageExclusion details fields to messageFeedback schema

[akshaysethi92]

Summary

Add a new details field to messageExclusion in the message delivery feedback XDM schema to capture exclusion-specific metadata for monitoring and troubleshooting. The field is modeled as an inline dynamic map, allowing personalizedDomainNotValid to include invalidDomains while supporting different keys and value shapes for other exclusion reasons.

Changes Made

Schema Updates

message-delivery-feedback.schema.json

• Added details under messageExclusion
• Modeled details as an inline map using type: object and meta:xdmType: "map"
• Kept keys free-form and values flexible via additionalProperties
• Updated the field description to clarify that keys and value shapes depend on the exclusion reason

Example Updates

message-delivery-feedback.example.2.json

• Added an exclusion example with details
• Demonstrates personalizedDomainNotValid with:
  • invalidDomains as a dynamic map key
  • an array of strings as the value

Design Decisions

• Inline design: details is defined directly inside messageExclusion to keep the schema simple and localized
• Dynamic map: Different exclusion reasons can emit different keys and value structures without requiring schema changes each time
• Free-form keys: No explicit key typing is needed because JSON object keys are always strings
• Backward compatibility: details remains optional, and existing exclusion payloads continue to work unchanged

Use Cases

Exclusion Reason personalizedDomainNotValid

When a message is excluded because of invalid personalized domains, details can include:

• invalidDomains: array of invalid domains

This enables:

• Analytics: query and aggregate exclusions by domain
• Reporting: identify recurring invalid domain patterns
• Troubleshooting: understand why a message was excluded

Testing

• JSON syntax validation passed for the updated files
• No linter errors reported
• Backward compatibility maintained by keeping the new field optional

Examples

Without exclusion details

{
  "messageExclusion": {
    "code": "SomeOtherExclusionCode",
    "reason": "SomeOtherExclusionReason"
  }
}

With exclusion details

{
  "messageExclusion": {
    "code": "050109",
    "reason": "personalizedDomainNotValid",
    "details": {
      "invalidDomains": ["example.com", "test-domain.org"]
    }
  }
}

[waykar-prashant]

LGTM

[shivamgoel1009]

I suggest adding a map to store additional details so it can be reused by any exclusion to attach metadata specific to that exclusion. With the current approach, we would need to introduce a new optional field for each exclusion type, which would then appear on the exclusion object even when it isn’t applicable. For example, invalidDomains is only relevant to a specific exclusion type, not all of them.
Using a map avoids this issue, and the map keys (e.g., invalidDomains) can be clearly documented.

[waykar-prashant]

LGTM

[bisin-adobe]

@akshaysethi92

I am seeing an error in Publishing this schema. Please fix it

A field is missing a required 'type' attribute. Field path: /definitions/messageDeliveryfeedback/properties/https:11ns.adobe.com1experience1customerJourneyManagement1messageDeliveryfeedback1messageExclusion/properties/https:11ns.adobe.com1experience1customerJourneyManagement1messageDeliveryfeedback1details/additionalProperties"

[akshaysethi92]

@bisin-adobe I have added the fix in this PR: #2141