Pre-populate Form Data from an Email Link

This feature allows admins to send out email marketing communications that will pre-populate member data when recipients use links in the email to come back to a specific event, campaign or other form.  It allows the transaction to be associated with the recipient's constituent record in the Encompass database without requiring the user to be authenticated.

• User Flow
• Recipients who are not members of the community
• Setting Up The Form/Event/Donation/Membership Campaign
• Excluding Fields From Pre-populating
• Including the Link in an Email
• Link Expiration
• Method to Review Changes to Data in Forms from an Email Link
• Business Rules
• Quality Assurance Notes

User Flow

The user will receive an email with a link back to a form/event/campaign. When the link is selected and the user is taken to the form, their profile data will be pre-populated. The user is not required to enter a username or password in order for the data to be pre-populated, The system identifies the user through the link that is clicked and does a light authentication, meaning the user is logged in behind the scenes to the specific form but if they attempt to leave that form they will be logged out. The member is authenticated via the &authkey= link from their email.

NOTE:  Admins will NOT be able to fully utilize a pre-populate link. Admins will be taken to a window that indicates that as an admin you will not see your data pre-populated in the form.This page tells you that pre-population is enabled and functioning.  The admins are provided a "Continue" link that takes them to the linked form, with no information pre-populated and administrative options will still not be available.

When a user clicks on the link and is brought to the site, their information will be populated and a message will display with "Welcome User1, not User2....in a pop-up. This messaging is a verbiage item and can be changed by the admin.

If the user clicks to Continue, the member data will be pre-populated. The user is light authenticated, meaning that they are authenticated for this specific form - but if they attempt to go anywhere outside of this form they will not be considered authenticated to the site.

If the user selects that they are not the user, the form is displayed with no information pre-populated.

Recipients who are not members of the community

If you are not a current member of a community/group, you do not have the ability to access your information within that community. So, if you receive a pre-populated link in an email marketing email, you will be taken to the form but you will not be authenticated or have your data show up. The same thing goes for billing notification emails with pre-populated links to update your credit card information. This behavior is the same in sealed and un-sealed sub-communities.  For more information see Quality Assurance Notes - Pre-populate Testing.

NOTE: In Email Marketing, the pre-populate key will still be appended in the query string, even if the email recipient isn’t a member of that community. The check that determines whether or not they belong to the community is being done at the form level.

 

 

Setting Up The Form/Event/Donation/Membership Campaign

An administrator can enable links in an email to be set to pre-populate member data when the recipients click on them to come to the site. This Allow data population setting is enabled on a per form basis when adding a new form, event, donation or membership campaign in Encompass. This feature can also be enabled on existing forms, events, donations and membership campaigns.  The default for pre-populate member data at the form level is Off. By enabling this option, the admin will be able to include a link to this form in an email that will pre-populate profile fields when a user clicks on the link. This only applies to profile fields, so when creating the form the admin needs to ensure they are using profile fields if they want the pre-population to work.

The Pre-populating the profile data from a return link setting can be applied with all of the audience settings (Everyone, Logged In and Role). The behaviors for each audience setting is as follows:

Everyone - Ask unregistered users to create a Non-member account before continuing

• The user is not prompted to login.
• If the user does not confirm identity and chooses to start a new form, then the audience settings apply and the user is prompted to create a non-member account.

Everyone - Allow registered users direct access

• The user is not prompted to login.
• If the user does not confirm identity and chooses to start a new form, then the audience settings apply and the user is given direct access to the form.

Logged in

• The user is not prompted to login.
• If the user does not confirm identity and chooses to start a new form, then the audience settings apply and the user is prompted to log in.

Role

• If the user falls into the appropriate role, the user is not prompted to login.
• If the user does not meet the role, the behavior is the same as if a regular logged in member tried to follow the link. You never get the interstitial pop-up because you don’t get to the page (and you have to get to the page first before the page attempts to recognize you)
  
  • If the user clicks on an Events/Memberships/Donations Center link and does not fall into the role, the user is prompted to login (to see if the user meets the role). If the user does not meet the role, the user is redirected to the homepage.
  • If the user clicks on an Events/Memberships/Donations Center link and does not fall into the roll, the user is redirected to the homepage.
• If the user does not confirm identity and chooses to start a new form, then the audience settings apply and the user is prompted to log in

Identity Checkpoint

• No login prompt when accessing form. And ICP pop-up isn't triggered when the first step is submitted.
• If the user does not confirm identity and chooses to start a new form, then the audience settings apply and the ICP pop-up appears after I submit the first step.

Excluding Fields From Pre-populating

The admin will have the ability to exclude some fields from being pre-populated through a setting that has been added for each profile field. This setting is called Allow data population on return linked forms and will be enabled by default.

To set the field to NOT pre-populate, the admin needs to uncheck the option. Administrators may want to set the email address field to NOT pre-populate, especially if this field is used as the username for the site.

• On the admin view of the form, event, donation or membership campaign, click to edit the field.
• Check the Show Advanced Options checkbox.
• Select the option to Allow data population on return linked forms.
• Click Next to save your changes.

When the Allow data population is set to "off" for a profile field on one form, it will be set to "off" across the site. For example, if Event1 and Event2 both use the email address field on the form, and the admin disables the pre-population setting on Event1 it will also be disabled on Event2.

The following list of fields will be excluded from pre-population at the system level:

• File Upload Fields
• Username
• Password
• MUID
• Social Security Number
• date_added
• email_format
• email_kicked_back
• email_rate
• email_receive_comm
• email_receive_member
• email_receive_notes
• email_receive_updates
• em_site_opt_out
• facebook_id
• has_class_notes
• has_read_terms
• imod_const_id
• imod_sys_is_privacy_protected
• is_deceased
• is_deleted
• is_directory_hidden
• is_disabled
• is_email_valid
• is_hidden
• is_internal_account
• is_locked
• is_lost
• is_nonmember
• is_privacy_protected
• is_sanitized
• is_trigger
• is_verified
• last_emailed
• last_updated
• last_updated_by
• linked_in_coregistration_id
• member_id
• mentor_enabled
• resume_enabled
• role_chain
• virtual_pattern
• webcard_enabled

In addition, instance fields will not have the ability to be set to pre-populate.

 

Including the Link in an Email

When setting up an email, the administrator will be able to include the link to the form, event, donations or membership campaign when the admin has a properly formatted link:

1. Using the Link icon -  The admin does not need to include anything special in the URL or do anything special to make sure the pre-populate functionality works. You only need to enter the link using the link icon. If you try to paste the link in the email without using the link icon, it will not work.
   • Pre-populating data will work with Custom URLs such as custom URLs created in Content Properties, custom URLs created via Link Builder, Donation form URLs with dids (as well as bledit=1 and sort=1), appeal codes, tokenized hidden values and promo codes.
     

     NOTE:  When creating custom URLs via Link Builder, the system defaults the order of the query string parameters to sid=W&gid=X&pgid=Y&cid=Z. If an admin manually changes the ordering of these before initiating Link Builder to build the custom URL (e.g. moving the cid before the pgid), the custom URL will not be properly identified as a pre-population enabled link and will not work.

2. Dynamic Content - links for Events will automatically be set up for pre-populate if activated for the Event. You would use the Code Element for Events.
   

When building email content, there is no special UI button for "this is an authkey link"; instead, when sending an email, the sending application scrapes all the links in the email and matches them to a well know list of authkey links to find any matches.

Pre-populating the form with profile data will work with custom URLs or with any URLs that the admin has added something at the end of the URL string, for example, appeal codes or designation IDs.

Link Expiration

The default for expiration of the link is 7 days. (The maximum number of days that it could be set to is 180 days. Contact Customer Support to change the expiration time frame.)  

This means that after the expiration, the link would no longer pre-populate the constituent's data on the form. The link is still valid, but it will treat the user as a non-member, or if it is behind a login it will prompt the user to login.

 

Method to Review Changes to Data in Forms from an Email Link

Data updated by the email recipient via this process is tracked in the Submissions grid. Each submission will appear as a row in the new grid with a status of No Change or Data Changed.

The Current Value will display the value that is currently in the database. This is not necessarily the new value that was entered by the user. If a field was changed by another source between the time that the user made the change and the time the admin reviewed the change it will show the current value in the database. This is to handle changes being made through the Data Change history grid by an admin. If the admin makes changes in the data change history grid first, then the current value in the Review Grid would be updated.

Data updated by the admin via this review process would be tracked in the iModules Data Change History grid.

The changes to the profile data that are made on the form are committed to the database when the form is submitted. The review process allows the admin to confirm the changes or revert the changes back to the previous values.

 

Business Rules

• Main Roles - The roles that are set up on the form will be maintained when the user comes to the form through the link. For example, if the event is only for alumni and you have the roles set up correctly, if the email is forwarded on to a student they would not have access to the event form.
• The auto-populate option on the form will override the setting to allow only logged in users access to the form. This means if the admin selects the 'logged in' option for the audience and then enables the 'Pre-populate member data on the form", the user will not be required to login when clicking on the link to enter the site. When they are taken to the form they will receive the "welcome' message on the pop-up and will be able to continue without logging in.
• Interaction with Identity Checkpoint - When the user comes to the form through the link and they say "yes" they are the person specified, then Identity Checkpoint is not engaged. If user says they are NOT the person specified, then Identity Checkpoint (if enabled) is engaged.
• This functionality is not supported for legacy campaigns and legacy events.
• Preview emails will not support the pre-populate form data functionality with the first release.
• Any roles applied to the form through content properties will currently cause the authkey to be dropped from the query string once the login redirect occurs.
• Data changed on the form through the pre-populated link process will be tracked in the Data Change History grid. It is tracked as a profile update and the member is identified as the editor. It is also tracked through the Form Submissions grid.
  • Data updated by the admin via this review process would be tracked in the iModules Data Change History grid.
• If an Admin sets a profile field to not pre-populate on the form, then the field will not be displayed on the pre-populated form when the user is auth keyed into the form.

If the following conditions are met:

• • The "Pre-populate user profile data from return link" option is enabled on the form. (Content Properties)
  • The member is authenticated to the form via the link from their email. ( &authkey)
  • The "Allow data population on return linked forms" for a profile field is disabled.

then we Do Not render the field on the form or the form data token.

For role purposes, the user will be in any roles associated with the value in the database.

If a profile field is marked to NOT pre-populate, a warning message will be displayed at the top of the form stating that some profile fields are set to not pre-populate and will not show up on a pre-populated form.

• If an Admin sets a profile field to not pre-populate on the form, the field will be displayed if the user clicks on the "No, I'm not User1" message on the pop-up displayed to the user coming in through the email link. The user will not be authenticated via the authkey and the data will not be pre-populated.

If the following conditions are met,

• • The "Pre-populate user profile data from return link" option is enabled on the form. (Content Properties)
  • The member is not authenticated to the form via the link from their email. ( &authkey)
  • The "Allow data population on return linked forms" for a profile field is disabled.

then we DO render the field on the form and in the the form data token.

• If the field that is set to not pre-populate drives a role, the member would be placed in the appropriate role based on the value in the database.     
  
  • For Example: Class year is set to not pre-populate. When a member comes from the link in an email to a form that is enabled to pre-populate, class year will not be displayed. However, if class year drives a role that member will still be associated with the role based on the value in the database for class year.
    
    
• If a profile field that is relied on for a feature to work is set to not pre-populate then that field will not be displayed and those features will not work.
• Pre-populating the form with member data will work with custom URLs or with any URLs that the admin has added something to the end of the query string. This includes custom URLs created via content properties, custom URLs created via link builder, donation form URLs with dids (as well as bledit=1 and sort=1), appeal codes, tokenized hidden values and promo codes.

• Pre-populate option is hidden for profile instance fields.
• If the "Pre-populate user profile data" option is disabled on the form after the email is sent out, when the form is accessed through the link in the email the form is not pre-populated.
• In order for the pre-population (auth key) to work, the form has to be created in the same community as the email is sent. If you create an email in GID 5 and link to a form in GID 1, the link won't get the auth key.
• If the option to pre-populate is enabled on a multi-step form, the data values are pre-populated on all steps.
• Pre-population of the form data works with the edit registration functionality. If edit registration is on and the user is auth keyed in they will see their previous registration and will have the ability to edit the registration.
•  If a user forwards an email with auth key links, the new recipient will get the same links and will be accessing the form with their auth key. There is a possibility that the new recipient could update User1’s info (if they select to continue as User1). 
  

Quality Assurance Notes

(for even more details on how the Pre-populate Form Data from an Email Link will behave in your system!)

Pre-populate Testing