List V3 Going the Way of the Dodo?

[Paul Curwen]

List V3 has always been an issue since it's release with lots of customers mentioning its performance issues. For those of you using still using List V3, or are planning to do so, there is a clear message in the London Release notes on this page:

https://docs.servicenow.com/bundle/london-release-notes/page/release-notes/summary/rn-summary-upgrad...

additionally on this page:

https://docs.servicenow.com/bundle/london-platform-administration/page/use/using-lists-v3/reference/...

the advice is:

Reading between the lines, it looks like List V3 is going to be deprecated in a future release. So now is probabaly a good time to start planning how you are going to deal with this if you are currently using List V3. 

[Chuck Tomasi]

To be clear, we won't be taking it away from any instances that currently have it activated. We just won't make it available to activate starting with London. Personally, there are some features of List v3 that I find very useful, but in light of the number of problems it has, development has decided to go in another direction.

[younes_sebti]

Hello Chuck,

Sorry to comment this a year later.

I was evaluating list v3 actually. We wanted to test the impact activating it and using it only on a few related list (I would deactivate list v3 on all related list every a couple).

I see no impact on the server performance (checking the servicenow performance homepage). However I see a few differences on the UI. Difficult to evaluate without pushing to prod.

You are mentioning that ServiceNow is going another direction. Where would that be?

******* Additional literature *******

We have a special use case.
Some of our users are creating change requests with a lot of affected CIs. We have implemented a rollup system using the CMDB. When you add a "service" to your change a business ruleschecks the CI and search for some related CIs in the CMDB. These will be added as affected CIs to the change.

It sometimes takes a lot of time before the change gets created and the user to be able to edit the change. For this reason I am evaluating list v3. The change request will be created immediately and the related list will load after.

It still take time before the user can edit the change, but at least he/she/it can see what happens.

[Chuck Tomasi]

The new direction for lists is the workspace technology (a.k.a. now branded Now Experience.) 

List v3 was abandoned because it had too many bugs in it. Personally, I liked it and wished it would have gotten more support, but I don't make those decisions.

[younes_sebti]

Thank you for this feedback.

We have studied a couple of times this application. It requires some investment to set it up but it looks promissing.

I ran a few tests yesterday.

I was opening a form on agent workspace (a change request). I updated the change  and the affected related list in another session.
Lists are not updating live. Is there an property to activate? Or something?

[Chuck Tomasi]

I don't know of a way to make workspace lists live. I'm not sure I'd recommend it either.

Having implemented live lists in other places (Service Portal), I can tell you they are prone to performance issues. While easy to implement, anything updating the list en masse can cause serious issues with your live list.

Let's say you've got a live list on a list of outages. Someone uses a script or VTB or something else to update the order of the existing issues because one has now been closed. Your live list has to react to every change on every record, which could take a very long time.