Loyalty Programs: Data classification tags not updating after schema modifications

CRM Adobe Experience Cloud
, , , , , , ,
1

We recently updated our loyalty program member profile schema to add new fields for tier benefits and reward redemption history. After deploying the schema changes to production, we noticed that the data classification tags on these new fields are not being applied correctly, and some existing fields have lost their classification tags entirely.

This is causing access control issues-users who shouldn’t have access to sensitive fields like member_ssn_last4 and payment_method_token are now able to view them because the C3 (No Identity Export) and C2 (No Export) labels are missing. Our compliance team is understandably concerned about this exposure.

When I check the schema in Data Governance, the new fields show as “unclassified” even though we specified classification tags in the schema update. The existing fields that lost their tags now show “inherited” classification, but when I drill down, there’s no parent field group providing those inherited tags.

How do data classification tags get updated after schema change management? Is there a manual step we’re missing, or should this be automatic when the schema is published?

2

I’ve applied dataset-level restrictions as suggested, which has locked down access for now. When I go to Data Governance > Labels to re-apply the classification tags, I can see the new fields, but some of the classification options are grayed out. Specifically, I can’t apply C3 (No Identity Export) to the new tier_benefits_detail field. Is there a prerequisite or field type requirement for certain classification labels? The field is defined as a string in the schema.

3

This is a critical security gap that needs immediate attention. Until you fix the classification tagging, you should implement temporary access restrictions at the dataset level. Go to Data Governance > Datasets and apply restrictive labels to the entire loyalty member dataset. This will block access for all users except data stewards until you can properly re-classify the individual fields. It’s a blunt instrument, but better than leaving sensitive fields exposed. Also, audit who accessed those sensitive fields between the schema update and now-you may need to report this as a potential data breach depending on what was accessed.

4

Your situation reveals three interconnected issues in how data classification tags interact with schema modifications. Let me provide a comprehensive solution:

Schema Change Management Process: The fundamental problem is that Adobe Experience Cloud’s data governance framework treats schema structure and data classification as separate concerns. When you modify a schema, the platform ensures structural integrity but does not automatically maintain governance label continuity. This is actually by design-it forces explicit governance review after schema changes, preventing accidental exposure of sensitive data.

Here’s the proper schema change workflow that preserves data classification:

  1. Pre-Change Documentation: Before modifying your schema, document all existing data classification tags. Export your current governance labels:
  • Navigate to Data Governance > Labels > Export
  • Save the label inventory as a reference
  • Note which fields have which labels (C1, C2, C3, etc.)
  1. Schema Modification Best Practice: Instead of directly modifying your production schema, create a development version:
  • Clone your existing “Loyalty Member Profile” schema
  • Name it “Loyalty Member Profile v2.0”
  • Add your new fields (tier_benefits_detail, reward_redemption_history)
  • Modify any existing field groups as needed
  1. Pre-Production Governance Classification: Before deploying to production, apply data classification tags to the new schema version:
  • Go to Data Governance > Labels
  • Select your v2.0 schema
  • Apply appropriate labels to all new fields
  • Verify existing fields retained their labels (they should, since you cloned)
  1. Validation and Testing: Use a test dataset to validate that access controls work correctly with the new schema:
  • Create a test dataset using the v2.0 schema
  • Ingest sample data
  • Test access with different user roles to verify governance enforcement
  • Confirm that C2 and C3 labeled fields are properly restricted
  1. Production Deployment: Only after validation, deploy the new schema to production:
  • Update your loyalty program dataset to use the v2.0 schema
  • Re-apply any dataset-level governance policies
  • Verify that data classification tags are active on all fields

Data Classification Tagging Restoration: For your immediate situation where labels have been lost, here’s the systematic restoration process:

  1. Identify Lost Labels: Compare your current schema against the governance label export you should have created (or recreate from compliance documentation). For your loyalty member schema, typical classifications should be:

Sensitive Identity Fields (C3 - No Identity Export):

  • member_ssn_last4
  • payment_method_token
  • government_id_number
  • date_of_birth (if used for identity verification)

Restricted Export Fields (C2 - No Export):

  • reward_balance
  • lifetime_value
  • credit_card_type
  • internal_risk_score

Marketing Restricted Fields (C1 - No Data Usage):

  • opt_out_flags
  • do_not_contact_indicators
  1. Re-apply Labels Systematically: Navigate to Data Governance > Labels > Field-Level Labels. For each field that lost its classification:
  • Select the field
  • Choose the appropriate governance label(s)
  • Add a note explaining why this label was re-applied: “Restored after schema update 2025-07-25”
  • Save and validate
  1. Address Grayed-Out Label Options: You mentioned C3 labels are unavailable for some fields. This happens when:

Issue: Field not in identity context Solution: For fields like tier_benefits_detail that contain identity-adjacent information:

  • If it truly contains identity data, move it to an identity field group
  • If it’s sensitive but not identity data, use C2 (No Export) instead
  • If it must stay in current location with C3, modify the field definition to include identity: true attribute

To modify field identity status:


Field: tier_benefits_detail
Type: String
Identity: true
Identity Namespace: LoyaltyMemberID

This marks the field as identity-related, enabling C3 classification.

  1. Field Group Level Classification: For efficiency, apply labels at the field group level when possible:
  • Navigate to Schemas > Field Groups
  • Select your custom loyalty field group
  • Apply governance labels at the group level
  • All fields within the group inherit these labels
  • Individual fields can have additional labels applied

This approach makes future schema updates easier-new fields added to a classified field group automatically inherit appropriate labels.

Access Control Enforcement: Even after re-applying classification tags, you need to verify access control enforcement:

  1. Merge Policy Configuration: Your merge policy must enforce field-level governance. Navigate to Profiles > Merge Policies > [Your Loyalty Policy]:

Settings to enable:


Governance Enforcement: Enabled
Field-Level Restrictions: Enabled
Label Priority: Respect most restrictive label
Unlabeled Field Behavior: Apply dataset-level label

Without these settings, classification tags are advisory only and won’t actually restrict access.

  1. Role-Based Access Control Alignment: Verify that user roles respect data governance labels. Navigate to Permissions > Roles:

For each role that accesses loyalty data, check:

  • “View Labeled Data” permission (should specify which labels they can view)
  • “Export Labeled Data” permission (should exclude C2/C3 labels for most roles)
  • “Identity Data Access” permission (required to view C3 labeled fields)

Example configuration for “Loyalty Program Manager” role:


View Labeled Data: C1, C2 (can view but not export restricted fields)
Export Labeled Data: None (cannot export any restricted data)
Identity Data Access: Denied (cannot view C3 identity fields)
  1. Dataset-Level Governance: While you’ve applied temporary dataset-level restrictions, configure permanent dataset governance:

Navigate to Datasets > Loyalty Member Profiles > Data Governance:

  • Enable “Governance Labels Enforcement”
  • Set “Unlabeled Field Default”: Apply C2 (conservative default)
  • Enable “Access Audit Logging”: Track all access to this dataset
  • Set “Label Conflict Resolution”: Most restrictive wins

This ensures that even if field-level labels are somehow lost again, the dataset-level policy provides baseline protection.

Audit and Compliance Response: Address the compliance team’s concerns about the exposure period:

  1. Access Audit: Run a comprehensive audit of who accessed sensitive fields during the exposure window:
  • Navigate to Data Governance > Audit Logs
  • Filter for: Dataset = “Loyalty Member Profiles”, Date Range = [schema update date] to [now]
  • Export all access events
  • Identify any access to member_ssn_last4 or payment_method_token fields
  1. Impact Assessment: For each unauthorized access event:
  • Determine what data was actually viewed or exported
  • Assess whether the user had legitimate business need (even without formal permission)
  • Document the scope of exposure (how many member records)
  1. Breach Notification Evaluation: Work with your legal/compliance team to determine if this constitutes a reportable breach:
  • Under GDPR: Likely yes if EU member data was exposed
  • Under CCPA: Possibly, depending on California resident exposure
  • Document the timeline: when exposure started, when discovered, when remediated
  1. Remediation Documentation: Create a formal incident report including:
  • Root cause: Schema modification process lacked governance label preservation
  • Exposure period: [specific dates/times]
  • Affected data: [specific fields and approximate record count]
  • Remediation actions taken: [list all steps from this solution]
  • Preventive measures: [new schema change process described above]

Preventive Measures for Future Schema Changes: Implement these processes to prevent recurrence:

  1. Schema Change Checklist: Create a mandatory checklist for all schema modifications: □ Export current governance labels

□ Document all C2 and C3 classified fields

□ Create new schema version (don’t modify in place)

□ Apply governance labels to new schema

□ Test in development environment

□ Validate access controls with test users

□ Document changes in governance log

□ Deploy to production

□ Verify labels active in production

□ Update role permissions if needed

  1. Automated Governance Validation: Set up monitoring to detect classification gaps:
  • Create a scheduled report that lists all fields without governance labels
  • Alert if any field in loyalty schema loses its classification
  • Weekly governance label audit comparing current state to baseline
  1. Schema Governance Training: Ensure all users with schema modification permissions understand:
  • Data classification requirements
  • Schema change workflow
  • How to apply and verify governance labels
  • Compliance implications of classification gaps
  1. Version Control Integration: If you use a version control system for schema definitions, include governance labels in the schema files:
{
  "field": "member_ssn_last4",
  "type": "string",
  "governanceLabels": ["C3", "I1"],
  "classificationReason": "Partial SSN is identity data"
}

This makes governance labels part of your schema definition, tracked in version control alongside structural changes.

By implementing this comprehensive schema change management process with integrated data classification tagging and access control enforcement, you’ll prevent future governance label loss while ensuring your loyalty program data remains properly protected according to your compliance requirements.

5

The issue with “inherited” classification tags showing but not actually being enforced suggests your field groups might have been modified incorrectly. When you update a schema, if you change the field group structure (adding or removing fields within a group), the governance labels applied at the field group level can become orphaned. Best practice is to create a new version of the field group rather than modifying the existing one, then update your schema to use the new field group version. This preserves the governance context.

6

Data classification tags don’t automatically carry over when you modify schemas. When you add new fields or modify existing field groups, you need to explicitly re-apply the classification labels through the Data Governance UI. The schema publishing process only validates that the schema structure is correct-it doesn’t apply or verify governance labels. Navigate to Data Governance > Labels and manually apply the appropriate tags to your new fields and re-apply them to any fields that lost their labels.

7

Also worth checking your merge policy settings. After schema modifications, if your merge policy isn’t configured to respect field-level governance labels, you might have classification tags applied but they’re not being enforced during data access. The merge policy needs to have “Governance Enforcement” enabled and should be set to respect field-level labels. This is a separate setting from the schema-level classification and often gets overlooked during schema updates.