Pre-populate Forms 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 forms. It allows the transaction to be associated with the recipient's constituent record in the Encompass database without authenticating the user.

• 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 users click on the link, they get redirected to the Form, and their profile data will be pre-populated. The user is not required to enter a username or password to pre-populate the data. The system identifies the user through the link that is clicked and does a light authentication, meaning the user logged in behind the scenes to the specific Form, but if they attempt to leave that Form, they will be logged out. Encompass authenticate the member via the &authkey= link from their email.

NOTE: If an admin arrives at the site via a pre-populated link, pre-populate will not be activated for the transaction due to security purposes. If an admin arrives at the site via an edit registration link for viewing or editing for security reasons, their email field will not be displayed.

When a user clicks the link, their information is populated, and a message is displayed. This messaging is a verbiage item, and the admin can change it.

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 cannot 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 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 is not 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 pre-populate member data when the recipients click on them to come to the site. This allows data population setting to enable on a per form basis when adding a new form, event, donation, or membership campaign in Encompass. You can also enable this feature 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 can 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.

You can apply the Pre-populating the profile data from a return link setting 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, 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 log in.
• 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 log in.
• 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 log in.
• 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 pop-up box 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 log in (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 role, the user is redirected to the homepage.
• If the user does not confirm identity and chooses to start a new form, the audience settings apply, and the user is prompted to log in.

Identity Checkpoint

• There is no login prompt when accessing Form, and the Identity Checkpoint 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.

The admin can exclude some fields from pre-populating through a setting that is added for each profile field. This setting is called Allow data population on return linked forms and it's enabled by default.

To set the field to NOT pre-populate, the admin must uncheck the option. Administrators may want to set the email address field to NOT pre-populate, mainly 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, 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, you can not set instance fields to pre-populate.

 

Including the Link in an Email

When setting up an email (with a properly formatted link), the administrator can include the Form, Event, Donation, or Membership Campaign link.

1. Using the Hyperlink Manager - 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 Hyperlink Manager in the text editor toolbar. If you try to paste the link in the email without using the hyperlink manager 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 - You can also add the links using the Dynamic Content listings for Events.
   
3. Buttons and images - add the URL to the properties for buttons and images.

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 URLs that the admin has added something at the end of the URL string, such as appeal codes or designation IDs.

Link Expiration

The default link expiration duration is 7 days. (The maximum number of days you can 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 No Change or Data Changed status.

Data updated by the admin via this review process would be tracked in the Encompass 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 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, they would not have access to the event form if the email is forwarded on to a student.
• 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.
• 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 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, members 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 URLs that the admin has added 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.
• The data values are pre-populated on all steps if the option to pre-populate is enabled on a multi-step form.
• 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 can edit the registration.
• If a user forwards an email with auth key links, the new recipient will get the same links and access 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