Metadata Field Change Breaks a Live Embed
Your organization has used Widen for six years. A custom metadata field called campaign_code was created as a plain text field and is referenced by 14 public embed links that render asset metadata into partner microsites via the Widen API. Marketing now wants campaign_code converted to a controlled-vocabulary (dropdown) field with 30 fixed values so reports group cleanly. There are 240,000 assets; roughly 38,000 have values in campaign_code, and an audit shows about 900 of those values do not match any of the 30 new allowed values. Two partners have contractual SLAs requiring their embeds to keep working. The change request is due Friday.
1. What is the core risk in converting the field type in place, and how would you sequence the work to protect the partner embeds?
Read the worked answer
Core risk: changing a field's type and restricting its allowed values is a schema change that can invalidate existing data and break anything reading that field. The 900 non-conforming values will either be rejected, blanked, or left in an inconsistent state, and the 14 API-driven embeds read whatever the field returns. A partner embed that suddenly gets a null or an unexpected value can render blank or error, which is an SLA breach.
Sequencing:
- Inventory first. Pull every asset where
campaign_codeis populated and export the distinct values. Classify the 900 outliers into mappable (typo/variant of an allowed value) and genuinely unmappable. - Decide the mapping before touching the schema. Get Marketing to sign off on a value-mapping table. Anything unmappable needs a decision: remap, park in a transitional free-text field, or leave blank.
- Create the new field rather than mutating the old one. Add
campaign_code_v2as the controlled-vocabulary field, backfill it from the mapping, and validate counts match. - Coordinate with partners. Give the two SLA partners a dated change window and confirm how their integration consumes the field.
- Cut over, then retire. Point embeds/reports at the new field, verify, then deprecate the old field once nothing references it.
Never convert in place on a Friday with live consumers and 900 unresolved values.
2. Marketing insists on doing the conversion directly on the existing field to avoid rework. How do you respond, and what evidence would you bring?
Read the worked answer
Push back with evidence, not opinion. Bring:
- The outlier count and a sample: 900 values that match none of the 30 allowed options, with examples, so the risk is concrete rather than abstract.
- The consumer list: 14 embeds, two under contractual SLA. Show that these read the field via the API and will surface whatever the field returns.
- A dry-run result: run the mapping against a copy or a report and show how many assets would end up blank or mis-grouped if the field is converted without remediation.
Then offer the compromise that removes their real objection (rework): the new-field approach is less rework because the backfill is scripted and reversible, whereas an in-place conversion that corrupts 900 values creates cleanup work with no rollback. Frame the new field as a staged migration with a single cutover, not duplicated effort. If they still want in-place, require a written acceptance of the SLA risk and a rollback plan - and confirm the platform actually supports reverting the field type, because many do not cleanly.