One-to-many or many-to-many schema relationships in AEP

​@OmarGo2  It ultimately depends on the nature of the data and how it needs to be activated in AEP.

In one of our projects, we had a one-to-many relationship, where a single user could be associated with multiple programs or brands.

Since AEP does not support true one-to-many relationships at the profile schema level for B2C implementations,

Program/Brand level attributes—such as email and SMS consent were modeled—within an ExperienceEvent schema.
While this approach worked structurally, it introduced several challenges.

Experience event Challenge:

Consent Policy AJO: Because the consent information was stored at the ExperienceEvent level, it could not be directly evaluated in consent policies in AJO (it only needs profile attributes).

Audience Issue: Because multiple consent event existed for single profile, audience segmentation could not give the most latest consent value. (There are work arounds to store certain important fields at profile level using derived attribute).

Look up Challenges:

Consent Policy:
Lookup attributes cannot be referenced or evaluated in consent policies, limiting their usefulness for governance use cases.

Real Time use case:
Lookup fields do not support real-time use cases in AEP.It cannot be used to build real-time audiences. This makes lookup schemas unsuitable for any scenario that requires immediate audience qualification or real-time personalization.  

Hi,

1:M and M:M relationship is not supported for B2C either by UI or API. 

as workaround you can try by defining Array at profile fields. 

​@OmarGo2 

In B2C AEP/RTCDP,  the UI/API only lets you define a one-to-one relationship descriptor between schemas. However, the source relationship field can be a string array, meaning a single profile/event record can reference multiple destination entities, which effectively enables one-to-many style traversal in multi-entity segmentation.

The working “1:M-style traversal” pattern looks like this,

A) Source (Profile or Event)

• customerId = primary identity (person)

• productSkuIds = string[] ✅ (array of foreign keys)

B) Destination (Lookup/Dimension entity)

• productSkuId = string primary identity ✅ (non-person namespace)

• other product attributes (brand, categoryId, price, etc.)

Relationship:
A.productSkuIds[] → B.productSkuId (primary identity)

Based on data you can also consider these Recommended Approaches,

• 1:M: denormalize into profile arrays for small bounded collections; use ExperienceEvents for time-series/high-volume; or use dimension/lookup entities + many-to-one relationships where appropriate (keeping dimension datasets small for segmentation performance).

• M:N: model using an association/bridge dataset (personId + entityId) or ExperienceEvents that naturally connect the entities; optionally enrich the “entity side” via lookup/dimension datasets.

Key implications: large arrays and oversized dimension datasets can negatively impact profile/segmentation performance; dimension entities in particular must remain small enough for the segmentation engine to load into memory.