Allow Anonymous Access to Person or Dataset Portals

Anonymous security portals can be useful for displaying information to the general public as well as including links to forms and/or event registrations. However, there may be cases where users want the option to use the same portal, but with two experiences:

  • Logged In - If the portal user is logged in or accesses the portal via a personalized URL, they see personalized content
  • Not Logged In - If the portal user is not logged in or accesses the portal via a non-personalized URL, they see unpersonalized content

In these cases, users can select the option to 'Allow anonymous access to view unpersonalized content'.

Important!

Extreme caution should be exercised when displaying personal information without requiring login. Ensure that the personalizations are limited to things like first or preferred name and the GUID to prepopulate forms.

Portal Settings
  • Allow anonymous access to view unpersonalized content - This should be selected in order to allow for anonymous access
  • Allow access only for identified users - This is the default setting. Typically person and dataset portals will require a login or a personalized URL

Portal Security

To begin creating a person or dataset security portal that also allows for anonymous access:

  1. Create a new portal.
  2. Select the desired Security based on audience, either person or dataset.
  3. Select the desired Security Link setting.
  4. Select Allow anonymous access to view unpersonalized content for the Anonymous Access setting.
Using @identity

In order to personalize the person or dataset security portal, the Portal Identity filter is needed which uses the @identity variable:

Portal Identity Filter

To ensure that the portal uses an appropriate Portal Identity filter:

  1. Create a new query in the portal.
  2. Add the exports desired. Be sure to make the export names computer-friendly, i.e. no spaces, all lowercase.
  3. The Portal Identity filter should use the @identity parameter.
In the case of a person-scoped
query, you should see:
In the case of a dataset-scoped
query, you should see:
(p__JID_.[id] = @identity)
Adding Filters to the Portal View

Filters can be used on Portal View parts to display certain content only to identified records.

For example, if the portal should only display specific information to prospects in a particular term, filters can be added to conditionally display the content. Those records accessing the portal anonymously would not see this content, and those records that login or use a personalized URL would only view the content if they met the filter criteria. 

Filters on Portal View Parts

Adding Liquid Markup to the Portal View

Liquid markup can also be used in the portal view(s) to display conditional content.

For example, the portal may be set up to display 'Welcome, {{first}}!' if it knows who is accessing the portal (via a personalized link or login) or display 'Welcome!' if the portal is being accessed anonymously. 

In the source code of the view where these messages display, the Liquid markup would resemble the following:

Welcome Text

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
Welcome{% if first %}, {{first}}!{% else %}!{% endif %}
</body>
</html>

If first is populated in the portal query, then the view will display the first name. Otherwise, it will display nothing: 

First name exists in the query: First name does not exist in the query:

Additional customizations can be made, such as personalizing content based on other fields using Liquid markup.

Customizing Form Links

The same logic can be applied when creating links in the portal. For example, if the id of the record exists in the query, then add &person={{id}} (or ?person={{id}} if the form has an alias) to the form or event registration URL:

URL Text

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>{% if id %}
<a href="/register/request-info?person={{id}}">Click here to request information!</a>{% else %}<a href="/register/request-info">Click here to request information!</a>{% endif %}
</body>
</html>

The result of this code is:

Automatically linked to the associated record Not automatically linked to a record

(Pre-populates any previously collected data for that record)

Personalized Form Response

Create a Mailing to Send out the Personalized Portal Link

Many institutions will use a Deliver mailing to email records a link to the portal. The link in the mailing will include the person GUID to allow access to the portal. 

  1. Create a new mailing.
  2. Create a recipients list. (Be sure to include the person GUID or dataset GUID.)
  3. Edit the message and add the desired template, formatting, and text.
  4. Include the link to the portal. (Be sure to note the 'key' syntax at the end of the URL.)
slate-university.edu/portal/person_portal_key?key={{Person-GUID}}
slate-university.edu/portal/dataset_portal_key?key={{Dataset-Row-GUID}}

  Tip

Don't forget to replace person_portal_key or dataset_portal_key with the actual key of your portal!

The recipient list includes the Person GUID which is necessary to customize the URL in the mailing:

Recipients List Query

When adding the URL to the mailing, the key syntax is used, and the value of that key parameter is the Person GUID:

Mailing with URL

Test the Portal

These steps allow you to send a personalized link to the portal (if secure link is enabled). When the record clicks their personalized link to the portal, the portal will populate with their information. 

Personalized Experience Gif

If the portal URL is not personalized, records can still access the portal, but the content, forms, etc. will not be personalized. 

Upcoming Events

Additional links can be added, such as those for upcoming events:

  1. Create a new query in the anonymous portal. If this is a query of upcoming events, use the Configurable Joins - Forms base.
  2. Add the exports desired. (Be sure to make the export names computer-friendly, i.e. no spaces, all lowercase.)
  3. Click Edit Parameters.
  4. Add a node, as the query will be returning a list of events, and the view will use the node in Liquid looping to generate the list of events.

    Query with Node

  5. Add the desired filters to narrow down the list of events to display on the portal.
  6. Edit the portal view to add a new static content block with Liquid looping. The Table View Widget may be useful to display a dynamic list of upcoming events, or other data points that involve Liquid looping. 

Liquid markup is used inside of the Liquid looping. If the portal knows who is accessing the portal (via the personalized URL, or if the user is already logged in), then all of the URLs to the event registrations will include a passed parameter to pre-populate the registration form. If the portal is accessed anonymously, the portal will link to the general registration URL with no pre-population. 

Liquid Markup for Events

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
<table cellpadding="1" cellspacing="1" class="sortable" style="width:80%">
<tbody>
<tr>
<td>Date</td>
<td>Event Name</td>
<td>Location</td>
</tr>
{% for event in events %}{% if id %}
<tr>
<td><a href="{{event.url}}&amp;person={{id}}">{{event.date}}</a></td>
<td>{{event.title}}</td>
<td>{{event.location}}</td>
</tr>
{% else %}
<tr>
<td><a href="{{event.url}}">{{event.date}}</a></td>
<td>{{event.title}}</td>
<td>{{event.location}}</td>
</tr>
{% endif %}{% endfor %}
</tbody>
</table>
</body>
</html>
Was this article helpful?
3 out of 4 found this helpful