Is your custom widget the cause of your Service Portal issue?Issue <!-- div.margin { padding: 10px 40px 40px 30px; } table.tocTable { border: 1px solid; border-color: #e0e0e0; background-color: #fff; } .title { color: #d1232b; font-weight: normal; font-size: 28px; } h1 { color: #d1232b; font-weight: normal; font-size: 21px; margin-bottom: 5px; border-bottom-width: 2px; border-bottom-style: solid; border-bottom-color: #cccccc; } h2 { color: #646464; font-weight: bold; font-size: 18px; } h3 { color: #000000; font-weight: bold; font-size: 16px; } h4 { color: #666666; font-weight: bold; font-size: 15px; } h5 { color: #000000; font-weight: bold; font-size: 13px; } h6 { color: #000000; font-weight: bold; font-size:14px; } ul, ol { margin-left: 0; list-style-position: outside; } --> Symptoms Occasionally, customers will discover that a page or function within Service Portal no longer works as expected. Symptoms can range from a form not submitting to a page not rendering correctly. Release All supported releases Cause One possible cause of these issues could be a custom widget. Customers frequently clone out-of-box widgets and modify them. This is especially common with Service Catalog widgets. As the base Service Portal architecture evolves and out-of-box widgets are updated, the custom widgets that were cloned from previous versions are no longer compatible with the new functionality and do not provide the expected results. Resolution An easy way to test whether the custom widget is the cause of the issue is to create a test page in Service Portal and add the latest version of the widget from which the custom widget was cloned. If everything works without issue then it can be assumed that the custom widget is the culprit. The customer can then use the latest version of the widget as a starting point and re-add their customizations incrementally, testing along the way to ensure everything is working as expected.