Redirects automatically send a user to a different page from the one they originally accessed based on specific criteria. This can be useful in a variety of scenarios:
- Redirecting an admitted student to a new page specifically for admits after accessing their status page
- Can redirect to a new portal
- Can redirect to a new view
- Redirecting an alumni volunteer to a confidentiality form if they have not completed the form
Redirects can help keep the URL consistent (such as sending all applicants to /apply/status) and then redirecting different populations to other pages if necessary.
When a redirect method is called and the query criteria is met, the page will redirect to the URL that is specified in the "redirect" export.
If the new page for a particular population will have a distinct look and feel, and the content is entirely different, then a new portal with redirects implemented might be recommended.
If the difference is simply the display of an extra tab (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 adding just an additional view to the existing portal might be the easiest to maintain.
Other things to consider:
- How much conditional logic would be needed if the 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 portal(s)? Are the same Slate users in charge of the applicant status page as well as the admitted student content?
The redirect query will have an export called "redirect" that will determine the URL to which the user should be directed.
Redirect with an Existence Export
In this example, the applicant status portal will redirect to the enrolling students portal if the applicant meets the criteria. Additionally, the enrolling students portal will redirect to the status portal if an applicant who does not meet the enrolling student criteria tries to access the enrolling students portal.
Redirect query in the status portal:
This query uses a Display Filter in the existence export to evaluate whether the applicant does meet the enrolling students criteria. The "Value if Exists" setting specifies the relative link to the enrolling students portal.
Redirect query in the enrolling students portal:
The display filter evaluates whether the applicant does not in fact meet the criteria for the enrolling students portal, and should thus be redirected back to /apply/status.
In other words, if a non-enrolling student attempts to log into https://slateuniversity.edu/portal/enrolling, they will be redirected back to https://slateuniversity.edu/apply/status.
Redirect 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 upon login 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 that evaluates whether the user already has the specified form submission.
The redirect SQL snippet specifies a relative link to the form to be filled out.
For redirect methods that redirect to a form registration, the use of the "referrer" parameter allows Slate to send you back to a particular URL after form submission.
A form can also be prepopulated 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.
When possible, the use of an existence export is preferred over custom SQL for ease of use and sustainability.
The redirect query to redirect to a new view will also have an export called "redirect" that will determine the URL to which the user should be directed. Since there are different views, the URL will be the regular portal URL appending 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.
- Admitted Students
- Enrolling Students
In the redirect query, a parameter of cmd is needed so that the redirect export can evaluate what view the applicant is on, and what view they should be redirected to.
This parameter is then used in the redirect export.
Here, in a formula export, case statements are used to determine which view the applicant should be redirected to. The formula also takes into consideration if the applicant is already on the correct view, and thus no redirect is needed.
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", it then checks what URL the applicant is on.
If they are already on /portal/status?cmd=enroll, as evidenced by checking the @cmd parameter, then the applicant remains where they are.
If not, they are 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.
Redirect methods will be linked to the redirect query and will use Output Type of "Redirect".
For the initial portal load, the redirect method should not have an action and should be associated with your default view.
If the portal has multiple tabs (and thus multiple methods with various actions), a redirect method will be needed for each action. The redirect query can be reused for each redirect method. This will ensure that users who should not have access to the portal cannot access any tab within the portal.
If the portal has multiple views (and thus multiple methods with various actions), a redirect method will be needed for each action as well to ensure that applicants only see the intended view.
The enrolling students portal also has a Directory tab. Including the redirect on this method will ensure that a non-enrolling student is also redirected back to the status portal even if they try to access https://slateuniversity.edu/portal/enrolling?cmd=directory, and not just, for example, https://slateuniversity.edu/portal/enrolling.
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 and never 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, as 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.