Data Mapping / Field Mapping
Deciding which field on their side becomes which field on yours, so 'MailingStreet' lands in 'address.street' and nothing quietly vanishes.
See it
What it is
Two systems designed by different people never agree on names. Field mapping is the translation table between them: their 'MailingStreet' becomes your 'address.street', their 'Status__c' of 'CLSD' becomes your 'closed'. It covers three jobs at once: matching names, coercing types (their date string to your ISO 8601 timestamp), and translating values (their picklist to your enum).
You want one any time data crosses a border: CSV imports, CRM syncs, iPaaS connectors, migrating off an old database. Keep the mapping as data, an array of rules or a config table, rather than a wall of if-else code. Then a non-engineer can fix a mapping without a deploy, and you can show the user a mapping screen instead of asking them to rename their spreadsheet columns.
Gotcha: the easy fields are not the problem. The problem is fields with no counterpart. One side has a single 'name' string, the other wants first and last. One side allows null where yours requires a value. Decide upfront what happens to unmapped source fields: drop them, park them in a catch-all JSON column, or fail loudly. Silent drops are the bug you discover three months and forty thousand records later.
Ask AI for it
Build a configurable field-mapping layer between an incoming payload and my internal schema. Represent the mapping as data, not code: an array of rules with sourcePath, targetPath, an optional transform (trim, parse date to ISO 8601, split full name, look up a value in an enum table), and a required flag. Write a mapper that walks the rules, collects every per-field error instead of throwing on the first one, and returns { data, errors, unmapped }. Include a worked example mapping a Salesforce-style contact (FirstName, LastName, Email, MailingStreet, Status__c) onto { firstName, lastName, email, address: { street }, status } with a value map for the status picklist.