---
title: "Portal Redirects"
slug: "portal-redirects"
updated: 2026-04-16T19:04:41Z
published: 2026-04-16T19:04:41Z
---
> ## Documentation Index
> Fetch the complete documentation index at: https://knowledge.technolutions.net/llms.txt
> Use this file to discover all available pages before exploring further.
# Portal Redirects
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](/v1/docs/portals-overview) 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](/v1/docs/portal-redirects#redirects-with-a-single-view).
- If your portal has **multiple views,**skip to [Redirecting with multiple views](/v1/docs/portal-redirects#redirecting-with-multiple-views).
- If your portal uses **tabs**, skip to [Redirecting tabs](/v1/docs/portal-redirects#redirecting-tabs).
## Redirects with a single view
If your portal one view, redirects require one query and one method.
> [!WARNING]
> 📝 If your portal has more than one view, skip ahead to [Redirecting with multiple views](/v1/docs/portal-redirects#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.](/v1/docs/creating-a-custom-portal)
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.
> [!WARNING]
> 📝 If your portal uses tabs, skip ahead to [redirecting tabs](/v1/docs/portal-redirects#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.](/v1/docs/creating-a-custom-portal)
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:
```xml
```
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](/v1/docs/using-formulas-in-queries#case-statement).
Let’s take a look at the final formula, then discuss each step in its logical sequence:
```sql
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](/v1/docs/portal-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:
```xml
```
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](/v1/docs/using-formulas-in-queries#case-statement):
```sql
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.