Troubleshooting Service Portal customization IssuesSummaryThis article will help you troubleshoot and fix some common Service Portal issues, possibly due to customization, like the following: Portal Search not workingPage throwing an error for failed widgetCloned widget failingKnowledge portal widgets failingReleaseAll supported releasesInstructionsBasic service portal architecture: Service Portal consists of these components: Portal ConfigurationPagesWidgetsWidget Instances Issue 1: Portal Search is not working Check the search source in the related list (Search Sources) under the portal record.Search for the KB & catalog types that are defined under Knowledge Bases & Catalogs related list.For catalog items make sure that the item is visible in service portal. You can add the column Hide on Service Portal in the sc_cat_item list to check if the value for the item is true/false.Make sure that the tables are indexed regularly.If any search term does not show up in portal, try searching with the same term in platform and compare the results. Another very commonly occurring issue with portal search using custom widgets is that some articles or the item does not show up. It does show other articles and items.The simple way to validate if the user actually has access to the KB Articles & Catalog Items is by: Capture the name of the record that the user is trying to search.Get the name of the User who is trying to search.Get the name of the article or item that is not showing up in the search.Now go to either Service Catalog > User Criteria Diagnostics or Knowledge > User Criteria Diagnostics In case we find that the user has got access to the article and item, and they can be found on platform UI, the issue has to be with the widget code, which queries the tables to retrieve the records.A way to check this is the following: Step 1: Get the sys_id of the article or item that the user is trying to search. Step 2: Go to the portal, and try opening any article or item that the user has access to and can be searched in portal. Step 3: The URL holds the sys_id of the record being rendered. Step 4: Replace the sys_id captured in Step 1 and see if the record is displayed. If the record is shown, then widget code needs to be debugged. If the record is not shown, it could be ACL or BR. This can be validated by User Criteria Diagnostics. Issue 2: Page gives an error message for widget failing. Check if the widget is customized or an OOB widget.If it's a customized widget, can the same be achieved using an OOB widget?Try deactivating the scripts and/OR removing variables one by one to check which one is causing the widget to fails.Another root cause could be invalid variables or variables within a variable set in the catalog item. By invalid we mean that: For a reference field, the referred table is not present. This could happen if the catalog item was moved from another instance using update set or XML.If the variables have duplicate names.If a UI Policy or policy action is referring to a variable which is actually not present in the catalog item.Improper placement of containers. Issue 3: Cloned widget failing. Check if the dependencies - Angular Providers & Angular ng-templates are same as the OOB widget.If the above is not the root cause, then check if user is accessing the portal through a custom portal other than /sp.If customer is using a custom portal, then validate the below steps. The above steps were wrt to the portal pages. You might also want to check the same from a widget perspective. To check the same from a widget perspective. you can follow the below steps. Additionally, if the issue happens with /sp also along with their custom portal, one good step would be to check in $sp.do. If the issue does not happen there, then it is probably related to a custom dependency in Dependencies table with ‘Include on Page load’ set to true.Related LinksAreas to look into: If the above steps do not help in fixing the issue, switch to SNKIT and verify what other widgets are being used. Remove all the widgets, and just keep the required ones on the page. If the page loads now, add the widgets one by one to validate which widget is failing.You can also debug the server script by adding $sp.log to check which line of the widget is failing.If there are issues regarding the visibility of data on a field on portal page, validate if the same data is visible to user on normal platform layout. Also validate the roles that are given at the page and widget level, as they can also restrict the visibility of data.For certain records, do validate if the portal is trying to load a specific view. You can check this by looking at the URL. You can also try checking the view rules.Make sure to not be using a deprecated widget (OOB or customized).In case of issues related to display of widgets overlapping, icons overlapping, images or icons not loading properly, start by checking if the portal theme has been modified. Also check with the page and widget HTML codes to narrow down the issue. You can validate this through the browser inspect option. When the page loads, you can check with the attributes that are loading in the Styles section. Make changes in the HTML by inspecting the field and see if this fixes the issue on the page which is rendered.For CSS related issues, refer to the product documentation Service Portal styles which shows the hierarchy of styles applied in Service Portal. Try reverting to OOB themes and check if that resolves the issue. Knowledge Articles you can refer to for Portal performance issues: How to identify a slow widget on a pageSix common performance pitfalls in Service Portal and how to avoid them