Map Revup fields to integration fields
Match participant fields to compatible destination properties without misrepresenting consent.
## Match the meaning of each fieldIn the provider setup, match the Revup email field to email and review each remaining field individually. Use compatible types: text to text, dates to dates, numbers to numbers, and known choices to allowed provider values.Do not reuse a destination field with a different meaning merely because its type accepts the value. Use stable field names across promotions when the information is genuinely the same.Consent mappings require special care. Rules acceptance, form submission, email consent, and SMS consent are separate facts. Send only the status the participant actually provided.After any field change, submit a test and inspect the destination. Existing destination records may keep earlier values depending on provider behavior.## Understand consent filteringEmail Consent and SMS Consent control their respective channels. When a consent field is present and unchecked, Revup removes that channel's mapped identifier before sending. If the provider then lacks a required identifier, delivery can be skipped. If no consent field is present, the general integration mapping does not treat that absence as an automatic opt-out. Attentive is stricter and requires explicit SMS consent.Do not rely on missing fields to enforce your marketing policy. Collect the appropriate permission and test both checked and unchecked submissions. Verification codes prove access to a destination; they are not marketing consent.System fields and primary participant identifiers are distinct from additional contact fields. Not every form control is mappable: layout, CAPTCHA, payment, signature, and consent controls have separate behavior. A participant login link is sensitive; map it only when your receiving workflow needs it and restrict access there.