Practically speaking, a portal is just a Composer page. What sets it apart from other Composer pages is how you configure it and how users access it. In this article, we’ll go over the distinctive features of private portals, including:
If you’ve decided to create public portals, you can skip the following steps and go to Best practices for portals.
Set up access-controlled pages
If you don’t already have a landing page for your portal, create a new Composer page and follow the instructions in Restrict page visibility to groups or roles to limit access to a single role.
On the Access Control tab of the Page Settings menu, select “Constituents Only,” and then click “Select Groups” to choose the role for that portal. Click on the first arrow to expand the “Roles” section, then select that role.
In this case, it is better to give access to an entire role, rather than a more limited group. Landing pages (outlined below) are configured for an entire role, so you don’t want any of your constituents to land on a page they cannot access.
Best practice: Where to put your portals
The location of your portals depends entirely on the setup of your site, but most organizations find it helpful to put them in their own branch.
If you purchased portals during the sales process, the Portals branch is usually created for you with the rest of your site. You may need to create links to the Portals branch, if your header or footer navigation points to them, which can be done with a linked page.
Configure landing pages
What makes portal pages different from other access-controlled Composer pages is that you can direct your constituents there as soon as they log in. Each role has one designated “landing page” per domain that they will be sent to after successfully logging in. By default, it is the homepage, but you can set it as a portal page instead.
In the Domain Settings for your site, change the landing page for each role in Constituent Manager using the steps outlined in Set Portal (Role) landing pages.
Create usernames and passwords
In order for them to log in and access your portal page, your constituents will need to have portal accounts. Depending on how the constituents are populated in Constituent Manager, including whether you have already created their profiles, the procedure will be different.
If you only have a few accounts to create, you may want to do so manually, or you can include usernames and passwords as part of a constituent datasheet upload. Both of those methods are described in Creating usernames and passwords.
On the other hand, if your constituents already have an account through your student information system or another site, it may be possible to authenticate users that way. To find out more, go to Integrations and single sign-ons.
Once your users have accounts, they’ll need to know where to log in. Every site has a login page, usually located in the Utility branch and accessible by adding /login to your site’s URL.
The login page includes an Account element, which you can customize according to your needs. You may want to add specific instructions for logging in or resetting passwords, for example.
Any site visitor who encounters an access-controlled page on your site will be redirected to the login page. Since the system doesn’t know who you are before you’ve logged in, this is a universal page across all roles. You can place an Account element on any page, however, and users will always be taken to the landing page for their primary role.
Once you’ve created and configured your portal pages, the sky's the limit for how you set them up! Check out our article on Best practices for portals for more ideas and inspiration, or find out the best way to preview your portal in Preview role-restricted content.
Please Sign in to leave a comment if you don't see the comment box below.