Access filters can be applied to portals to restrict the records that are allowed to use the portal. Access filters are used in scenarios where only a certain subset of a type of record--person, application, user, or dataset--should gain access to a portal: for example, an Athletics portal to which only users assigned to a role of "Coach" can enter.
To apply access filters to a portal, click "Edit" on the portal's main page, and click the Filter button in the Restrict Access configuration.
For older portals, you might see a SQL Authorization section instead of the Restrict Access configuration. The SQL Authorization is a legacy method of determining whether someone attempting to log in should not have access, and then displaying a message that indicates so.
If you have a portal that is currently using SQL Authorization, we would highly recommend switching to using filters, as this does not require SQL knowledge, and is therefore more sustainable.
- Security - The Security setting of the portal will determine what filters are available for restricting access.
For example, a portal using the "Application" security setting (e.g. applicant status portals) will have access to filters associated with the primary Application query base.
For a portal using the "Dataset" security setting (e.g. alumni interviewer portals), filters that are scoped to the corresponding custom dataset, i.e. filters available in that query base, are available.
- Authorization Fail Custom Message - If you wish to display a custom message when access is restricted, you may add one in the Authorization Fail Custom Message section right below Restrict Access.
Filter in the Affirmative
Filters added in the Restrict Access configuration should point to the "affirmative," i.e. who should be allowed access, based on attributes that those records have. Although the NOT operator is available, we discourage its usage and it often obfuscates the nature and results of the filter(s).
In some scenarios, we might recommend using a portal redirect instead of access filters.
For example, you may have two separate portals for applicants (i.e. a custom status portal) and admitted or enrolling students. Instead of adding access filters on the admitted student portal so that it does not allow in applicants who don't have an admit decision, a redirect could be added so that they could be immediately taken to the relevant portal in the same browser window. That is, instead of stopping students in their tracks, they can be seamlessly directed to the correct page instead, which creates a friendlier user experience.