1. Slate Knowledge Base
  2. Admissions & Enrollment
  3. Portals
  4. Getting Started with Portals

Portals Best Practices

Updated
Expand-All  Collapse-All

To be successful in the use of Slate Portals, please ensure you have reviewed basic web development or data querying knowledge articles. Familiarity with specific Slate tools and concepts are necessary to build out functional portals.

Getting Started

      1. Determine the type of portal.
      2. What is the overall goal of the portal?
      3. Who are its users, and what should they be able to accomplish?
      4. Determine the functionality.
      5. Which Slate users should be allowed to edit the portal?
      6. Map out the view.
      7. Portals should not be created to replace existing Slate functionality. For example, batch updates can and should be performed by Slate users with the Upload Dataset or Query Batch Management tools, etc.
      8. Reader review forms and workflows within the Slate Reader should still be the mechanism through which Slate users provide admission reviews on applications.

Avoid the use of custom SQL

      1. As stated in the Custom SQL Best Practices article, Slate is designed to be used and administered by non-technical users who have no previous experience with Structured Query Language (SQL). In most circumstances, custom SQL is not necessary.
      2. When custom SQL is used, it limits the number of Technolutions resources, such as the Service Desk, who will be able to help assist you.
      3. Custom SQL is no longer needed for POST methods in portals. Instead, you can use forms to update the data you may need. A future Knowledge Base article is coming out with these steps, but this Community Forum post has outlined an example with the Athletics Portal.

CSS within portal

      1. To effectively use this feature, you must be comfortable with or be willing to learn CSS, in order to maintain CSS rules for portals and be able to update or troubleshoot when necessary!
      2. We recommend consulting your web/marketing staff for advice on what styles or rules to implement in an individual portal so that it remains consistent with your institution's visual brand and identity.
      3. We recommend that your portals inherit your main Slate branding (by selecting "Default Branding" on the relevant pop-up method) while leveraging custom CSS code for specific items, such as making buttons or tables look a particular way. This allows specific elements or aspects of the portal to be customized at a more granular level, but without writing an entire stylesheet for the portal from scratch.
      4. If you need further assistance, we suggest contacting a Preferred Partner to see if they can assist.

Widgets

Widgets are recommended to improve portal functionality. 

      1. A portal widget is an element that can be added to a portal view to display specified content.
      2. Depending on the security type of your portal will determine if you have access to certain widgets or not. For example, an Anonymous security portal will not have access to application widgets.
      3. Some widgets include built-in logic, and all widgets can be conditionally shown with filters.
      4. Not all widgets are necessary, depending on the portal's function and role in your process.

Forms

      1. Using the form widget is recommended if the scope of the form is the same as the scope of the portal (i.e. the security setting that indicates the type of record that will be authenticated by the portal).
      2. Forms can be used instead of the POST method in portals. Please review the Community Forum post for how to accomplish this here: https://knowledge.technolutions.com/hc/en-us/community/posts/4408364539547-Athletics-Portal-and-Notes-Feature

Pop-Ups

When updating data from a pop-up, the pop-up will often include either select lists or input boxes. The user will then select or type in the appropriate value and then save/update/submit.

Tabs

If you are adding tabs to an existing portal, please note that you'll need to create a new default view with just the tab framework, and then make adjustments to your existing method, as the former default view and method (pre-tabs) will become a view associated with a tab method. For example, moving from a portal without tabs (one view, one method) to a portal with three tabs would result in four views (the tab framework default view and then the three views for the tab content) and four methods (one default and then three with actions for the three tabs).

Timeouts

      1. Ultimately, the speed of loading depends on many factors, including the processing power being used across your system in things like rules, scheduled queries, mailings, etc. 
      2. As your database grows in depth and complexity, it is not uncommon for resource-heavy processes that once worked to begin timing out.  This is why all functionality should be built with one clear eye of efficiency and sustainability.  Slate is extremely flexible but any transactional database needs to be nimble as well to complete operations effectively.

Reporting

Reports can be embedded inside of any portal using the portal editor.

      1. It is recommended that anonymous/guest is not chosen when sensitive data is displayed.
      2. Using reports in portals provides independent analysis of specific data.
      3. It also provides a wide range of aggregate data regarding their assigned populations, whereas queries show lists of records with details.

Querying

      1. To add filter-based search in portals, you must be comfortable with editing HTML, JavaScript, and custom SQL snippets.
      2. The parameter type must also match the type of data being passed into the query. For example, if you are selecting an option value of a prompt ID in the portal filter, the parameter will be a unique identifier. If you are passing in a bit prompt (i.e. 1 or 0) or a free text value, the parameter will be a string.
      3. To leverage Liquid looping in portals, and thus the table view widget, your query must have an output node.

Preferred Partners and the Community Forum

      1. Technolutions staff will not be able to build custom portals on your behalf. Technolutions staff will be happy to assist and advise you in the construction or modification of a Slate portal, but someone on the school's staff will need to take the lead. This should be someone who has, or is willing to learn, basic web development skills using HTML and basic knowledge of SQL.
      2. If you deviate away from standard Slate portals, the Service Desk may be limited in providing support. The Service Desk is unable to write or provide support for custom SQL solutions outside of standard identity filters, custom CSS styling, or custom JavaScript. These things should be done by your web development team and maintained by your institution.
      3. Feel free to reach out in the Community Forums to see if other institutions are working on similar portals as yours.
      4. For customized portal and maintenance, you may need to reach out to a Preferred Partner for further assistance.
      5. Please review the Troubleshooting Portals documentation before reaching out to the community for assistance.

 

Was this article helpful?
0 out of 0 found this helpful