Common people patterns
SharePoint Person column
Best when the field should resolve to a user, support profile data, and integrate with SharePoint permissions or people controls.
Text or email field
Best when the form historically saved a display name, email address, or notification target as text.
Role support list
Best when a dropdown selects from a managed list of roles, specialists, approvers, or notification recipients.
What to validate
- Does the app display a friendly name but save an email or claims value?
- Does the destination SharePoint field expect a person object or text?
- Are inactive users, external users, and service accounts represented correctly?
- Do role-based dropdowns use the right supporting list and filter?
Form Migrator behavior
The mapping step lets you preserve or override people-field handling. The generated app keeps SharePoint internal binding names while using user-facing labels where available.
Common questions
Why not always use a Person column?
A legacy form may have saved plain text or an email address, and changing that to a Person object can break reporting or old process assumptions.
Can role dropdowns show names but save emails?
Yes. The converter supports separate display labels and submitted values when the InfoPath package exposes both.
Do people fields need tenant testing?
Yes. Always test in the target tenant because user resolution and permissions depend on the real environment.