Service Portal Page Development Best Practice..

ryanwoodburn · ‎01-03-2018

Hi All

I recently built a quick proof of concept for our service portal, and I have since re-cloned the environment and we are now starting to build our portal.

During the proof of concept, I would take a standard page, copy it, and develop my copied version. The one issue with this, however, is that certain widgets are set to bring you to certain pages, which are always the standard pages. At times I struggled to modify these widgets to point to the newly developed page (using a copy of the widget of course).

E.g. a simple list widget points you to a certain record page, which will work perfectly with the breadcrumbs widget. (I can get this one to point to the correct page, but it's a simple example)

I am considering building our new portal by editing the original pages (saving a copy for rollback), as opposed to editing copies of the original pages.

Does anyone have any recommendations for or against this?

I was also wondering how this would be affected when upgrading / patching - i.e. how likely are the portal pages to be updated, and if I have edited the original will SNow still update the pages?

Any help appreciated!

Thanks

Ryan

ChrisBurks · ‎01-03-2018

Hi Ryan,

I'm not so sure if ServiceNow performed updates that it would be directly to the pages. The pages only act as containers. The real update would be to the widgets.

You have to remember that when you place a widget onto a page it not actually the widget that gets rendered but the widget instance that points to the actual widget.

Edit:

One other thing that isn't apparent is that widget instances have an Active flag on them. You can see this by either looking at a list view and pulling that field in or doing a righ-click view xml while viewing a widget instance record. So one way of preserving the oob page is simply setting the Active flag to false and then pulling your custom widget on that page. You'll just have to remember that if you need to see the oob widget work you'll need to go back to the widget instance record and flip the Active flag back on.

View solution in original post

ryanwoodburn · ‎01-03-2018

Nice idea!

Thanks, and good point re the widget instance. It will be interesting to see what additional functionality comes with future realses.

Thanks all for the help

miriamberge · ‎04-24-2018

I'm wondering if you can share what approach you ended up taking? I've just started working on portal and part of it was already built using mostly custom portals and pages. Some of these pages still direct back to out of the box pages though and it makes me wonder what the best practice is in terms of just using the out of the box pages where we know the breadcrumbs will work or creating copies of the out of the box pages and trying to redirect to the proper custom pages, if that makes sense. Any insight you can share? Thanks!

ryanwoodburn · ‎04-25-2018

Hi

I have ended up using none of the standard pages.

I do, however, try to keep the page IDs standard.

I.e. if I am making a new request page, I will add a suffix to the old request page's ID, and then build my custom page with an ID of request

This allows the standard widgets to still work if I use them. Generally with widgets, however, I take a clone and use my own version. This just allows me to tweak them as and when required.

Hope that helps

Daniel Pettet · ‎05-02-2018

Modifying the baseline pages are bad for a few key reasons:

Any portal making use of this page can no longer expect the baseline version. Remember that pages can be used in any portal.
There is a slight risk that the page is updated in future. It would be better to create your own page to compare with baseline in the future (eg upgrade debugging).
It's hard to identify if the page has been customised or not unless you open it up in the designer. If you create a new page you should have a unique page ID (URL) that is prefixed with your customer dev prefix (eg, "toy_" for Toyota). This will help with support and maintenance efforts.

I would not recommend using the "active" flag on a widget instance as this can create maintenance confusion. It could even potentially create a performance risk if an in-active widget instance was still to be say processed on the server side but not rendered on the client side. Although clever, it's un-intuitive. Deleting the widget instance is cleaner or as mentioned above, simply create a new custom page via the "Clone Page" button.

Steve Brandt · ‎01-15-2019

This is late information for the question but if you find this conversation from a search, as I did, this may help. ServiceNow has helped address this issue in London with "Page Route Maps" in Service Portal. Maps provide an easy way to redirect links pointing to a oob / baseline page to your new custom cloned page.

From docs.... Multiple widgets in the Service Portal may link to a single page using a hard-coded page ID. If you want to replace the page, all widgets that reference the page must be updated with the new page ID. Instead of cloning and updating each widget with the new page ID, you can create a single record that automatically redirects all references to the original page to point to the new page. This way, you can replace a page without locating and replacing all references to the page ID.

https://docs.servicenow.com/bundle/london-servicenow-platform/page/build/service-portal/task/reroute-page.html