Skip to main content
A
Ankith Menon
Level 2
May 12, 2026
Solved

Need some information on how Primary Identity Declaration at Field Group level works and how it stays consistent across Schemas

  • May 12, 2026
  • 2 replies
  • 38 views

Hi everyone,

I’m working on a schema configuration and have run into a question regarding field group inheritance and Profile enablement.

The Setup:

  • I have a Custom Field Group containing Field A and Field B.

  • Field A was marked as "Required" at the Global Field Group level (it appears as mandatory in every schema it is added to).

  • In my specific schema, I have designated Field B as the Primary Identity.

  • In most other schemas across our organization, Field A is usually the Primary Identity.

The Question: If I enable this schema for Profile and begin ingesting data, will my local configuration (marking Field B as Primary) have any "upstream" impact on the Field Group definition? Specifically, will Field B suddenly become a required field for other schemas using this same Field Group?

Also, since Field A is "Required" at the group level but is NOT my primary identity in this specific use case, is there a recommended way to handle this during ingestion if Field A values aren't the focus of this specific dataset?

Any insights on how AEP handles this validation would be greatly appreciated!

Best answer by akhil_merupula

Hi ​@Ankith Menon ,

Ganesh is correct on the first part marking Field B as Primary Identity in your schema is a local schema-level decision and has zero upstream impact on the field group definition or other schemas using it. Identity designation and field group constraints are completely separate concerns in AEM’s Schema Registry.
 

To add more on your second question about handling Field A being required at the group level when it’s not your focus this is the more practical challenge and there are a few patterns teams use.

 

The cleanest approach if Field A values genuinely don’t exist in your dataset is to ingest a placeholder or default value for Field A specifically to satisfy the schema validation constraint. This is common in multi-source data architectures where a shared field group has a required field that only some data sources naturally produce. The placeholder keeps ingestion clean without corrupting your actual data.

 

If Field A is truly irrelevant to your use case and you have the ability to modify the field group, consider whether the required constraint on Field A at the global level is actually intentional or a historical decision that hasn’t been revisited. If it was added for a specific schema’s needs and shouldn’t be globally required, removing the required constraint from the field group definition is the right long-term fix just be aware this affects all schemas using that field group.

 

The third option if you can’t modify the field group and don’t want placeholder values is to create a separate custom field group that contains only Field B without the Field A required constraint, and use that in your schema instead of the shared group. More maintenance overhead but gives you clean schema governance for your specific use case.

 

For ingestion validation errors you’ll see them surface in the AEP Monitoring dashboard under dataset ingestion filtering by failed batches will show you exactly which records are failing Field A validation so you can scope the impact before deciding which approach to take.

2 replies

G
GaneshKalamadug
Level 2
May 12, 2026

No, your local schema configuration (making Field B the Primary Identity) will NOT affect the Field Group globally.
Field B will NOT become required in other schemas just because you used it as a primary identity here.
Field A remains required everywhere because that constraint is defined in the field group itself.
For ingestion: you must still provide a value for Field A, even if it is not your primary identity.

    A
    akhil_merupulaAccepted solution
    Level 3
    May 12, 2026

    Hi ​@Ankith Menon ,

    Ganesh is correct on the first part marking Field B as Primary Identity in your schema is a local schema-level decision and has zero upstream impact on the field group definition or other schemas using it. Identity designation and field group constraints are completely separate concerns in AEM’s Schema Registry.
     

    To add more on your second question about handling Field A being required at the group level when it’s not your focus this is the more practical challenge and there are a few patterns teams use.

     

    The cleanest approach if Field A values genuinely don’t exist in your dataset is to ingest a placeholder or default value for Field A specifically to satisfy the schema validation constraint. This is common in multi-source data architectures where a shared field group has a required field that only some data sources naturally produce. The placeholder keeps ingestion clean without corrupting your actual data.

     

    If Field A is truly irrelevant to your use case and you have the ability to modify the field group, consider whether the required constraint on Field A at the global level is actually intentional or a historical decision that hasn’t been revisited. If it was added for a specific schema’s needs and shouldn’t be globally required, removing the required constraint from the field group definition is the right long-term fix just be aware this affects all schemas using that field group.

     

    The third option if you can’t modify the field group and don’t want placeholder values is to create a separate custom field group that contains only Field B without the Field A required constraint, and use that in your schema instead of the shared group. More maintenance overhead but gives you clean schema governance for your specific use case.

     

    For ingestion validation errors you’ll see them surface in the AEP Monitoring dashboard under dataset ingestion filtering by failed batches will show you exactly which records are failing Field A validation so you can scope the impact before deciding which approach to take.

      Terms & ConditionsAccessibility statement

      Loading footer...