Introduction
Claromentis can be configured to allow guest/public users (those who are not logged in) to access limited areas of your intranet. e.g. stakeholders need to view certain documents, or have a landing page that details information specific to them.
Public users cannot perform every action a logged-in user can, or access every application.
Depending on your use case for public access, a suitable set-up can likely be achieved to meet your aims, but it will need to be tested thoroughly for the specific applications/actions you want them to be able to perform to confirm this is a viable option.
The alternative is to give everyone you want to access the site a login.
Only the Claromentis team can turn public access on/off, so please raise a support ticket if you are interested in changing it for your site.
What can a public user do?
A public user can perform certain actions that do not require them to log in, however, some actions are reserved only for those with accounts.
A public user can:
View a unique theme (set for public users)
View a homepage
Access/open other pages
View/open menu items
View News channels (and their articles)
View Knowledge Base categories (And their articles)
Submit Infocapture tickets (the 'submitter' will display as 'guest user')
View & download documents
View images/albums in Gallery
A public user can't:
View any content where the public permission is not included
Create any content, e.g. News, KB, Blog
Open user profiles (but they can see the users listed if the People List component is placed on a page)
Upload documents
Post in Discussions
Undertake eLearning
Comment on or like News
Comment on or like KB articles
View or accept policies
Take a Poll or Survey
Be targeted by Announcements
This is not an exhaustive list, so if you are thinking about using public access, we can always turn this on for you so you can test what a public user can do and check if it fits your goals.
Otherwise, if you need them to perform certain actions, those users will need to be given a login instead, which takes up a user license.
Here is what happens when guest / public access is enabled
1. The "Public" permission will now be available to type into the permissions boxes across the Intranet. Your team can place this in applications or content permissions to give users who are not logged in access e.g. making a folder and its contents publicly accessible
2. Decide how you want to set up the access
Will you be directing public users to just one page that is 'theirs' by supplying them with a direct URL, e.g. in an email, or do you envision them seeing a homepage, which may or may not differ from the one for your employees?
This decision impacts how you now set up the site and enter the 'public' permission across applications and content to give access to it to public users.
e.g. is a new theme, homepage, buttons, menu needed that only includes public items? or will one public page suffice
3. What content and which applications do you want Public users to access?
Will public users simply be viewing information on a page or do you wish them to perform certain actions e.g. download a file.
Some applications will not allow public permissions to be entered into them, others they can only be given the 'view' permission.
Some components will also not show their content to public users when placed on a page, whereas others will.
4. Configure what guests/public can access
Add the 'public' permission across the applications or areas you want public users to be able to view or interact with.
e.g. give 'public' the permission to 'view' your desired pages, documents, menu items etc
4. Test
Log out of your Intranet and access the public URL(s) you have set up for use.
Check you can see and interact with everything you expected to as a public user and make tweaks to your set-up (once logged back in!) as necessary.
Public access and the mobile app
Everyone, when opening the app, will be prompted to log in.
So, if you want to use public access on mobile, you will need to create a public homepage and set this in a theme to appear publicly, so that is appears in the app before the log in page.
This means the public content appears when the app is opened, but anyone who needs to can still login with their details.
Without this set-up, public users cannot use the mobile app to access the content you have made public because the login page appears first.
SSO
If you have the custom app with SSO also set up, we recommend turning this option to 'no' in the login handler:
It will ensure local accounts can still log in through mobile, but public users will view the public homepage.
