Instance fields:
- Pre-populate option is hidden for profile instance fields.
You shouldn't be able to reuse a profile instance field on a form – it should be a clone of the field.
- When adding a new field to a profile form, the default is to have it checked. Once I select instance field, this option goes away.
- Existing instance field doesn't display the pre-pop option.
Form setting:
- I turned an auto pop form off (unchecked the setting) after I had sent an email with the auth key. I accessed the form with the auth key in the url – data was not pre-populated and when submitted, it created a new member id and didn't tie any of the information back to the original member record.
Auth keys & sealed subs:
- I confirmed that auth key only happens for form links in the same community as the sending email. If you link to a form in gid1 in a gid5 email, the link won't get the auth key.
- I confirmed that auth keys are added in regular sealed subs and sealed subs with unique urls.
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 below.
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 leve
- Regression of auto pop:
- Sent an email with auth key link to a member of gid1 (only community that they belong to)
- Sent emails to that person in a sealed sub-community and a non-sealed sub-community using a custom list that had the same email address
- gid1 email:
- I was taken to form and was authenticated (tested with audience set to Everyone and then Logged In); pre-pop modal displayed; data pre-popped.
- I submitted the form without error and data changes were tied to the constituent’s record
- un-sealed sub email:
- Auth key was still included in query string
- With audience set to Everyone:
- I was taken to the form and was NOT authenticated; pre-pop modal did not display; data was not pre-popped
- I filled out form and created a new non-member record that wasn’t tied to the member in gid1 who has the same email address
- With audience set to Logged in:
- I hit the login page
- sealed sub email:
- With audience set to Everyone:
- I was taken to the form and was NOT authenticated; pre-pop modal did not display; data was not pre-popped
- I filled out form and created a new non-member record
- With audience set to Logged In:
- I hit the login page
Multi-step forms:
- Auth key does NOT get dropped on multi-step form
- Data values are populated on all steps
Interaction with Edit Event Registration: I registered for an RSVP event and purchased a commerce item via auth key and then...
- I accessed the form via the edit registration link: It showed my registration response and the number of commerce items purchased from the auth key registration. I then purchased another commerce item.
- I accessed the form via the auth key again. It showed my current registration status and the total number of commerce items purchased (included both auth key and edit reg purchases)
Payment Processors: This was also tested with a hosted processor.
Forwarding the email: 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 the original recipient's auth key. There is a possibility that the new recipient could update the original recipient’s info (if they select to continue as that member). BUT, if the system Forward to a Friend community content is added, it strips out the auth key and the links still work
Email address file: When linking to an auto populate enabled form in an email and using an email address file to build the recipient list, it’s recommended that a first and last name be included in the email address file.
Examples from an email address file scenario:
- Email address in the file existed for a member record: It matched it with that member record, so when accessing the form with the auth key, it populated the member info
- Email address in the file didn’t exist in db, and no FN or LN included in file: A nonmember record is created. There’s no info to pre-populate, so you end up with an empty form and the pop-up contains no data.
- Email address in the file didn’t exist in db, and FN and LN were included in the file: A nonmember record is created. Since the first name and last name were included in the email address file, the name info shows up on the pop-up and on the form.
Different types of constituents:
- Member: You get the pop-up and data populates on form.
- Non-member: You get the pop-up and data populates on form.
- Admin: You get the pop-up and data populates on form. You see the admin toolbar, but the links don’t go anywhere – you’re prompted to login.
- CMS admin: You get the pop-up and data populates on form. You don’t see the CMS toolbar or anything else that indicate your admin privileges
Different types of URLs in email:
- Links to text (sms:), call (tel:) and email (mailto:) did not use the redirect.aspx?linkID= or auth key treatment
- Admin URLs do not get the auth key treatment (they get switched to site URL in EM, but they still don’t get the auth key treatment)
Link to your current membership: If auth keyed in on a membership form as a member with a current membership, you’ll see the current member link. This link will prompt them to login to access their member information, and the auth key will be dropped.
Audience settings:
- Everyone - Ask unregistered users to create a Non-member account before continuing
- Not prompted to login
- If I don't confirm identity and choose to start a new form, then the audience settings apply and I am prompted to create a non-member account
- Everyone - Allow registered users direct access
- Not prompted to login
- If I don't confirm identity and choose to start a new form, then the audience settings apply and I'm given direct access to the form
- Logged in
- Not prompted to login
- If I don't confirm identity and choose to start a new form, then the audience settings apply and I am prompted to log in
- Role
- If I fall into the appropriate role, I'm not prompted to login
- If I don’t 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 I click on a E/M/D Center link and don't fall into role, I'll be prompted to login (to see if I meet the role). If I don’t meet the role, I’m redirected to the homepage
- If I click on a E/M/D/F form link and don’t fall into role, I’m redirected to the homepage.
- If I don't confirm identity and choose to start a new form, then the audience settings apply and I am prompted to log in
- ICP
- No login prompt when accessing form. And ICP pop-up isn't triggered when the first step is submitted.
- If I don't confirm identity and choose to start a new form, then the audience settings apply and the ICP pop-up appears after I submit the first step
Data handling/Field visibility:
- Field has a value. Field is marked to pre-populate
- Field value populates on form
- When user blanks field out and completes/submits the form, the field is blanked out in profile.
- Field doesn’t have a value. Field is marked pre-populate.
- Field loads on form and is blank.
- User adds a value and submits the form. After the form is submitted, the value for that field appears in the profile.
- Field has a value. Field is NOT marked pre-populate
- The field doesn’t load if the user confirms identity (proceeds using auth key). If the user says to start a new form, the field is loaded.
- When form is submitted, the value for the hidden field is not altered in any way
- The hidden field is not displayed in Form Data or Form No Blanks tokens
- When a role is associated with the hidden field (in db – not form specific), that association is maintained. Example: The Maiden Name field was hidden from the form since it’s not marked prepopulate. Even though the field didn’t show up, rich text that was tied to a role from that field did show up. When I changed the value for that field in the db and removed the constituent from the role, the rich text was removed.
- When profile field isn’t marked prepopulate, there’s a warning for the admin
- Scheduled payment scenario: A field not marked to pre-populate doesn’t show up in the original confirmation email. I confirmed that it is pulled in during scheduled payment email process, though.
Form setting (allow data population… checkbox) defaults:
Add New Field:
- On non-profile form, it’s set to false and checkbox is invisible
- On profile form, it’s default is true, checkbox is displayed for user choice
Quick Add Field:
- On any non-profile form, it’s set to false and checkbox is invisible
- On profile form, it’s default is true, checkbox is displayed for user choice
Add Existing Field:
- When reusing/copying the member field: It’s set to whatever the previous owner set it to
- When creating a new member field/cloning: It’s set to false.
Add Existing Category:
- When reusing/copying the category:
- Non-instance, non-clonable field: Set to true
- Non-instance, clonable field: Set to true
- Instance field: Set to false, checkbox is invisible
- When creating a new category/cloning a category:
- When reusing member fields:
- Non-instance, non-clonable field: Set to true
- Non-instance, clonable field: Set to false
- Instance field: Set to false, checkbox is invisible.
- When reusing member fields:
- When reuse member fields isn’t checked:
- Non-instance, non-clonable field: Set to true (they aren’t clonable, so they are reused)
- Non-instance, clonable field: It’s set to false.
- Instance field: Set to false, checkbox is invisible
- Cloning a Form
- Profile forms and Membership campaigns are not clonable
- Forms/Events/Campaigns
- Profile fields are reused and maintain their existing setting.
- All new fields on the form are not profile fields and are set to false.
Storing Non-Member Field based fields in form sessions:
- Designations - On return visit, the unconfirmed values of the last visit prepopulated. If you complete the form/transaction and return to the form again with the auth key, the designation information will return to its default setting – the last values are confirmed and do not prepopulate.
- Membership levels - On return visit, the unconfirmed values of the last visit prepopulated. If you complete the form/transaction and return to the form again with the auth key, the membership level information will return to its default setting – the last values are confirmed and do not prepopulate.
- Membership promo code - On return visit, the unconfirmed value of the last visit prepopulated. If you complete the form/transaction and return to the form again with the auth key, the promo code information will return to its default setting – the last values are confirmed and do not prepopulate.
- Volunteer Management agent code - On return visit, the unconfirmed value of the last visit prepopulated. If you complete the form/transaction and return to the form again with the auth key, the agent information will return to its default setting – the last values are confirmed and do not prepopulate.
- Payment Options - unconfirmed values Scheduled Payments, Recurring Billing and the Membership Auto-Renewal checkbox don't show up on a return visit
Non- commerce, non-instance Forms & the submissions grid
- The Form submissions grid now shows data for non-commerce, non-instance forms when the Auto Populate rollout flag is on (when off, no submissions from these types of forms are captured and icon is still gray/deactivated). "Pre-populate user profile data from return link" form setting does NOT have to be checked for this to happen – it works when the auto populate form setting is enabled and when it's disabled.
- Old forms: Existing non-commerce, non-instance forms have a submissions grid icon but it's grayed out/deactivated. Once there's a new submission, though, it's activated and the new submission shows up in the grid (old submissions do not – it's only a partial history).
Auto Populate & the Submissions Grid
- When changes are made on an auth key'd form, "Pending Review" shows up in the Profile Data Change column. When nothing is changed on the form, "No Changes" shows up up for that submission under Profile Data Change.
Auto Populate & forms added to new pages via Module ID:
- I believe a small number of clients put the module id for their donation form on a number of different pages (with different templates... to give a different look and feel for athletics vs. fine arts, etc.).
- I confirmed that adding a URL from one of these kinds of pages will NOT trigger the auth key functionality in Email Marketing.
HEP/gift matching with auth key login
- If the matching gift field is not an instance field, the company name from their previous submission will show up and when they click on the link to search, it will have the search results for the current value in that field .
- If the matching gift field is an instance field, the company name from the previous submission will not show up when returning to the form with an auth key