Skip to main content
SahuSa1
SahuSa1
Level 3
March 20, 2026
Question

Pattern Field Property in AEP Schema

  • March 20, 2026
  • 1 reply
  • 53 views

Hi Adobe Community, Greetings!

 

Until early Feb or Feb end, I was able to see the pattern field property available for string fields in AEP and could freely test the regex pattern to filter out records which were invalid. For the use case, we wanted to filter out invalid Identity values and we could do the testing.

 

But until recently, Adobe has pushed an update it seems where the pattern field property is only available if dataset is not created from the schema. So to test the regex pattern you need to create schema → add pattern → create dataset → Ingest data to test if regex pattern is working or not.

 

Incase the pattern fails, then you need to delete the dataset → update regex pattern in the schema → create dataset → ingest data → and test again. 

 

So, I feel this is not very developer friendly. When I inquired this with adobe support, I got to know the reason why this change was made is, now Pattern is considered as a breaking change. I feel its not, as we can control the error threshold so that the whole batch does not fail even when multiple rows are rejected. 

 

What does the community think on this? Is Pattern really a breaking change?

 

Thanks,

Sambit

1 reply

AmitVishwakarma
Community Advisor
AmitVishwakarmaCommunity Advisor
Community Advisor
March 21, 2026

Hi ​@SahuSa1 

Your observation is right: pattern is now treated as a breaking‑change constraint in AEP once a schema has any dataset attached. Why pattern is considered breaking

Changing a pattern after you've already ingested data can make previously valid values invalid, and can break downstream services that depend on the old contract, so the UI now blocks editing it once a dataset exists. That's why you only see the pattern field fully editable before the dataset is created.

Practical workaround for testing regex

Use a throwaway test schema in a dev sandbox:

  • Create schema > add string field + pattern.
  • Create dataset > ingest sample data.
  • If the regex is wrong, delete dataset + schema and recreate.
  • Or validate identities upstream (source system or ETL/Data Prep), and only put the final, stable regex into AEP when you're confident.

So: from AEP's point of view, yes, changing pattern on an existing schema with datasets is a breaking change and is intentionally blocked. Use separate test schemas or upstream validation for regex experimentation.

 

Amit Vishwakarma - Adobe Commerce Champion 2025 | 16x Adobe certified | 4x Adobe SME
    SahuSa1
    SahuSa1Author
    Level 3
    March 24, 2026

    Thanks for your reply ​@AmitVishwakarma . I personally do think that this is not a developer friendly update and I think considering pattern as breaking change might be based on the fact that multiple schemas might be using the same field and it could affect them when changes made to one. 

     

    I wish there was a different approach for this, for example if this feature could be updated n number of times until the schema is enabled for profile. And once enabled, only then it would behave as per the new update. 

     

    Between, can we not just delete the dataset every time a regex did not work while testing and then the existing schema would allow to update the regex pattern? I mean, recreating schema again and again to validate a regex pattern doesn’t seem to be a developer friendly approach and would consume more time.

     

    Thanks,

    Sambit

      S
      santoshkr
      Level 2
      April 1, 2026

      Hi ​@SahuSa1 

       

      I completely agree that the constant 'Delete/Recreate' loop is a productivity killer.

      To answer your specific question: No, simply deleting the dataset is often not enough. Once a schema has been 'associated' with a dataset and used for ingestion, AEP’s Metadata Service often locks the schema structure to maintain a 'contract' history. Even after a dataset is deleted, the schema may remain in a 'locked' state for a period, or the system may still treat any change to the regex as a restriction of an existing contract.

      A more 'Developer-Friendly' approach to bypass this:

      1. The 'Draft Schema' Strategy: Instead of using your production-intent schema for regex testing, create a 'Sandbox' schema with a single field. Since you aren't enabling it for Profile or using it for real downstream flows, you can delete and recreate this 'light' schema in seconds using the Schema Registry API or the UI.
      2. Use Data Prep (Mapper) for Regex Testing: This is the best workaround. Instead of hardcoding the regex into the Schema, keep the Schema field as a standard string. Then, use AEP Data Prep (Mapping) during ingestion to apply a regex_match or if/else transformation.
        • This allows you to change the logic at the Ingestion/Mapping level without ever touching the Schema.
        • If the regex fails, you simply update the mapping for the next batch. No schema or dataset deletion is required.
      3. External Validation: Since AEP is a downstream consumer, the 'expert' recommendation is always to validate regex at the Source (e.g., using a Custom Code Data Element in Adobe Tags or a transformation in your ETL) before the data hits the AEP landing zone.

      Why Adobe considers it 'Breaking' even before Profile-enablement:
      Adobe's logic is that even if it's not in Profile, a Dataset might be used in Data Distiller or exported to Cloud Storage. If you tighten a regex, a scheduled export that worked yesterday might suddenly fail today. They chose 'Global Safety' over 'Developer Flexibility' in this recent update.

      Using the Data Prep mapping is likely your fastest path forward to test your patterns without the deletion headache!

       

      Please let me know if it works for you.

       

      Thanks,

      Santosh Kumar

      Santosh Kumar | AEP & CJA Expert
        Terms & ConditionsAccessibility statement

        Loading footer...