Service Portal has really allowed developers to flex their web design muscles, but what about using all this new technology within the normal UI? Luckily there is an easy way to achieve this, but first of all let’s consider some reasons why you may want to do this:
- Ability to use modern, more powerful technologies like AngularJS
- You can avoid spending hours buried in obscure Jelly and UI Pages
- You can provide your users with a consistent look and feel across the normal UI and any portals you may have
- You can reuse existing widgets within the normal UI
How do we achieve it? Firstly you would create your page as you normally would within the Service Portal application. Build out your widgets and make sure you have the page looking and functioning as you would expect. For this example I will just use an existing page from the OTB portal called services_status:
Let’s say that we wanted to give users access to this page from within the normal UI, all we need to do is create a new module that has a link with the following arguments:
Where page_id is the id of the service portal page you would like to display when the user clicks on the module. In this example we will create a module called “Service Status” that will live under the “Self Service” application:
As you can see the arguments for this link are “$sp.do?id=services_status” as “services_status” is the id of the page we want. Once saved we will now have a new module under “Self-Service” called “System Status”, that when clicked will display the services_status page from the service portal within the normal UI.
It’s as simple as that!
A couple of things to note:
- The header/footer is not included because they are associated to the theme and the theme is associated to the portal record. Pages have no relationship to portal records within service portal. In my opinion this is a good thing, otherwise you would end up with double headers.
- For the same reason if you have any CSS/JS defined at a portal or theme level it will not display when viewed using the method above. You would need to consider putting all of your CSS/JS in at a page or widget level.
- “$sp.do” in the arguments has no relation to the OTB sp portal other than sharing a name. So if you created your own portal record with an id of “self_service” and tried to do “$self_service.do?id=services_status” that would not work. Again, service portal pages have no relationship to portal records.