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?

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.

Tip

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. 

Tip

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

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.
   

   

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

   

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

   

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. Leave Action blank to redirect the default portal view. (More complex portals can redirect other pages by setting the same Action value as the page you'd like to redirect.)

7. Set View to Default.

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

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.
    

    

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.

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

    

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.
    

    

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.
    

    

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

23. Click Save.
    

    

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:

Your title goes here

Your content goes here

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.
   

   

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

4. Click Save. The query summary page appears.

   

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

   

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.

   

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.

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.

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.

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

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.