You can create portals with the Anonymous/Guest security setting to display information to the general public, like links to forms or event registrations.

However, you might want to give your visitors different experiences depending on their logged-in status:

• If the visitor is logged in or accesses the portal via a personalized URL, they see personalized content.

• If the visitor is not logged in or accesses the portal via a non-personalized URL, they see generic, default content.

The anonymous access portal setting lets you build a single person or dataset portal that offers both experiences.

The anonymous access portal setting

To configure a person or dataset portal for anonymous access:

1. Go to Database → Portals.

2. Create a new portal, or select an existing one.

3. Select Edit.

4. From the Scope list, select either Person or Dataset.

5. Select Save. If you’re creating a new portal, select Edit again.

6. Ensure Secure Link is set to Enable access via secure link.

7. From the Anonymous Access list, select Allow anonymous access to view unpersonalized content.
   

8. Select Save.

The remainder of this article covers the different ways you can present personalized information to the logged-in users of this portal.

Using queries to display personalized information

When a query is created, the portal identity filter is created automatically.

This filter uses the @identity variable to query information about the logged-in visitor.

When the portal is accessed anonymously, the @identity variable is null. A null value causes all queries to return zero rows, and thus not display any personalized information.

Using filters to display personalized information

When you create a view in a portal, you populate it with various parts from the palette.

When you configure a portal to allow anonymous access to view unpersonalized content, each of these parts is in turn given a new setting called anonymous access filter.

This setting has two options, which determine the type of filters that can be added to the view part:

• Use standard filters: The default setting. Lets you to add filters to the portal view part that match the scope of the portal. If you add any non-system filter to the part, this part will not appear to anonymous visitors to the portal.

• Use system filters only: Prevents you from adding any filters that would hide the part from someone viewing the portal anonymously. If you choose this setting, but do not add any filters, the setting resets to the default Use standard filters setting.

Example: Filtering for entry term

If you’d like your portal to display specific information to prospects in a particular term, you could:

1. Create a portal view part displaying that content.

2. Leave Anonymous Access Filter set to Use standard filters (restrict all anonymous access).

3. Add an Entry Term filter.
   

Anonymous visitors to your portal do not ever see this content, while records that log in or access the portal via a personalized URL, if they met the filter criteria, do see the content.

Example: Event open to the public

On the other hand, say you’re announcing an event that’s open to everyone, and you want the portal to automatically update once the announcement is live. You can:

1. Create a portal part.

2. Leave Anonymous Access Filter set to Use system filters only.

3. Add a Current Date filter.

4. Configure the filter to display the portal part on or after a specific date.
   

Regardless of whether someone uses a personalized link, a login, or anonymous access, they’ll only be able to see this portal part when the filter criteria evaluates on that date.

Using Liquid markup to display personalized information

You can add Liquid markup to a portal view to display conditional content.

Example: Greeting with first name

For example, the portal may be set up to display “Welcome, {{first}}!” if the visitor is accessing the portal via a personalized link or login, and to otherwise display “Welcome!” if the portal is being accessed anonymously.

In the source code of the view where these messages should appear, you’d enter the following Liquid markup:

Welcome{% if first %}, {{first}}!{% else %}!{% endif %}

If a value for first is populated in the portal query, then the view will display the visitor’s 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.

Using custom form links to display personalized information

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:

<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: Pre-populates any previously collected data for that record.

• Not automatically linked to a record: ID does not exist. Will not pre-populate any data.

  

Creating and sending a personalized access link

You can create a personalized link that displays all of the conditional content you’ve created to that visitor. The personalized link includes the person or dataset GUID, which allows access to the portal.

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

To create and send this link:

1. Go to Deliver.

2. Select an existing mailing, or create a new one.

3. Create a recipient list that includes the person GUID or dataset GUID.

   

4. Edit the message and add the desired template, formatting, and text.

5. Add a link to your portal in the body of the message. Format the link as follows:

   • For person-scoped portals:

     slate-university.edu/portal/person_portal_key?key={{Person-GUID}}

     Where person_portal_key is the key of the person-scoped portal and Person-GUID is the exact name of the GUID export merge field from your recipient list.
     

   • For dataset-scoped portals:

     slate-university.edu/portal/dataset_portal_key?key={{Dataset-Row-GUID}}

     Where dataset_portal_key is the key of the dataset-scoped portal and Dataset-Row-GUID is the exact name of the GUID export merge field from your recipient list.
     

     

Testing the portal

As long as the secure link access setting is enabled, the personalized link you’ve created should provide access to the conditional content you created in your portal.