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: