Pattern Field Property in AEP Schema

Question

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

AmitVishwakarma · Answer

Hi ​@SahuSa1Your 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 breakingIn XDM, pattern is a validation constraint on a string field (like min/max length, format, etc.) > See "pattern" for string fields:https://experienceleague.adobe.com/en/docs/experience-platform/xdm/tutorials/custom-fields-apiAEP's schema evolution rules say that once a schema is tied to a dataset (and data or Profile is involved), only non‑destructive ("additive") changes are allowed. Anything that tightens what values are valid is treated as a breaking change. > Non‑destructive only after dataset/profile use:https://experienceleague.adobe.com/en/docs/experience-platform/xdm/api/getting-started> "You can't remove or restrict previously supported values" once data exists:https://experienceleague.adobe.com/en/docs/platform-learn/tutorials/schemas/update-schemasChanging 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 regexUse 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.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded