Portal Redirects

A redirect is a small line of web code that automatically sends a user (redirecting them) to a new page based on specific criteria. This can be useful in situations such as sending an admitted student to a new page specifically for admits after accessing their status page or sending an alumni volunteer to a required confidentiality form if they have not completed the form.

Redirects can help by keeping URLs consistent. For example, A process can be designed to have all applicants open the URL ending with /apply/status, and then based on information about the user, recognize that they are in a particular population and then redirect them to other pages as necessary.

When a redirect method is called and the query criteria is met, the page will redirect to the URL specified in the "redirect" export.

A redirect can be configured to send the user to a new portal or to a new view.

Multiple Views vs Multiple Portals

If the new page for a particular population has a distinct look and feel, and the content is entirely different, then a new portal using redirects might be recommended.

If the difference for the population means only adding an extra tab on the page (for example, showing a tab of volunteers if the user is an Alumni Captain, or showing a tab with enrolling student information for admitted applicants on the status page), then just adding an additional view to the existing portal might be the easiest to maintain.

Other things to consider:

  • How much conditional logic is needed if different populations share the same portal?
  • Will there be a large number of different view parts with filters if using only one portal?
  • Who is maintaining the portals? Are the same Slate users in charge of the applicant status page as well as the admitted student content?
Build a Redirect Query to a New Portal

A redirect in a portal can send a user to a new portal based on specific conditions. To generate the redirect, the portal page must contain a redirect query with an export called "redirect," which defines the URL For the target portal that will appear for the user.

The redirect can be configured in one of two ways:

  • With an existence export
  • With a custom SQL snippet

When creating a redirect that will send a user from one portal to another, first configure both the initial (originating) portal and the targeted portal (where the user will be redirected). Refer to the articles on Portals for additional details.

Redirecting with an Existence Export

For the purpose of this procedure, the Welcome Portal and the My Admitted Student Portal portals have been previously created.

1. Click Database from the Slate navigation bar and select Portals in the Portals section. The Portals page appears.

Portals Link


2. Click the Welcome Portal item in the list of existing portals. The Welcome Portal summary page appears.

Portals Summary Page


3. In the Methods area, click the New Method link. The Edit Details popup appears.

New Method Link


4. Give the method a Name. In this example, the method is called "Redirect to New Portal."

5. Set Output Type to Redirect. The options on the popup change.

6. For Action, provide a readable description of what the method does (this is for administrative information appearing on the portal summary page).

7. Set View to Default.

8. Click Save. The summary page for the method appears.


Edit Details

9. Using the breadcrumb navigation at the top of the page, click the link for Welcome Portal. The Welcome Portal summary page appears. 



10. Scroll to the Queries section and click the New Query link. A New Query popup appears.

Queries Link


11. Give the query a descriptive Name. In this example, the query is called "Redirect to new portal."

12. Set the Type, Category, and Base as needed. For this example, Type is Configurable Joins, Category is Records, and Base is Application.

12. Click Save. The summary page for the query appears.


New Query Popup

13. Create a subquery export by clicking the subquery export icon on the right side of the page. An Edit Part popup appears.

Create Subquery Export Icon


14. Give the export a descriptive Name, such as "redirect."

15. Change Output to Existence. Additional existence fields (Value If Exists and Value If Not Exists) appear.

16. In the Value If Exists field, enter the trailing part of the URL for the target portal. (In this case, "/portal/admitted?tab=subtab1".)

17. Create a filter in the Filters section to specify when the redirect will act. In this example, the query filter matches when Submitted Date is equal to or earlier than TODAY (redirecting the user when the item is in "submitted" status).

18. Click Save.

Query Edit Part Popup

19. Return to the Welcome Portal summary page by again clicking the Welcome Portal link in the navigation breadcrumb at the top of the page.

20. Click the Redirect to New Portal method previously created. The Portal Method summary page appears.



21. Click Edit Linked Queries. The Portal Method Queries popup appears, listing all queries available to link to this method.

Edit Linked Queries Button


22. Select the query to link (in this example, "Redirect to new portal").

23. Click Save.

Portal Method Queries

The display filter determines if the application submitted date exists (it is less than or equal to the current date), and if so, the user is redirected to /portal/admitted.

If the user does NOT meet the filter requirement (the application has not been submitted), the current application portal appears.

Redirecting with a Custom SQL Snippet

In this example, if the alumni volunteer has not submitted the Confidentiality Form, they should be redirected to the form after logging in to the portal. If they have already submitted the form, they will not be redirected and will proceed to the portal. 

The query needs one export - a custom SQL "redirect" snippet - and a filter to determine if the user already has the specified form submission.

The redirect SQL snippet specifies a relative link to the form that needs to be completed.

To create the redirect:

1. Follow the steps previously described to set up the View and Method.

2. Return to the portal summary page, scroll to the Queries section and click New Query. A New Query popup appears.

New Query Popup


3. Give the query an appropriate Name. Set Type, Category, and Base according to your requirements.

4. Click Save. The query summary page appears.


Custom SQL Button


5. Click Custom SQL on the right side of the page. An Edit Part popup appears.

Edit Part Popup


6. Give the SQL snippet an appropriate Name.

7. In the SQL field, enter the SQL code required to make the redirect function.

8. Click Save. The new export appears in the Exports area.

Updated Exports Area


For redirect methods that redirect to a form registration, using the "referrer" parameter allows Slate to send the user back to a particular URL after the form submission.

A form can also be system populated with the user's information by appending the form URL with &person=GUID OF RECORD


If the logged-in user meets the redirect criteria, they will be taken to the form registration page. Until the user fills out the form and no longer meets the redirect criteria, they will continue to be taken to the form upon login.


Whenever possible, use an existence export rather than custom SQL for best ease of use and sustainability.

Build a Redirect Query to a New View

The redirect query to redirect to a new view will also have an export called "redirect" that will determine the URL to directed the user. Since there are different views, the URL will be the regular portal URL appended with ?cmd=METHOD_ACTION.

Redirect with a Formula Export

When a portal has multiple views, the redirect query must take into account what, if any, cmd is already in the URL, and then redirect accordingly.

In this example, the status portal has three different views.

  • Applicants
  • Admitted Students
  • Enrolling Students

In the redirect query, a parameter of cmd is needed so the redirect export can determine that view for the applicant, and the redirected view.

Edit Parameters Popup

This parameter is then used in the redirect export. 

Here, in a formula export, case statements are used to determine the redirected view for the applicant.  The formula considers if the applicant is already on the correct view, requiring no redirect.

Edit Part Popup Decision Code

In this formula, there is a case statement nested within a case statement.

The formula first checks the decision_code value. If the value equals, for example, "ENROLL", the formula then checks the current URL for the applicant.

If the applicant is already on /portal/status?cmd=enroll, as evidenced by checking the @cmd parameter, then the applicant remains where they are.

If not, the applicant is sent to /portal/status?cmd=enroll. The formula continues to check for the ADMIT decision, and then no decision.


The cmd value is the action of the associated method.

The multiple case statements are necessary in case an enrolling applicant later bookmarks the /portal/status?cmd=enroll URL. In this example, the applicant would not need to be redirected anywhere, as they would be logging into the /portal/status?cmd=enroll URL, and the redirect query would see that they have the enroll decision, are on the enroll view, and thus nothing should happen.


Whenever possible, use a formula export rather than custom SQL for ease of use and sustainability. Both types of exports allow for commenting or annotation. For example, if you wish to make note of what each case statement is doing, you can put comments between /* and */

Edit Part Popup Enrolling Applicant

Build a Redirect to an External Website

The query to redirect to an external website will have a single export that determines the URL to direct the user. Since you are sending the user to a page outside of Slate, no View or Method is needed. The URL in the export is the URL of the website where you wish to send users. For example: https://www.slateuniversity.org

Redirect using a Literal Export

Build a new Query within your portal and add a Literal export and in the Literal setting, enter the URL for the site where you wish to redirect your users. Add filters to the query to define who should be redirected to the website. No View or Method are needed for this after the query is created.



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.


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?
4 out of 9 found this helpful