How can you decrease load times on large Catalog Items?

[Shane J]

We have (at least) one exceptionally large Catalog Item used for requesting new computer/systems access.   It currently has the following, with little chance of any of these numbers decreasing:

• 120+ Catalog UI Policies
• 10 Catalog Client scripts
• 450+ variables

The problem is load time.   I have seen Requested Items or Catalog Tasks that have the Request Variable for this form take 10 seconds or more to load.   Since essentially one team works on these, their love of SN is wavering quickly.  

So I'd like to know how others are handling this same issue?   I'm not even sure how to attack it at this point.

[ProbirDas]

One thing to look at would be the client scripts, whether any server side calls are being made. Server side GlideRecord queries can be replaced with asynchronous GlideAjax calls.

Also, about the variables, you can check whether some of these are redundant. In ServiceNow, we have the reference field. Fields such as Caller's first name, Caller's last name, Caller's phone number can be replaced by a single reference field

[Mike Malcangio]

I'd love to learn more about why the form has 450 variables -- even with UI policies, client scripts, etc. -- it's got to be a pain to fill out. I see this with a lot of customer's where rather than creating a Service Catalog, they've recreated previously existing web forms in the Service Catalog. What I try to advise our customer's is that's not what a Service Catalog is about. No one comes to IT for a software request form -- they want Photoshop -- it's not a hardware request form -- it should be broken out by the specific things that you're customer would search/browse for -- laptop, desktop, mouse, etc..

You have to try and balance the needs of the customers to find what they want with collecting the necessary information so that IT/HR/etc. can complete their task without necessarily having to go back to the customer.

I'd recommend reviewing the form and breaking it up into smaller bits for the following reasons:

• Workflow -- if you have a bunch of variables which are keying off multiple branches of a workflow -- you probably have separate items.
• Integration -- if you have different integrations at the end -- you're probably dealing with separate items.
• Form Information -- if you're building a bunch of show/hides and cascades between variables as you determine exactly they want -- you probably have separate items.
• Reporting -- If you want to break out the information into reports. Try to think of the lowest level that you'd want to chart the information in -- for computers -- do you care if they requested desktops or laptops or is computer good enough? Do you want to know 13" vs. 15" MacBook Pros? If you bury the information in variables it raises the difficulty for pulling the information out later.

Hope that helps!

[BryanS413339635]

Mike hit the nail on the head about the Service Catalog, we saw the same thing at implementation. You can always break out items as he described and then still have one larger item in the form of an Order Guide for those people who need multiple items but don't want to fill out multiple forms. For example we've got an item for ordering a computer, gaining access to systems, phone lines...but then also have them all captured in 1 order guide for new when someone is a new hire and needs all of these things...Even though combined the order guide might contain hundreds of variables, they are technically still individual forms and display separately to the user so load time shouldn't be an issue.

[wirachat]

Very nice.