Portal Redirects
  • 12 Sep 2024
  • 10 minute read
  • Dark
    Light
  • PDF

Portal Redirects

  • Dark
    Light
  • PDF

Article summary

A redirect intercepts a URL before the page loads, checks specific criteria, and sends the user to a new place. You can redirect to another view in the same portal, a completely different portal, or any URL of your choosing. For example, you can redirect the application status page to an admitted student page once the student is admitted, or send an alumni volunteer to a required confidentiality form if they have not completed the form.

Redirects can help by keeping URLs consistent. You can publicize the /apply/status link and allow students to bookmark it, knowing that they’ll be taken to the admitted student page at the appropriate moment.

Building a Basic Redirect

All redirects are composed of two parts:

  1. A query with only one export called “redirect”.

  2. A method with an Output Type of Redirect.

This section describes how to set up a single redirect.

Creating the Redirect Query

  1. Create a new query in your portal. The base of this query must match the Security setting of your portal. For example, in an application-scoped portal, make a query with a base of Application.

  2. Create a subquery export.

  3. Set the Name to “redirect”. It must have this exact name.

  4. Use subquery logic to export the desired redirect location. The export should return a null value if it shouldn’t redirect.

The most straightforward way to build a redirect is by using an Existence export. For example, we can redirect from the status portal to an admitted student portal by checking for the existence of an Admit decision:

In this example, we leave the “Value If Not Exists” blank. This is because if the student doesn’t have an Admit decision, we don’t want to redirect - we just want to stay on the status portal.

Important!

Redirects don’t work both ways. If a student who’s not yet admitted tries to visit the /portal/admits link, they will not be redirected back to the status portal. In this example, you would need to modify the admitted student portal to disallow non-admitted students - most commonly by using access filters, or setting up a redirect in the admitted student portal.

Creating the Method

Now that you have the redirect query, you can create the redirect method.

  1. Create a new method with the following settings:

    • Name: Give it a descriptive name.

    • Type: GET

    • Output Type: Redirect

    • Action: Match this to the action of the method you’re redirecting away from. To redirect the default view, leave this blank.

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

  2. Once you save the method, click Edit Linked Queries.

  3. Select the redirect query you made and click Save.

Redirecting with Multiple Views

If your portal has multiple views, you’ll need multiple redirects - one for each view. You can use a single redirect query and associate it with multiple redirect methods.

Important!

Do not use this section if your portal uses tabs - it only works if each view represents a separate page in the portal. If your portal uses tabs, read the Redirecting Tabs section instead.

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

One Query, Multiple Redirects

It’s a best practice to use a single redirect query, even if you have multiple views with multiple redirects. This allows your redirect logic to live in one place and helps catch and prevent potential redirect loops.

We also recommend using a Formula export. Existence exports can only export two values, so they can’t handle more than two views. Additionally, since our logic will need to get more complex, a formula can more concisely express our logic even for portals with just two views.

  1. Create or edit your redirect query. Remember that its base should be the same as the Security setting of the portal.

  2. Click Edit Parameters and add the following: <param id="cmd" type="varchar" />. This allows us to 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.

  3. Create a subquery export and set the Name to “redirect”. Choose the Output Type of Formula.

  4. Create one or more nested existence exports that check for the relevant criteria. Use a nested case statement to check both your exports and the cmd value to determine where to redirect to.

Let’s take a look at our example to make things clearer. Since we want to check if a student is admitted, we will create a nested subquery export called “admitted”. This is an Existence export that makes sure the student has a released Admit decision:

Why use an existence export?

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 need to check the logic we just built - is the student admitted or not?

  • Second, we need to 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 logical step.

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”, that means 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-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-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.

Multiple Redirect Methods

Once you have created your redirect query, you’ll need to create one redirect method for every view. In our example, that means we need two redirect methods.

  1. Create a new method with the following settings:

    • Name: Give it 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 away from. To redirect the default view, leave this blank.

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

  2. Once you save the method, click Edit Linked Queries.

  3. Select the redirect query you made and click Save.

  4. Repeat this process for each view.

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

Notice the single “Redirect” query has both Redirect methods listed in the Used By column. In the methods, the Action column is identical for each view and its corresponding redirect.

Redirecting Tabs

The example in the previous section assumes each view is a separate page. However, your portal may have tabs which are conditionally displayed. 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, and the tab query string parameter is used in the address bar instead of cmd.

Tab Redirect Query

  1. Create or edit your redirect query. Remember that its base should be the same as the Security setting of the portal.

  2. Click Edit Parameters and add the following: <param id="tab" type="varchar" />. This allows us to capture the tab query string parameter in our query.

  3. Create a subquery export and set the Name to “redirect”. Choose the Output Type of Formula.

  4. Create a nested existence export that checks for the relevant criteria. Use a case statement to check your export and the tab value to determine where to redirect to.

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:

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. Create a new method with 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 this blank.

    • View: Select the default view

  2. Once you save the method, click Edit Linked Queries.

  3. Select the redirect query you made and click Save.

It may seem counterintuitive to leave the Action setting blank - after all, each tab does have a specific method associated with it. However, just remember 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

Don't forget to test thoroughly! 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 "never-ending 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.

Tip

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 is needed.


Was this article helpful?

What's Next