Skip navigation

Developer Community

4 Posts authored by: Matt Metten Employee

choices.jpgWith the introduction of Service Portal in Helsinki, those who had spent the last few years knee-deep in CMS development and wrestling with Jelly/iframes rejoiced! Finally, there was a modern solution for elevating the end-user experience.


Virtually every customer or partner I have chatted with around Service Portal has asked the same question: Is there a migration plan from CMS? With good reason. With checks still being cut for CMS development, how do you not lose out on all that work you did to get to the new portal?


The short and unfortunate answer is: there is no migration path. It’s a completely new technology and runs in a whole different way:


  • CMS uses Jelly, Service Portal has AngularJS
  • CMS has layouts for HTML, Service Portal uses Bootstrap
  • CMS requires iframes for forms, Service Portal has built-in widgets for that to render within the page


So programmatically it’s all different. That dynamic block that you spent days working on will need to have about 90% of it ripped out and replaced. Why 90%? Well, you can take advantage of some of the server side scripting and styling that you put in place for use within your new widget.


Style wise you might be able to salvage some of the work you’ve done if you previously designed for Bootstrap. You can use the same CSS which might save some time.


Translations, messages and system properties can be retained, but need to be adjusted at the code level as to how they are used.


That’s about it, unfortunately.


Menus have to be rebuilt, custom JS or jQuery you have will need to now work within a context of Client Scripts on your new custom widget. Pages are a whole new beast from a layout perspective (no more templated layouts), and even URLs are going to change.


It’s a whole new world!


However, asking how to move from CMS to Service Portal might be the wrong question.


To me, it’s better to think through:


  • How do we translate our current functionality (dynamic blocks, lists, etc.) through a lens of Service Portal out-of-box widgets? More than likely you’ll find something that’s close. That will save you some time and will help with future support and upgrades to stay close to OOB.
  • Do you have any customer feedback to incorporate so you can approach this as more of a 2.0 release? If you want a straight swap you might be missing out on a great opportunity to make some improvements.
  • Will you gain by moving? Sure, the new technology is fun and exciting, but what is wrong with what you have now? Identify that before you make any moves so you know when you’ve been successful. That being said, it’s worth your effort to move towards Service Portal. CMS is going to be retired at some point (there are no plans for any development on it for the near future) so instead of moving when you HAVE to move, start thinking through now how to get from here to there.


With what you have available to you out-of-box, I bet you’re closer than you think.

Let's connect:

iceburg.jpgFor the past six months or so I’ve been gallivanting around the world with a crew of folks teaching, evangelizing, discussing the new Service Portal application that came out in Helsinki. Without a real solid training program out yet (though it’s coming soon!) we basically created our own to help the internal folks, partners and customers get up to speed on Service Portal.


There is so much that I’m loving about Service Portal:

  • No iframes. I could just stop there.
  • No Jelly coding. While it has meant I have a learn AngularJS, I’m glad for the community to not be restricted by such an obscure programming language.
  • Pixel-perfect sites. I can get a portal to look EXACTLY as I want it to be. I’m not sure there’s another enterprise UX tool out there with so much flexibility.
  • If I can dream it, I can build it. Angular opens so many doors to interactive and modern experiences. You marry that with the power of the platform and you have something pretty exceptional.


Sure, there are some bugs and things that are being worked out, as I would expect with any recently released product. If I compare what we had (CMS) with what is there now, no contest.


That being said, the solution for all your enterprise service management (ESM) woes is not Service Portal (SP). By that I mean, SP is just an application within a much larger and powerful platform. It’s the vehicle that is going to take your ESM to a whole new level. You are not just going to magically fix all your problems because there are some great out-of-box widgets to use.


Once you have your strategy in place, SP gives you the opportunity to make some real magic. But at the end of the day, if you have a form with 100 fields that are all mandatory to be filled out before a Catalog Item can be submitted, that’s not a SP issue.  If your site looks beautiful and responsible and branded you have definitely accomplished something great, but if people can’t get to what they are looking for when they search or have to click through seven levels to find that one service, you’ve missed the mark.


Much like an iceberg, the true challenge of launching an enterprise portal lies beneath the surface of interface. Sure, learn the new technology and become incredibly proficient at deploying widgets and spinning up beautiful portals. But you also have to consider a few things if you want to truly transform the customer experience:

  • Why do your users come to your site? What are they hoping to achieve/accomplish/find?
  • To the business, what value is a great portal? What is the cost to one that under-performs? How will you know?
  • How come the portal is the way it is now?
  • Do you have a baseline of who is using the portal now? Which pages are they going to? Which articles are they reading? Do they give up somewhere along the way?


Service Portal does allow you to seriously improve the impression your portal will give your end users. Take the time as you move towards that 2.0 release and make sure you are not just swapping out one mediocre experience for another that just happens to look a bit better.

Let's connect:

Service Portal in Helsinki has opened up a new world of UI opportunities. The modular nature of functional widgets which combine AngularJS, CSS/SCSS, Client scripting and Server scripting has unleashed a whole new level of creativity. Already in Share you can find a bunch of new widgets and it’s only beginning. However, the functionality that you're seeing is no longer restricted to just the Service Portal experience.


One key feature to understand is that your Theme (Header/Footer, CSS and JS) is attached to your Portal. When you navigate to your Portal suffix it then knows to serve up the page, including the Theme defined at the Portal record level.


Here’s what that looks like:

Standard page served up within a Service Portal’s theme (in this case, a specific Catalog category):


The URL for this is: {your-instance}}

  • Implies a Service Portal with a URL suffix of “sp"
  • Implies a Page ID of “sc_category"
  • The URL drives how the page is built


Now here is a standard page served up WITHOUT a portal & theme (no header):


The URL for this is: {your-instance}$}

  • You’ll notice the $ which is a Service Portal call to serve up a specific Portal Page ID.
  • You’ll notice the /sp/ has been omitted from the URL implying we are not loading this page within a Service Portal (and in doing so without the associated Theme).


HOWEVER, there are 2 other ways you can use this same page:


1. Include the Page within the Theme INSIDE the Platform UI:


The URL for this is: {your-instance}}

  • You'll notice the double-header, however, because you're telling it to serve up the entire Portal by using /sp/ (if that's your Portal suffix)


2. Include the Page WITHOUT the Theme INSIDE the Platform UI:


The URL for this is: {your-instance}$}

  • You see now the header has been removed since the URL does not have the /sp/ which is the Portal suffix which then implies the Theme has been removed.


So what does this mean and/or why should I care?

  • You can now elevate your UI Page experience to be either AngularJS-driven pages served up via Service Portal or as you had them before using Jelly.
  • Build once, use many - use widgets that you're producing for the employee portal within the platform view as well.
  • Design out your own Fulfiller experience if you want! You don't have to wait necessarily for the platform to change UI elements - you can start to build out your own.


It's going to be great to see how people start to take this to a whole new level!

Let's connect:

With the Helsinki release came the introduction of Service Portal. Those of us who have been knee-deep in CMS for the past few years are very excited about this new addition!


Here's a list of 6 things that I have come to love about Service Portal:


  1. No Jelly
    While I'm disappointed to basically have to dump the years of learning Jelly, I'm so very glad to have more modern ways of serving up data. I also am happy for what this will do for the customer base as you now no longer need someone with such a specific skill set to run your portal. Finding AngularJS and Bootstrap developers is WAY easier than finding Jelly specialists.
  2. No More iframes
    Probably the greatest limitation of CMS is the requirement to use iframes for anything involving data (forms mainly). While Service Portal has a bit of a catch up to do on some of the OOB features, the ability to get at the data in a single page view is pretty awesome.
  3. Page Designer
    One of the most innovative UI changes in ServiceNow I've seen in recent years has to be Page Designer within the portal configuration tool. From one view you can build your pages, create your layouts, drop in your widgets, set your options, adjust CSS and define any meta properties you need. You can even preview the results as it will be rendered within various viewport sizes (mobile, tablet and desktop). We now have a very low-code approach to building out portal pages!
  4. Widget Editor
    For those looking to get down and dirty with functionality, widgets are your friend. The widget editor itself is also an amazing approach to development. In one pane you can view your HTML code, CSS/SCSS, Client Scripts and Server Scripts. Throw in some JSON and you can preview your changes. All without reloading the page! You can even set the options for your widget. If you're a pro-code type, this is for you and it's a great improvement from the Dynamic Block days of CMS. And also for you pro-coders, make sure you check out the Github for Service Portal that's being compiled by the product team:
  5. Robust Theming
    When using CMS your theme was basically a collection of CSS files. With Service Portal, you now have the ability to define a header and footer (both widgets by the way - think of the possibilities!), attach any CSS or JS files and set any Sass variables and away you go. You can then share this theme across multiple portals or not. So much more power available to you, in a very simple way of putting it all together.
  6. Analytics
    My old digital marketing tendencies are pretty excited for all the things you can do now with the Log Entries available in Service Portal. Instead of serving up a list of "Popular Items", I can get more sophisticated and refine that list to "Popular Items (of people in my same location)" or "Popular Items (for those in my same role)". Why not? We have the data. Due to the iframe limitation of CMS we never had such portal specific data. I am probably the most excited to see what the community does with this information now as contextual experiences are a given with this new feature.


Hopefully you've had some time to kick the tires a bit on Service Portal. If you have, throw any comments you have below as I would love to hear what your impressions are!

Let's connect:

Filter Blog

By date: By tag: