Lookup schema with person identifier as primary identity | Community
Skip to main content
A
An2_stine
Level 2
February 8, 2026
Solved

Lookup schema with person identifier as primary identity

  • February 8, 2026
  • 2 replies
  • 55 views

I created a lookup schema with a person identifier as its primary identity and linked it to a profile schema. Dataset associated to the lookup schema has been enabled for profile as I need the lookup data in audience builder. I’m not seeing the data from lookup dataset in my customer profile as expected for a lookup dataset. So, why does Adobe official documentation insist on having a non-person identifier as the primary identity of a lookup schema? Are there any hidden disadvantages? If yes, are they mentioned in any Adobe docs?

Best answer by Devyendar

Lets first understand the profile and lookup datasets and their intent.

  1. Profile datasets (person-centric, merged into the Unified Profile store and viewable in Profile Viewer), and

  2. Lookup / relationship (“dimension”) datasets (reference entities used at segmentation time or journey runtime, not materialized into the person profile record you browse in the UI).

Adobe’s Profile store is not a relational store. Adobe supports “multi-entity segmentation” by linking small “dimension entities” (lookup entities) to the primary person entity via relationships, but that doesn’t mean the lookup columns get copied onto the person profile and shown in Profile Viewer. Even if the lookup dataset is profile-enabled, Profile is not a relational store, so you typically won’t see lookup attributes on the person profile.

Adobe recommends using a non-person identifier as the primary identity of a lookup schema because lookup keys are intended to represent reference entities (productId, storeId, offerId, etc.), not people. If a person identifier (email/ECID/CRMID) is used as the primary identity on a lookup dataset, it can have unintended Identity Service/Profile side effects (identity graph pollution, unexpected merges, governance implications) and can be operationally fragile if duplicate keys occur.

If the dataset is truly person enrichment (additional CRM/profile attributes), the recommended pattern is to ingest it as an XDM Individual Profile dataset (profile schema) rather than a lookup entity, so the attributes become part of the unified profile and can be viewed/used normally.

 

2 replies

A
amruta1412
Level 2
February 9, 2026

​@An2_stine Lookup dataset fields will not appear automatically in the unified customer profile store.Look up data lives separately  and can be queries via query service or can be used in audience condition.

 

Refer to this old community discussion  

 

    A
    An2_stineAuthor
    Level 2
    February 9, 2026

    Yes, I’m not seeing lookup fields in my profile. But, I have kept a person identifier as my primary identity in lookup schema. AEP docs says not to use a person identifier as primary identity. So, are there any hidden issues with my implementation?

    bjoern__koth
    Community Advisor and Adobe Champion
    bjoern__kothCommunity Advisor and Adobe Champion
    Community Advisor and Adobe Champion
    February 9, 2026

    @bjoern__koth Lookup data is typically used for non-person data like additional product data in a separate datasets enrich available data from an Experience Event based dataset.

    What you are probably trying to achieve is uploading additional profile information like additional CRM data which then only needs a profile enabled dataset that is based upon the Profile schema. The profile service will do the stitching to your other profile data for you:

    Cheers from Switzerland!
      Devyendar
      DevyendarAccepted solution
      Level 6
      February 10, 2026

      Lets first understand the profile and lookup datasets and their intent.

      1. Profile datasets (person-centric, merged into the Unified Profile store and viewable in Profile Viewer), and

      2. Lookup / relationship (“dimension”) datasets (reference entities used at segmentation time or journey runtime, not materialized into the person profile record you browse in the UI).

      Adobe’s Profile store is not a relational store. Adobe supports “multi-entity segmentation” by linking small “dimension entities” (lookup entities) to the primary person entity via relationships, but that doesn’t mean the lookup columns get copied onto the person profile and shown in Profile Viewer. Even if the lookup dataset is profile-enabled, Profile is not a relational store, so you typically won’t see lookup attributes on the person profile.

      Adobe recommends using a non-person identifier as the primary identity of a lookup schema because lookup keys are intended to represent reference entities (productId, storeId, offerId, etc.), not people. If a person identifier (email/ECID/CRMID) is used as the primary identity on a lookup dataset, it can have unintended Identity Service/Profile side effects (identity graph pollution, unexpected merges, governance implications) and can be operationally fragile if duplicate keys occur.

      If the dataset is truly person enrichment (additional CRM/profile attributes), the recommended pattern is to ingest it as an XDM Individual Profile dataset (profile schema) rather than a lookup entity, so the attributes become part of the unified profile and can be viewed/used normally.

       

        A
        An2_stineAuthor
        Level 2
        February 10, 2026

        ​@Devyendar, that made it very clear. Is there an official Adobe documentation mentioning these side effects mentioned? Or, is there a way to test this in sandbox?

        Devyendar
        Devyendar
        Level 6
        February 13, 2026

        ​@An2_stine there is no specific documentation on the side effects it is mostly with the practitioner knowledge. Here is Adobe’s documentation on setting up Lookup datasets, make tweaks to it with the approach you want to test
        https://experienceleague.adobe.com/en/docs/journey-optimizer/using/data-management/lookup-aep-data

        If this information is helpful, please mark my response as Correct Answer to help other community members find helpful information.

          Terms & ConditionsAccessibility statement

          Loading footer...