AEP Schema Design: Primary Identity vs Field Group Required Constraints

A question that comes up frequently when working with shared Field Groups: does marking a field as Primary Identity in one schema affect other schemas using the same Field Group? And how do you handle required fields that don't apply to your specific dataset?

These are two separate concerns that get conflated because they both live in the schema layer.

Primary Identity is Schema-Local

Marking a field as Primary Identity is a local decision scoped entirely to that schema. It has zero upstream impact on the Field Group definition or any other schema using it.

Identity designation and field group constraints are completely separate layers in AEP's Schema Registry:
- Field Group = shared blueprint with structural rules (required, data type)
- Schema = local implementation including identity role assignments

Field A stays required everywhere because that constraint is defined at the Field Group level. Field B being Primary Identity in Schema X doesn't change anything for other schemas.

Handling Required Fields That Don't Apply to Your Dataset

Three options depending on your situation:

Option 1: Ingest a placeholder value — most common in multi-source architectures. Satisfies validation without corrupting your actual data.

Option 2: Remove the required constraint from the Field Group — right long-term fix if the constraint shouldn't be globally required. Coordinate with other teams since this affects all schemas using that group.

Option 3: Create a separate custom Field Group — most governance overhead but gives you a clean schema scoped to your use case without modifying shared resources.

Before Deciding — Check Your Monitoring Dashboard

Monitoring > Datasets > [your dataset] > Failed Batches will show exactly which records are failing validation and at what volume. Scope the impact first, then choose your approach.

Hope this helps anyone working through multi-schema, multi-source AEP implementations!