This article provides a general definition of what field mapping is and why it needs to be done.
Field mapping serves two functions:
- It tells the Engagement Rx system which member attributes the client is using (when configuring SAML SSO or uploading an eligibility file)
- It aligns the Engagement Rx system field names with the field names that the client is using (sometimes they are the same, sometimes they differ)
Why and when is mapping fields necessary?
When a client sets user eligibility or SAML SSO as an authentication type, they need to submit data about their members to the Engagement Rx system. Different data-types are categorized under field names. For example, a client might have all the first names of their members under the field name "First Name." We call these data-types "member attributes." (Other member attributes include last name, birthday, and email address, as examples. For the complete list of member attributes, values, and related details, see this article.)
Mapping fields tells the Engagement Rx system which member attributes the client is including for their members. In some cases, the field name that the client uses differs from the field name that the Engagement Rx system uses. This is fine because when you map fields, the Engagement Rx system field name is matched with the field name the client is using. For instance, if the client has a file which includes the member attribute "Birthday," they can map the field to the Engagement Rx system field name, which is "Birthdate." Once the field is mapped, the Engagement Rx system knows that inside the file, the column header "Birthday" means "Birthdate."
Here is an example of a field mapping that contains some field names that are the same, and some fields that have slight differences. Note that "System Name" refers to the Engagement Rx naming convention and "Assertion Attribute Name" refers to the client naming convention:
In this example, you can see that the client has mapped four fields. The Engagement Rx system now knows that all four fields are included as member attributes, and that:
- "Email" is equivalent to "e-mail"
- "Gender" is equivalent to "user_gender" and that this field uses an old data format (indicated in the Data Transformation column)
- "Key Field" is equivalent to "user_ID"
- "LastName" is the same in both systems
To see information about Data Transformation and/or specific values for the Gender field, go to this article.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article