0

I have a customer portal that generates a unique URL that contains the Subscriber Key of my record (mdmid). The customer would click on the URL and brought to a CloudPage. On the CloudPage would just be a simple Smart Capture form asking the customer to verify or update their email and phone number. On the Smart Capture form, the Email and Phone fields would pre-populate with the data.

I can get this working in an email, but am having trouble getting this to work on an actual CloudPage.

I have a CRM data extension that contains all of the data I need. A mdmid, the phone number, and the email address. On this data extension the mdmid relates to the Subscriber Key.

The url structure that goes to the CloudPage would be something like cloud.website.com/update-info?mdmid='123456'

My AMPscript on my CloudPage is this:

%%[

var @SubscriberKey, @Email, @Phone, @mdmid

set @mdmid = RequestParameter('mdmid')
set @SubscriberKey = AttributeValue('_subscriberkey')
set @Email = Lookup('CRM','EMAIL','mdmid',@SubscriberKey)
set @Phone = Lookup('CRM','PHONE','mdmid',@SubscriberKey)


]%%

I can get the CloudPage to pull the parameter from the URL and get it to paste the mdmid as text on the page, but I cannot get it to paste the SubbscriberKey, Email, or Phone. Which is also not letting me pre-populate the email and phone fields on the SmartCapture form.

Looking for advice on how I can get the CloudPage to recognize these variables and paste the value of them to the page.

1 Answer 1

0

I am always wary of processes that are meant to surface data on Cloudpages. E.g. The email with your unique link could be forwarded by mistake (or found in a compromised inbox), exposing data - and worse, your smart capture in this case enables data changes for anyone who has the link, to anything they want.

This could be a severe security vulnerability, as it enables attackers to change profiles to their information and go social engineering. Do your own due diligence, but this sounds like thin ice. Email and phone numbers sound pretty juicy for exploits.

There are well-documented ways to use authentication on cloudpages, which is something you should definitely consider.

https://blog.email360.io/posts/cloudpage/create-authenticated-cloudpage.html

Also, you don't want to send PII data unencrypted in a GET Request.

All that aside - CloudpagesURL solves your immediate problem, and also takes care of the unencrypted GET request for you: https://developer.salesforce.com/docs/atlas.en-us.noversion.mc-programmatic-content.meta/mc-programmatic-content/cloudpagesurl.htm -

once you access the page from an email with that function like so:

(RedirectTo(CloudpagesURL('12345'))

12345 being the cloudpage ID. you can use _subscriberKey on the page for your lookups. This only assumes your Cloudpage is in the same BU as your email.

2
  • This is very much needed advice. The customer would have to log into the portal to reach the URL, then log in again to the CloudPage. Instead of logging in twice, would it be more secure to have a form on the customer portal and have it POST the data to a SFMC data extension or to a Smart Capture form? Commented Nov 19, 2021 at 17:41
  • yes, absolutely. put the form directly behind a login; POST data instead of GET, leave emails out of the sensitive data flows. also, be advised that email change is always a delicate thing in case SFMC already knows the existing email address; check this recent discussion: salesforce.stackexchange.com/questions/362259/… Commented Nov 19, 2021 at 17:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .