OneVu has a powerful in-built function that enables you to create 'sub-portals' that compared with the 'Master OneVu Portal' can:
- contain different content
- have different forms available
- have a different URL
- have a different header/footer
- have different branding i.e. styling
Also for public-facing portals, users can use the same login for each saving time/improving UX.
So as an example you could create a Business Portal, which has its own URL, only departments/forms pertinent to businesses showing, and for the portal to have different branding E.g. Blue instead of Black header as an example. As well as say 'My Business' to appear in the header in place of 'My Account' with a custom header.
Plus, recently we thought of a different way to use this, which is to enable Customer Services to have access to content which citizens do not. The approach if this is desired is to make the sub portal the one that citizens access. I.e. the sub-portal is actually the one citizens access and they only see a subset / reduced set of content.
What this means is citizens cannot see departments or forms that you do not want them to be able to access. Vis-a-vis customer services can access forms only they have access to.
Below you can see how the branding and even the location of the menu has been placed in a custom footer in the customer service view vs the public-facing view:
Customer Service View
Public Citizen Facing View
In the above multiple parts of the 'Portals' functionality has been used to ensure the header is different, the navigation is done differently and the URL is different. We will walk through how this is all done below.
Portals
The Portals function can be found within OneVu Control (Manage) as shown below:
The Portals Admin Screen
When you first go to this screen there will be no portals set up as, remember, these portals are sub portals of the master instance that already exists.
When you click to add a Portal you will be presented with a screen to request the name of the Portal. You can see that there is also the option to 'Add Host Name' at this stage but we'd suggest doing this afterward:
When you've created the Portal you'll see there are five tabs that control the functionality specific to the Portal you've created:
- Silos
- Forms
- Service Requests
- Host Names
- Appearance
The following explains each.
Silos
Silos are effectively council departments or rather organised and obvious sections of content. For example Council Tax, Benefits, Waste could be silos. Housing might be one silo or it might be two depending upon your preference e.g. Housing Rents/Accounts is silo 1, Housing Repairs is silo 2 and Useful forms is silo 3. This latter approach lends itself when a sub portal is being provided for a specific function.
The functionality provided within the Silos tab enables you to choose which Silos should be shown. You can see below that for a Business Portal the options of Council Tax, Benefits etc. are not checked reflecting the fact that businesses would generally not be interested in these.
The power of this is that it means:
- A sub portal can show different content to the main portal
- Different versions of silos that the public see versus internal users
- i.e. you could have additional content in the master portal that customer services see but not citizens.
Forms
This simply allows you to restrict the forms that are available within the sub portal. So within our Business Portal example, we can list only those forms pertinent to businesses as shown by the screenshot below:
Service Requests
Service Requests relates to trackable requests in OpenProcess. This area is less relevant than the Forms function, as technically a person can't track a process if there is no related form to complete.
The reason this exists is that technically you could have a citizen that has both a citizen and business portal account. In the citizen portal, they complete a trackable process that would not be possible to trigger in the business portal. So when they login to the business portal only those related to businesses will be shown.
Host Names
This section is the most important of the set up of the portal. The Host Name is effective the URL that should be used when one wants to access this portal.
This is important because this needs to be set up by both the council AND IEG4. I.e. you can choose what you want the hostname to be but we need to ensure our set up is aware of this and the network rules are in place to ensure traffic is routed to the URL.
Host Name
This will be URL you want to use:
Client ID
This can be found by:
a) Going to the main URL for your citizen-facing login screen
b) Click on register for a new account
c) Copy the end part of the URL as shown below:
The important thing is this needs to be coordinated with the helpdesk. So if you want to do this you need to raise a ticket and provide details of the hostname you intend to use as well as any custom CSS - see later.
Appearance
This tab enables you to add customisation of the header, footer, and branding. This is actually quite powerful when you consider that the view that citizens see / customer service staff can be very different if needed.
Customer Header
This section allows you to add a Custom Header in HTML format rather than the one on the main 'master' onevu site. The section that gets replaced is the <nav class="navbar navbar-default"> section:
If no custom header is added the standard header used on the master portal will be used. Note the master portal header is actually only changeable by IEG4 staff so this provides greater flexibility. The above illustrates the different header for the Business portal:
Vs the citizen-facing one:
Customer Footer
The footer works the same as the header in that one can add custom HTML and this replaces the <footer> tag.
If nothing is added then, whatever footer is present (note the default is no footer) on the master portal will be presented. This could be used, in conjunction with CSS, to add a floating menu that appears at the bottom for optimum ergonomics when OneVu is accessed on smaller devices:
Important
JavaScript CAN be added to the custom header/footer sections enabling you to add custom JS without involvement from IEG4. The only words of caution we would provide is that clearly, this means you can technically introduce security issues.
Custom Branding - Add CSS URL
Technically, this is only needed if you want to change the styling of the content without the header/footer, as you can add custom classes for content in Custom Headers/Footers.
If you do wish to have different content branding e.g. hiding the standard nav to use a floating nav then you need to provide IEG4 with the CSS changes and we will add this.
So it makes sense if you intend to do this, to send this as a part of the helpdesk ticket providing details of the hostname.