A redirect intercepts a URL before the page loads, checks for some criteria, and then sends the user to a new place. You can redirect the user of a Slate portal to another view in that same portal, to a completely different portal, or any URL of your choosing.

For example, you can redirect the user arriving at the application status page to an admitted student page if the user is an admitted student, or send an alumni volunteer to a required confidentiality form if they haven’t yet completed that form.

Why use a redirect?

Redirects can help you keep your URLs consistent. You can publicize the /apply/status link and let students bookmark it, knowing that they’ll be routed to the admitted student page if they fit the redirect criteria.

Building a portal redirect

All redirects have two parts:

1. A query called redirect that returns the existence of some condition.

2. A method with an output type of Redirect.

The steps you take to create a redirect depend on the layout of your portal:

• If your portal has just one view, go to the next section.

• If your portal has multiple views, skip to Redirecting with multiple views.

• If your portal uses tabs, skip to Redirecting tabs.

Redirects with a single view

If your portal one view, redirects require one query and one method.

📝 If your portal has more than one view, skip ahead to Redirecting with multiple views.

Creating the redirect query

To create the redirect query:

1. Go to Database → Portals.

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

3. Select New Query.

4. Configure the following settings:

   • Name: Enter a name for the query, for example: Redirect.

   • Type: Configurable Joins

   • Category, Base: The category and base of the query must match the portal’s Security Type. For example, for a portal with a security setting of Application, select Records → Application.

5. Select Save.

6. Select Subquery Export.

7. Configure the following settings:

   • Name: redirect 📝 This must match exactly.

   • Type: Dependent Subquery

   • Output: Existence

   • Value If Exists: Enter the redirect’s target URL slug (everything after the forward-slash). For example, we can send admitted students arriving at the applicant portal to /portal/admits

   • Value If Not Exists: Leave this field blank so that, if the redirect conditions aren’t met, the query returns a null value, and we leave the user on the page they arrived at.

   • Filters: Add filters that specify the conditions that will cause a user to be redirected. For example, to target admitted students, we filter for a decision code in Admit and decision status in both Released (but not Received) and Received.  

8. Select Save.

To summarize: This subquery export checks for the existence of an Admit decision. It returns a URL slug if an Admit decision exists, otherwise it returns nothing.

Redirects are one-way

If an applicant who has not yet been admitted goes to /portal/admits, what we’ve created wouldn’t cause them to be redirected to the status portal.

To get this behavior, we’d have to create another redirect in the admitted students portal, or else limit access to that portal with filters.

Creating the method

Now that we have the redirect query, we can create the redirect method:

1. Return to the portal overview page.

2. Select New Method.

3. Configure the following settings:

   • Name: Give the method a descriptive name.

   • Type: GET

   • Output Type: Redirect

   • Action: Enter the Action of the source method (the one you’re redirecting the user away from). To redirect from the default view, leave this field blank.

   • View: Select the source view (the one you’re redirecting the user away from).

4. Select Save.

5. Select Edit Linked Queries.

6. Select the redirect query created earlier.

7. Select Save.

   

Redirecting with multiple views

If your portal has multiple views from which you want to redirect users, you must create multiple redirect methods, one for each view. You can associate the same redirect query with multiple redirect methods.

📝 If your portal uses tabs, skip ahead to redirecting tabs.

In this section, we’ll use as our example an application status portal with two views: a default view, and an Admitted Students view. The techniques we use here can be applied to any portal with multiple views representing multiple pages.

Creating the redirect query

The redirect query will involve a subquery with the output type Formula. The subquery will itself include one or more subquery exports of output type Existence, and they’ll return Y or N depending on the presence of the criteria we’re evaluating. The formula will then use a nested case statement to perform a calculation on these returned values.

To create this redirect query:

1. Go to Database → Portals.

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

3. Select New Query.

4. Configure the following settings:

   • Name: Enter a name for the query, for example: Redirect.

   • Type: Configurable Joins

   • Category, Base: The category and base of the query must match the portal’s Security Type. For example, for a portal with a security setting of Application, select Records → Application.

5. Select Save.

6. Select Edit Parameters.

7. In the Parameters field, enter the following:

   <param id="cmd" type="varchar" />

   This lets us capture the cmd query string parameter in our query. We need to know the cmd value so we know what page we’re starting on.

8. Select Save.

9. Select Subquery Export.

10. Configure the following settings:

    • Name: redirect

    • Type: Dependent subquery

    • Output Type: Formula

11. Select Save.

12. Select Subquery Export.

13. Configure the following settings:

    • Name: Enter a computer-friendly name representing the criterion to be evaluated. For example, admitted.

    • Type: Dependent subquery

    • Output: Existence

    • Value If Exists: Y

    • Value If Not Exists: N

    • Add filters for the criteria. For example, a decision code value in Admit and a decision status value in Released (but not Received) and Received.

14. Select Save.

15. Repeat for as many criteria as you want to evaluate in the formula.

16. In the Formula field, enter a case statement that checks your exports and the cmd value to determine the redirect destination. See example below for more detail.

17. Select Save.

Example: Redirecting admitted students

We want to check if a student visiting our portal is admitted. To do this, we create a nested subquery export called admitted. This subquery export uses an Existence output that makes sure the student has a released Admit decision:

We use an existence export so we can encapsulate this logic. When we write our formula, we will only need to check whether @admitted equals Y or N. If we ever need to change this logic, we can just modify this subquery without modifying the formula.

We’re now ready to write our formula. We need to check two conditions to determine our redirect:

• First, we check the logic we just built: is the student admitted or not?

• Second, we check where we are: are we already on the right page, or do we need to redirect to it?

To do this, we are going to use nested case statements.

Let’s take a look at the final formula, then discuss each step in its logical sequence:

case when @admitted = 'Y' then
  (case when @cmd = 'admitted' then null 
   else '/portal/status?cmd=admitted' end)
else
  (case when @cmd = 'admitted' then '/portal/status'
   else null end)
end

• The first line checks our admitted subquery export. If it equals Y, the student is admitted, and they should see the Admitted Students view. But in order to prevent redirect loops, we now need to check whether we’re already on that view.

• The part in parentheses (lines 2 and 3) checks the cmd parameter. If it’s equal to admitted, we don’t want to redirect: we’re already in the right place. That’s why it ends with then null: because the redirect export should return null when we don’t want to redirect. The else statement handles the situation when cmd does not equal admitted, and so we do want to redirect to the Admitted Students view. Notice that we need to include the full path: everything starting with /portal.

• At this point in the formula (line 4), if we had other populations to direct to other views, we could add another when statement and start the process again. In this situation, we only have two possibilities (admitted or not admitted), so we just use else to capture the situation where admitted does not equal Y.

• The next lines (lines 5 and 6) are similar to the previous nested case statement. If the student isn’t admitted, but the cmd value is admitted, we need to redirect back to the default view (/portal/status). If we’re already there, we just need to return null.

Creating a redirect method for each view

Once you have created your redirect query, you now need to create one redirect method for every view.

In our example, that means we need two redirect methods.

To create a redirect method:

1. Select New Method

2. Configure the following settings:

   • Name: Give the method a descriptive name. It’s a good idea to match the name to the view it’s redirecting from. For example, naming it Redirect: Admitted Students.

   • Type: GET

   • Output Type: Redirect

   • Action: This must exactly match the action of the method you’re redirecting from. To redirect the default view, leave this blank.

   • View: Select the view you’re redirecting from.

3. Select Save.

4. Select Edit Linked Queries.

5. Select the redirect query you created in the previous section.

6. Select Save.
   

7. Repeat for each view.

In our example with two views, the final portal configuration looks like this:

Note that the single Redirect query has both redirect methods listed in its Used By column.

In the Methods section, the Action column is identical for each view and its corresponding redirect.

Redirecting tabs

The example in the previous section assumes each view in your portal is a separate page, but what if your portal has tabs that only appear under certain conditions?

Even if a tab is not shown to the end-user, someone could attempt to view the tab by changing the URL. Or, if the end-user previously had access to the page, they may have bookmarked the tab.

There are two main differences to consider:

• Tabs are all displayed within the same view on the same page.

• The tab query string parameter is used in the address bar instead of cmd.

Creating the tab redirect query

To create a redirect query for tabs:

1. Select New Query.

2. Configure the following settings:

   • Name: Enter a name for the query, for example: Redirect.

   • Type: Configurable Joins

   • Category, Base: The category and base of the query must match the portal’s Security Type. For example, for a portal with a security setting of Application, select Records → Application.

3. Select Save.

4. Select Edit Parameters

5. In the Parameters field, enter the following:

   <param id="tab" type="varchar" />

   This lets us capture the tab query string parameter in our query.
   

6. Select Subquery Export.

7. Configure the following settings:

   • Name: redirect

   • Type: Dependent subquery

   • Output Type: Formula
     

8. Select Subquery Export.

9. Configure the following settings:

   • Name: Enter a computer-friendly name representing the criterion to be evaluated. For example, captain.

   • Type: Dependent subquery

   • Output: Existence

   • Value If Exists: Y

   • Value If Not Exists: N

   • Add filters for the criteria. For example, an Alumni Interview Role in Captain.

10. Select Save.

11. In the Formula field, enter a case statement that checks your export and the tab value to determine where to redirect to.  See example below for more detail.

12. Select Save.

Example: Redirecting non-captain alumni volunteers

In the Alumni Interviewing portal, only certain alumni volunteers have access to the Assignments tab. The captain subquery export checks to see if the logged-in volunteer has the appropriate permission level.

If the user isn’t a captain but they’re trying to access the Assignments tab, we redirect them back to the home tab.

We do this with a case statement:

case when @captain = 'N' and @tab = 'assignments' then '/portal/alumni_captains?tab=home' end

Creating the tab redirect method

In a portal with tabs, the view we need to associate with our redirect method is the default view, since that’s the view containing the tab framework code.

1. Select New Method.

2. Configure the following settings:

   • Name: Give it a descriptive name. If your portal has tabs but no other views, you can simply name it Redirect, since you only need one redirect method.

   • Type: GET

   • Output Type: Redirect

   • Action: Leave blank.

   • View: Select the default view.

3. Select Save.

4. Select Edit Linked Queries.

5. Select the redirect query you created in the previous section.

6. Select Save.
   

It may seem counterintuitive to leave the Action setting blank; after all, each tab does have a specific method associated with it. Recall however that the default view contains the tab framework, so we’re technically redirecting to and from the default view.

We can also think about it like this: the redirect is just changing the tab query string parameter in the URL. No matter which tab we’re on, the default view handles loading the page and deciding which tab to load based on the query string parameter.

Redirecting to a form

You may want to redirect to a form to, for example, force end-users to fill out a confidentiality form before they can access a portal. There are two additional query string parameters you can add to the redirect to improve the user experience:

• referrer: Forms with this query string parameter will skip the default confirmation page and instead redirect to the specified page. This is a helpful way to get the end-user back to your portal once they have filled out the form.

• person: You can ensure the form is pre-populated with the end-user’s information by merging in their GUID.

In this example, we’re using a Formula subquery export.

There’s a nested subquery filter that checks to make sure the end-user hasn’t submitted the confidentiality form. If they already submitted it, the filter will cause this entire export to return null, preventing the redirect.

In the formula, we add /portal/alumni to the referrer query string parameter, and use the guid export to fill in the person query string parameter.

Testing redirects

Here are some things to keep in mind while testing:

• When testing with a record that meets the criteria for one portal but not the other, are they directed to the correct page?

• If a record does not meet the criteria for either portal, what happens?

A redirect loop may occur if a logged-in user does not meet the criteria for either portal, such that the redirect methods in both portals attempt to push the user to the other portal, resulting in the user "bouncing" between both destinations and never completely landing on any page. To avoid this scenario, make sure to define filter criteria in all redirect queries so that no records are inadvertently ineligible for both. Additionally, avoid redirects that send the user back to where they already are. For example, if they are on /apply/status, a redirect should not attempt to send them to /apply/status, since they are already there.

If a custom portal is associated with a round or period, when the applicant goes to /apply/status, they will be using the portal associated with their round or period. A redirect is already applied to send the applicant to the appropriate portal from /apply/status, no new redirect required.