Authenticated webpage links in email

Hi,
I have a process where a customer submits a form through the portal. The initial customer-facing form is configured as an authenticated webpage, so the customer must log in before they can submit a case.

Once the form has been submitted, the back-office user can review the case and, if required, request additional information from the customer.

The process works as follows:

  • The back-office user selects a field such as “Do you need more information?”

  • If Yes is selected, an email is sent to the customer.

  • The email contains a link to an authenticated webpage where the customer can provide the requested information.

The problem is that when the customer clicks the link in the email, they receive an error instead of being prompted to log in.

Our expectation is that, because the page is authenticated, if the customer is not already logged in, clicking the link should redirect them to the login page. After successfully logging in, they should then be taken to the authenticated webpage referenced in the email.

To generate the link in the email, we have configured the field as follows:

  • Base Object: CASE 1-1 Application for an advisory disabled bay [PROCESS] Object

  • Field: ID

  • Pre-processor: Changed the field name to “Please click the link to provide more information.”

  • Link: Authenticated Webpage – Customer payment page

  • Link to: [Default] Field's record

A link expiry has also been added to the webpage.

We understand that “Requires session-specific auth token” cannot be used with emailed links, as the token is tied to the browser session that generated it.

Our requirement is to email a link to an authenticated webpage, but we also need to ensure that only the customer who originally submitted the application can access that page after logging in.

We have a couple of questions:

  1. Is there any additional configuration required to make authenticated webpage links redirect users to the login page first and then return them to the requested page after authentication? Or is there a different recommended approach for this scenario?

  2. Is it possible to restrict access to the “Need More Information” page so that only the same authenticated user who submitted the original application can access it? We want to ensure that no other authenticated portal user can access the page, even if they somehow obtain the link.

  3. Has anyone implemented a similar process where customers receive an email containing a link back to an authenticated webpage after a case has already been created?

Any advice or best practice recommendations would be greatly appreciated.

Screenshots:

Webpage authenticated - More information

Message content - Link to above webpage (authenticated)

Thanks

Amara

1 Like

What error do the users receive?

  1. I dont believe authenticated web-pages require a user to be logged in to access them, only interface pages do.
  2. I think i did this by recording the username of the user that the page was about, then comparing it to the username of the logged in user. If they didn’t match then the page displayed an error
  3. I think i might have done something like this for an invite system. I’ll see if i can dig it up and remind myself how i made it work.
2 Likes

I get the below error page, this is because i have enabled requires session auth. But if i untick that, the page is then accessible by anyone that has the link and it doesn’t prompt the user to log in if they aren’t logged in. Is there a way to generate a link to the page which will ask them to login and then take them to the page?

As pointed out above, webpages (auth or public) do not require a login, you just need the link.

If in your use case the users receiving the email will always have an account, then a webpage is probably not the solution you need. Those are generally for when you don’t want to require someone to login to access the page.

I would instead create a record to represent the “request for information”, related to the user/case in question, and create a normal interface page within their portal with that as the base record where the user can fill in the details. This is the page you then send a link to via email (it could also be linked to from within the portal). As a normal interface page, the user will have to be logged in to access it.

You would need to ensure relevant multi-tenancy or object restrictions are in place so a user can only access their own RFIs.

2 Likes

There are probably many other ways to do the actual form, using a Case Stage widget with a completion sub page for example, but I don’t know what best suits your specific setup.

But the gist is you should use a normal interface page if you want to ensure the user is logged in.

1 Like

Thank you, Bob. I tested an interface page with user visibility configured so that the case is related to the user who created it, and it worked as expected for me.

I used the path below for the user visibility setting on the Basics tab of the interface page and linked this page in the email that is sent.