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
  • 3 replies
  • 92 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.

 

3 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.

          A
          An2_stineAuthor
          Level 2
          March 30, 2026

          Here is the response from Adobe on the cons of having a person identifier as primary identity in a lookup schema, hope this helps all - 
          “Technically it is supported to use a person identity as the primary identifier on a lookup schema. Platform doesn’t block it and Identity Service treats all person identities the same regardless of primary/non‑primary or lookup vs profile schema. “even a person identity if defined as primary has no significance in Identity graph” on its own.

          Although, It is not recommended because:

          Lookup schemas use a non‑people (relationship) identity as the primary identifier and Profile / Experience Event schemas use people identities (email, CRMID, ECID, etc.).

          Using the wrong identity type on lookup schemas is explicitly called out as a health‑check issue because it can inflate profile counts and make the dataset ineligible or unsafe for lookup-style use cases in the future.
          ---------------------------

          Practical impacts if you do it anyway:

          If you mark a person identifier as the primary identity of a lookup schema:

          --> Identity resolution / merging

          That lookup table will participate in the identity graph as if it were a person profile, which can cause unwanted merges (“graph collapse”) when the same identifier appears in real person profiles. You lose the clean separation between “context data” (products, stores, plans) and “people.”

          --> Profile counts & limits

          Those lookup rows can count as profiles, inflating your license‑relevant profile count and complicating sizing/guardrails.

          --> Downstream activation

          Data modeled as a person identity can be pulled into segments and activations as if it were an individual, which is usually not what you want for lookup entities.
          Some features (multi‑entity segmentation, AJO local lookups, etc.) are designed with the assumption that lookup schemas are non‑person records keyed by non‑people identifiers.

          --> Constraints / relationships

          You cannot use the primary identity of a schema as the source of a relationship descriptor, relationships are designed to link a person to a non‑person entity.

          So if your lookup schema’s primary ID is a person identity, that field cannot also be the relationship key from another schema, which limits how you can model multi‑entity joins.

          --> Compliance & privacy

          Lookup tables are often treated as “non‑PII context.” If they carry person identities as their primary key, the data is now customer‑identifiable and should be governed as such. That can complicate retention, subject‑access/delete workflows, and internal data‑minimization reviews.

          What you’ve tested will “work” now, but it’s fragile, it contradicts the documented model and is likely to create issues with profile counts, merging, and future product behavior.          ”

          Terms & ConditionsAccessibility statement

          Loading footer...