ServiceNow Service Portal: the bad parts
Every technical decision is “wrong” after enough time. (@anarafaelaferro)
In the first part of this series, I listed several use cases where Service Portal works best:
- OOB End-user portal and Service Catalog
- Documentation
- Dashboards and interactive pages
- Simple web applications
In your ServiceNow development practice, you may notice that Service Portal does not always address your needs in the most efficient way. It may not fit well with the complexity of your project or put too many limitations and enforce proprietary API.
Service Portal is an amazing, revolutionary and innovative part of the ServiceNow platform introduced in 2015. You may think that today is 2018 and it’s just 3 years old, but in fact, there is a big gap between today’s web development and Service Portal. The further we go with new and advanced web concepts and frameworks, the far behind Service Portal remains.
We are developers. The developers' community is a foundation for the ServiceNow platform; we all want to grow, improve our experience with modern technologies and be demanded professionals. That means you need to start looking beyond Service Portal when building ServiceNow applications.
I want to point out 4 different aspects of Service Portal, which are very important to think about, as they would drag you away from modern web development concepts and technologies.
1. Technology stack
Service Portal is based on AngularJS. It’s an 8-years old legacy framework, which is not compatible with the most recent versions of Angular and does not address today’s web development needs. In fact it’s a dead end, still supported by Google but only because there are tons of legacy applications exist.
AngularJS is NOT the same thing as modern Angular. Don’t be confused.
And it’s not only AngularJS. Service Portal enforces specific development concepts and proprietary API, which you have to be familiar with in order to build web applications. That might be another dragging point, especially when ServiceNow documentation does not cover everything.
2. Development pipeline
Service Portal development pipeline is simple and straightforward: there is no pipeline.
You just define a portal, pages, and widgets; everything is stored in ServiceNow, you cannot simply export and host it somewhere else. As I mentioned before — that works perfect for small apps and pages, but it’s not something the modern web development community would understand and appreciate.
With Service Portal, you are locked inside of ServiceNow IDE, and if you want to use VS Code, Atom or any other code editor you may have a hard time trying to integrate it with ServiceNow.
Service Portal application footprint may surprise you — “hello world” app requires multiple entities (portal, columns, rows, widget, widget instance).
Another drawback is that you just cannot copy/clone your entire web application. You can copy/clone a widget, but not the entire application. When you have a portal with 3–5 pages and want to copy/clone the portal and use it with some modifications for another department, the only way to do that is to manually copy-paste the code (!).
And then git. ServiceNow provides git integration, but there is one huge problem (it may be already fixed though) — every time when you pull the updated code from git, ServiceNow wipes out the application data. That would be a critical showstopper for most of the projects.
Git integration works fine for backup purposes and when you need to install the application on another instance. But if you want to review commits and changes, collaborate on something — it just doesn’t work in the way professional developers expect it to work.
3. Open source and external resources
Open source is a major driver of modern web development. It’s about the ability to contribute/share your code and ability to utilize the code from other developers.
Of course, you can share your Service Portal code/widget/apps, but the problem might be the way how you do that — you package it in a ServiceNow specific format. Team collaboration and contributions may be challenging, especially in open source community.
Using open source libraries (actually any external libraries) in Service Portal is fairly simple — you just link the library as a dependency or directly in a widget code.
But again — we’re talking about AngularJS and it’s not a modern web development framework anymore (like it was 3 years ago), so you will not find any new component library. And even if you found the javascript library you want, you may face technical issues with running it in Service Portal.
4. Developers Community
ServiceNow platform is growing, the community is growing, but Service Portal in its technology stack remains the same as it was 3 years ago.
Service Portal supposed to be the most exciting part of the platform. It supposed to attract front-end developers so they can extend the platform building amazing web pages, components, and interfaces.
And it worked... until today.
When I try to bring people (mostly front-end developers) into Service Portal I see a big problem — they don’t want to go there. And for the most intelligent and experienced people, the reason is always the same — technology stack.
They are all for JavaScript, but being locked with AngularJS — sorry, no. It is clear that they won’t be able to sell Service Portal knowledge and experience outside of the ServiceNow market because Service Portal today is way behind modern web development.
If Service Portal does not catch up with today’s web technologies — you’re out of the game of ‘modern web development’.
Short resume for the good and bad parts of Service Portal: Service Portal may work extremely well and be the best option in some use cases. But If you want to go beyond standard Service Portal options and work on advanced web applications and interfaces — it may not fit well.
I expect a reasonable question — if not Service Portal, what options do we have?
And there is a surprise… you can build ServiceNow applications with React, Vue and Angular.
That is a whole different story, which requires a new series of articles and, which I believe, may significantly shake ServiceNow development community.
