- Debug Now

Article:  https://community.servicenow.com/community?id=community_article&sys_id=69f8ed5fdb0e6784656a5583ca961903 

- Find All Record References https://[YourInstanceName].service-now.com/nav_to.do?uri=sys_ui_action.do?sys_id=78919cd8db36d8505a7090e5db961904__Find%20All%20Record%20References Article: https://servicenowguru.com/system-definition/find-references-specific-record/ - Include in Update Set

Article:  https://snprotips.com/blog/2016/9/7/force-include-any-record-into-an-update-set-in-servicenow 

- Takeaway - A UI Action is a control (button, link or menu item), added to the Platform User Interface to execute some Script. The Script executed may be either Client-Side or Server-Side. You must specify a Table that the UI action is related to. A Condition field allows UI actions to be hidden in situation where they do not apply. After completion of the UI action, you may redirect the user to another page. - Modules

System UI - UI Actions
Studio - UI Action

Creating Interactions with UI Actions UI Actions - A UI Action takes the form of a button, link, or menu item on a Form or List, and is used to make the UI more interactive and customized. - If the User does not need to initiate the action, for example if logic should be run on a record insert or state change, a Business Rule is more appropriate. - UI Actions may be created in the Platform UI or in Developer Studio. - You specify a Table for the UI Action to operate against. - A Condition field may be used to write a short script to Conditionally Show/Hide the UI Action control. - UI Action Scripts may be either Client-Side or Server-Side. Even though UI Actions show up on the User Interface in the Browser, UI Action Scripts, by default, are run on the Server side. The “Client” checkbox is used to specify a Client-Side script, instead. - Redirecting - Use the action.setRedirectURL() method to specify the page to open after the UI Action executes. - Use the action.setReturnURL() method to specify the page to open when the back button is pressed from the redirect page. - There is a very valuable custom UI Action called “Find All Record References”. Importing the XML file containing this UI Action adds a Related Link to all forms. Clicking on the link shows all of the tables where the record is found, as well as the column name, and the total number of references, as well as a link to the table which includes a filter to bring up only the relevant records!! - What are all the types of UI actions called, exactly?

1. Form
   1. Form Button - Regular old button which appears on the form in the header bar, at the top right.
   2. Form Context Menu - Menu item accessed via the Additional Actions menu, or via the Speed menu when you right click in the header bar.
   3. Form Link - Hyperlink which appears at the bottom of the form in the “Related Links” section.
2. List
   1. List Banner Button - Regular old button which appears above the list/table in the header bar, at the top left.
   2. List Bottom Button - Regular old button which appears underneath the list/table, at the bottom left.
   3. List Context Menu - Appears as a menu option when you Right Click any field of a row.
   4. List Choice - Appears as a menu option in the “Actions on selected rows…” dropdown control under the list/table.
   5. List Link - Hyperlink which appears at the bottom of the list/table in the “Related Links” section.

- For the List Type UI Actions, the client side function g_list.getChecked() may be used to get a list of which items the user actually checked.

- Use the function gsftSubmit() to define a UI Action which runs partially on the Client Side and partially on the Server Side. This is every confusing, but sometimes necessary. I wrote an article on this, here:

https://community.servicenow.com/community?id=community_article&sys_id=8f9d48fa1b777c10b00b86edcc4bcbab 

https://developer.servicenow.com/dev.do#!/reference - A ServiceNow JavaScript framework built on web components standards. - The Now Experience UI Framework enables you to build custom web components to create a modern UI for your users - Important: The UI Framework is currently limited to Workspace. - Built on “Web Components'. A “Web Component” is a web standard (new HTML tag). It is not owned by a single company. - Core Concepts / Patterns and Principles

1. Immutable Data
   1. Data / State is Read Only. No other code can change the state object without your direct knowledge.
2. Unidirectional Dataflow
   1. In the UI Framework, an action is dispatched from the View, state is updated, and the updated state is passed back to the View.
3. Effectful code is isolated

- Any code that causes side effects (state updates) should only be run in the “effect” function for an “action handler”. This keeps all other code free from side effects.

https://developer.servicenow.com/dev.do#!/reference/now-experience/sandiego/ui-framework/main-concepts/action-handlers 

http://www.john-james-andersen.com/blog/service-now/example-of-ui-macros-and-ui-pages-in-servicenow.html UI Macros are module, reusable components that can be used throughout the ServiceNow Platform. They are like little “Include” files that can be inserted into pages, forms, etc. They could involve Text, JavaScript, CSS, or HTML. - Contextual Search https://docs.servicenow.com/bundle/rome-servicenow-platform/page/administer/contextual-search/concept/c_ContextualSearch.html
https://docs.servicenow.com/bundle/rome-servicenow-platform/page/build/service-portal/concept/contextual-search-widget.html
https://docs.servicenow.com/bundle/rome-servicenow-platform/page/administer/contextual-search/task/t_CntxtSearchRP.html

- This is an undocumented class which may be used to display a temporary, floating message, at the top and center of a form. It is the same message you see when you create a new update set and set it as your current update set. (That message lasts about 10 seconds.) - Example usage: var uiNotification = new UINotification(); uiNotification.setText(“My UINotification message”); uiNotification.send();

1. Example Screenshot, and comparison to a regular InfoMessage:
   

https://docs.servicenow.com/bundle/rome-application-development/page/script/server-scripting/reference/r_UIPages.html Tables

sys_ui_page

Modules

System UI - UI Pages

- A concept used to create and display a Form, Dialog, List or other UI Component. - May be used as “widgets” on dashboards. - Requires knowledge of HTML and/or Jelly or Angular JS Applications. - Used to create a custom page for an application. Used similarly to how an index.html page would be used, outside of ServiceNow. - Note, UI Pages are implemented with a technology called “Jelly”, and ServiceNow is moving away from Jelly and to a technology called Angular.

1. UI Pages may need to be re-written as Service Portal Widgets.

- Some of the dialogs used in various Platform UI pages, may be implemented as “UI Pages”. For example, if you see “kb_find.do” in a URL, that may be coming from the UI Page “kb_find”.

- Takeaway - A UI Policy is a set of client-side logic for determining when to toggle 3 specific properties of various Form Fields; those properties are Mandatory, Visible, and Read-Only. A UI Policy is executed whenever a value on a Form record changes. A UI Policy is designed to be configurable (without code), but may also include script. There is a “Reverse if false” option which performs the opposite action, if the conditions specified evaluate to “false” instead of “true”. Since a single set of conditions (a single trigger) often results in the need to apply the same properties to multiple fields, many “UI Policy Actions” can be configured for a single UI Policy. The UI Policy specifies the conditions (and optional script to execute), and the UI Policy Actions specify the fields to adjust, and the properties to toggle. Modules [Open any record] - Configure - UI Policies. System Diagnostics - Session Debug - Enable/Disable UI Policies Debug

- When you are making Variables or Variable Sets Visible / Hidden, using UI Policies and UI Actions, and you are also making fields Mandatory / Not, you need to set the ORDER of the Mandatory / Not Actions to a LOWER VALUE (so they run first), because mandatory fields may not be hidden.

- A UI Policy is a set of client-side logic for determining when to toggle 3 specific properties of various Form Fields: Mandatory, Visible, and Read-Only. - A UI Policy is executed whenever a value on a Form record changes. - A UI Policy is designed to be configurable (without code), but may also include script. - There is a “Reverse if false” option which performs the opposite action, if the conditions specified evaluate to “false” instead of “true”. - Since a single set of conditions (a single trigger) often results in the need to apply the same properties to multiple fields, many “UI Policy Actions” can be configured for a single UI Policy. The UI Policy specifies the conditions (and optional script to execute), and the UI Policy Actions specify the fields to adjust, and the properties to toggle. - Conditions for a UI Policy are only re-checked when a user Manually changes a field of a form. If a change is made by a UI Action, Context Menu action, from an Import Set, via Web Services, or through the List Editor, the UI Policy conditions will NOT be re-evaluated.

1. Use Data Policies (which are not scriptable) to manage the Mandatory and Read-Only state of fields for records not changed on a Form.

- One place that you can NOT use UI Policies is on Save/Submit/Update. Since the user will no longer be interacting with the form, it doesn't make sense for a UI Policy to come into play at this point. - Although Fields can be hidden with UI Policy Actions, sections cannot, unless you use Script. - When a UI Policy is executed, there is no post-back to the server. - VS Client-Side Scripts. - Client Scripts and UI Policies both execute client-side logic and use the same API. Also, both are used to manage forms and their fields. - Client Side Scripts, unlike UI Policies, consist of ONLY a script, and no user-friendly (GUI) configuration. - UI Policies do not have access to a field's previous values, like client side scripts do. - UI Policies execute After all client scripts. - Only a Client Script can execute on a Save, Submit, or Update. - Only a UI Policy executes on a List Field value change. - UI Policy Related List actions do not require scripting to show or hide related lists. - Confusing: UI Policies do not have a “Name” field; only a short description. - UI Policy Actions tab - For each UI field you wish to manipulate with a UI Policy, you create one distinct UI Policy Action underneath the UI Policy, at the bottom of the form, in the UI Policy's list “UI Policy Actions”.

1. Each action may toggle one of the following 3 properties:

Mandatory or Optional

	Visible 		or 	Hidden
	Read-Only 	or 	Read-Write

- GGB: I believe a UI policy may also be used to Clear out the value of a field, but it seems like Script may be necessary to do so. - Script tab - Use UI Policy Scripts (Scripts Tab) to take actions other than setting field attributes. You write your custom script inside the onCondition() function, which is called by the UI Policy at runtime. Example function onCondition() {

var x = g_form.getValue("vs_requested_for_item");
//alert(x);
var employeeNumberControl = g_form.getControl("employee_number");

//To Do.  We need to either use AJax to get the actual Employee Number, not the sys_id, from the Server...
//OR we need to use the Scratchpad (if possible), to magically HAVE the Employee Number available to us, already.

//employeeNumberControl.setValue(x); //This does not work on the portal.
employeeNumberControl.value = x;

}

- To turn On or Off UI Policy Debugging, go to System Diagnostics - Session Debug - Enable/Disable UI Policies Debug.

https://docs.servicenow.com/bundle/paris-application-development/page/script/client-scripts/concept/c_UIScripts.html Modules

System UI - UI Scripts

Tables

sys_ui_script

Examples

See these articles that I myself wrote!!

UI Script - Global checkbox = false - Application = Global UI Script - Global checkbox = false - Application = Scoped

- UI scripts provide a way to package client-side JavaScript into a reusable form, similar to how script includes store server-side JavaScript. Administrators can create UI scripts and run them from client scripts and other client-side script objects and from HTML code. - UI scripts are not supported for mobile. - You can create a UI script and designate it as global, which makes the script available on any form in the system. You cannot create a global UI script in a scoped application.

1. But this is not considered a best practice.

- Quirks

1. After you change a UI Script, often you will need to use Ctrl + Shift + Del in order to clear your browser's cached local files.

- Example UI Script

API Name
	oc_platform_ui_utils
Global
	false
Script
	//Call attention to a Mandatory field in a standard way.

function oc_ShowMandatoryField(FieldToHighlight, MessageForDisplay) {

		var ocOrange = "#F57F29"; //Orange color.
		var ocMandatoryField_FlashConstant = -4; //-4 indicates seconds.
		var ocMandatoryField_DecorationIcon = "icon-alert"; //! icon with a circle around it.
			
		g_form.addErrorMessage(MessageForDisplay);
		g_form.addDecoration(FieldToHighlight, ocMandatoryField_DecorationIcon, MessageForDisplay);
		g_form.flash(FieldToHighlight, ocOrange, ocMandatoryField_FlashConstant);	

} - Example usage of UI Script

	ScriptLoader.getScripts("oc_platform_ui_utils.jsdbx", function() {		//Do include this ".jsdbx" extension.
		oc_ShowMandatoryField("description", sDescriptionMandatory);
	});

- Example usage of UI Script which has its Global flag set to true: oc_ShowMandatoryField(“description”, sDescriptionMandatory);

Customer Updates (table sys_update_xml)

1. When you make a change in the system to a “Tracked Object”, the XML related to that change will be captured in a record in this table.
2. These records contain the meat and bones of any tracked change that you make.

- Important: When you view a customer update, and you see the Payload (XML) and such, under Related Links there will be a “Show Related Record” hyperlink which will take you DIRECTLY to the record where the customer update was made! Update Sets (table sys_update_set)

1. An arbitrary set (group) of customer update records is called an Update Set, and is stored in this table.
2. Update sets “contain” customer updates. One update set contains many customer updates.

- Do NOT use the context menu command “Export XML (This Record)” from a record in this table!! - Use the Form Link “Export to XML” or “Export Update Set Batch to XML” in the Related Links section. This will give you an XML file of the form “sys_remote_update_set_xxx” rather than “sys_update_set_xxx”. Remote Update Sets (table sys_remote_update_set) - Contains files which have been Imported from other Instances. - A file named “sys_remote_update_set_xxx.xml” is basically an Update Set AND its related Customer Updates, all packaged up into a single XML file which may then be Loaded, Previewed, and Committed in a different instance of ServiceNow. - Misc

1. When working with the “Customer Updates” table, be sure you turn on the following columns: Type, Table, Name, Target Name.
2. When you use the “Add to Update Set” related link, new customer updates ARE created.

- If you end up with many Customer Updates spread across many Update Sets, the best thing to do to make deployment easier, is probably to just create a new “Everything” Update Set, and then add all the Customer Updates to that Update Set. - You may need 1 Update Set per Application. - Be sure you change your Application Picker application BEFORE you attempt to change the Update Set value of the Customer Updates. - Dealing with Parent Update Sets can be tricky. After you change the status of the parent, and you get a popup message, be 100% sure that you then Save the record. Also, if you deploy a Parent, double check that all CHILD update sets got deployed along with it.

- Takeaway - An Update Set is an XML snapshot of records from tracked tables which are normally stored in the sys_update_xml table. An update set allows tested changes to be moved from one ServiceNow Instance to another. It is important to understand that Update Sets do Not include changes to several types of objects, including Users, Groups, Configuration Items, and most database Records. Update Sets DO include changes to Logic such as business rules, changes to Data Definition (tables and fields), changes to User Interface components (forms and form views), Reports, and Roles. One issue to be aware of, with Update Sets, is they rely on sys_id fields, and some sys_id values are created after an instance is provisioned, so different instances may have different values. One solution to this is to Clone the production instance down to dev and test, so all the sys_id values again match. A different concept, the “Export XML” function may be used for data Records that Update Sets do NOT handle. You can export or import records from any list. Modules - System Update Sets - Local Update Sets - System Update Sets - Retrieve Update Sets Tables

sys_update_xml

Getting Started with Update Sets - An Update Set is literally a Set (that is a group, or a collection) of Updates that a developer can move from one Instance to another. - An Update Set is an XML snapshot of records from tracked tables which are normally stored in the sys_update_xml table. - An update set allows tested changes to be moved from one ServiceNow Instance to another. - Update Sets work by writing changes from tracked tables to the Customer Update [sys_update_xml] table. - Update Sets may be merged together, but if two different update sets have modified the same object, the most recent change will be the one moved to the merged Update Set. - Remember that you can add attachments to update sets. This is very useful for those coming behind you to understand the update set. - Update Sets track the following object types:

Logic / Code

Business Rules Client Scripts Flows (if published)

Data Definition

Tables Fields

User Interface Definition

Forms Form Views Reports Roles - Update Sets do NOT involve the following object types: Users Groups Configuration Items Dashboards (???) Homepages Data Records Schedules Scheduled Jobs Tasks - To export an update set, under System Update Sets - Local Update Sets - first change its state to Complete; then use the Export to XML related link. - After you import an update set, use the Preview Update Set button, then the Commit Update Set button. - Quirks: - One issue with Update Sets is they rely on sys_id fields, and some sys_id values are created after an instance is provisioned, so different instances may have different values. One solution to this is to Clone the production instance down to the dev and test instances, so all the sys_id values again match. - Planning the Update Set Process:

1.  Ensure that both instances are the same version.
2.  Determine the customizations to make in a single update set.
3.  Ensure all the base system records have matching sys_id fields.  How?
4.  Identify a common path (?) for update sets to move across instances, and maintain that model.
5.  Plan when you will commit the update set to production.	
6.  Make sure update set names are clear.

- It's good to have a naming convention for update sets such as this: [Process] - [Sprint#] / [Defect#]

7.  Ensure you understand how update sets work.

- Migration Process

1. Certain items are Not included in update sets, so the overall migration process should account for them.
2. Include instructions for:
   1. Activating Plugins
   2. Configuring system properties or other instance-specific settings.
   3. Setting up MID Servers and identifying servers.
   4. Ensuring that target tables are available.

- To Export an Update Set Change the State to Complete. Save. Click “Export to XML” button. - Importing and Committing an Update Set - From any list column menu…Import - XML

1. Retrieved Update Sets - Sort by Loaded date. (Or filter ty sys_id and use the sys_id in the filename.)
2. Preview Update Sets. Should say “Success”. (Runs quickly) This will then give you a “Commit Update Set” button.
3. Commit Update Set. (May take a little time to run.)
4. Back Out / Backing Out an Update Set

- Under Local Update Sets, for any Committed Update Set… above the Related Links section, there is a “Back Out” button. There should also be a Back Out button at the top right of the form. - XML Data Transfer - The Export XML function may be used for the object types that Update Sets do NOT handle.

1. To occasionally migrate data from one instance to another, you can export the XML data from one instance and import it into another.
2. With this method, there is no need to build an Import Set or a Transform Map.

- Important! Exporting a record will not magically export the Related records or records maintaining Relationships between records. For example, when importing a User, if you need the user's Roles and Groups, you may need to transfer records from those tables also, as well as the relationship tables between those tables and the User table.

1. Export:
   1. Single Record
      1. To export a single record as XML data:
         1. Open record you want to export.
         2. Right click header and select Export - XML (This Record)
   2. Multiple Records
      1. Navigate to List you want to export.
      2. Filter the list, if desired.
      3. Right click header and select Export - XML
2. Editing

- You may want to Edit the exported XML file and remove all Elements that you did NOT change. That way, when you import the XML file back in later, you are not overwriting anything which may have legitimately changed since you did the export. You only need to keep the sys_id element, and any other elements you actually changed, in order for the record to be re-importable later on.

1. Import:
   1. Note, importing XML does NOT trigger business rules or update the instance cache.
   2. Elevate Privileges.
   3. Form ANY list, right click the header and select Import XML. Select file. Click Upload.

- When you set an update set to by your “Current” update set, this information is tracked in the sys_user_preference table: https://[YourInstanceName]/nav_to.do?uri=%2Fsys_user_preference_list.do%3Fsysparm_query%3Dname%3Dsys_update_set%5Esys_created_onRELATIVEGT@dayofweek@ago@30
- Limitations of Update Sets:

1) Many configuration changes are not captured by them.

2) Those configuration changes which ARE captured often include extraneous information; for example, a change to the name of one dropdown value will cause the Update Set to include the definitions for ALL of the other dropdown values in the same field. - If you have an update set selected, and you import an xml file that is normally recorded in an update set such as changes to a business rule or form, the update/insert of the object is recorded in the update set. - Moving items (customer updates) from one update set to another - To move a Change from one Update Set to another… From the Update Set, right click rightmost breadcrumb and choose “Open New Window” - Then you can change the update set that the change falls into. Table involved is sys_update_xml - Dictionary Changes (Table Changes, such as Default values of fields) DO go into Update Sets. - Make new update sets the children of the parent after you complete them.

- This is a system field on all tables. - Sometimes it will show an unexpected user name. Usually this happens in the following situation… A user kicks off a Scheduled Job (or Flow / Workflow). That Job then modifies some records. The user's name will show up as the “Updated By” person for those records, even though the user did not explicitly open up those records and make direct changes to them. - According to ServiceNow, there is really no Customer-centric way of figuring out which Job / Workflow / Flow caused the Updated By field to be changed to a particular user, nor is there a way to differentiate Direct user changes vs indirect ones. (See case CS5671572.)

The Update Versions [sys_update_version] table contains records that represent the state of a customizable object at a particular time. A customizable record is any object that is tracked by Update Sets, such as business rules or script includes. A new version record is created automatically whenever a user changes a customizable record or changes the application file for the customizable record. The version you are looking at on the form (the version currently loaded on the instance) will have “State = Current”, despite the fact that the “Recorded at” field may be an older date than some of the other records. Other versions which were at one time Loaded on the instance will have a “State = Previous” value. “State = History” indicates that the version was never loaded on the instance, but was included for historical purposes (such as when pulling versions from a Parent in Team Development). Believe that the Bottom-most record appears to the RIGHT in the comparison tool UNLESS one of the records is the CURRENT record, in which case it appears on the right. When you do a comparison, the Current Version always appears on the RIGHT; the other record will be labeled as the “Selected Version” and will appear on the LEFT. Update “Versions” in the “sys_update_version” table are just records of what changed. Deleting a “Current” record in that table will not actually change the underlying record (the actual object in the database). When comparing 2 versions of an object in ServiceNow, you can actually make changes on-the-fly to the Current version. The “Save Merge” button saves all changes you made while comparing. Because the Current Record is editable, the controls that appear in the Comparison dialog for the Current record (such as the pencil icon) will often be different than those shown for a previous record (blank list). This can make it difficult to see what has actually Changed, since the control types in the 2 side-by-side columns are different. SOME of the Changed Rows are shaded in a Blue/Gray. They can be a little hard to pick out since some of the other controls are blue or have gray backgrounds. However, changed dropdown controls will NOT be shaded in the blue/gray color! Ugh!

disable_users();

function disable_users() {
                ClearUserLog();
    var gr = new GlideRecord("sys_user");
    gr.addQuery('u_last_refreshed', '<', gs.daysAgoStart(1));
    gr.addQuery('active', true);
    gr.addQuery('source', '!=', "");
    gr.query();
    var DeactiveCount = gr.getRowCount();
    gs.log("johntest" +  DeactiveCount);   // uncomment for test
                UserLog("johntest" + DeactiveCount);
    //limit the deactivation to 500 users per day
    if (DeactiveCount <1600) {
        while (gr.next()) {
          gr.active = false;
          gs.log("Disabled inactive user: " + gr.user_name + " – last LDAP update: " + gr.u_last_refreshed);  // comment b4
        //  gr.update();    // comment b4 jwj0215
        }
        gs.log("Completed disabling inactive accounts");
    } else {
        var ga = new GlideRecord('sys_user_group');
        ga.addQuery('name', 'IS-Technical-Operations');
        ga.query();
        while (ga.next()) {
            var gadminuser = new GlideRecord("sys_user");
            gadminuser.addQuery("user_name", "admin");
            gadminuser.query();
            while (gadminuser.next()) {
                var cmdbci = new GlideRecord("cmdb_ci");
                cmdbci.addQuery("name", "ServiceNow-PROD");
                cmdbci.query();
                while (cmdbci.next()) {
                    var gi = new GlideRecord("incident");
                    gi.initialize();
                    gi.caller_id = gadminuser.sys_id;
                    gi.short_description = "Error in Scheduled Job: 'Disable Inactive Accounts'";
                    gi.description = "There are more than 500 users discovered to be marked inactive. Please investigate and confirm the LDAP sync is working properly. If there are 500 records either increase the deactivation limit or manually run the script without the limit.";
                    gi.impact = '2';
                    gi.urgency = '2';
                    gi.category = "IS Processes";
                    gi.subcategory = "Operations Center";
                    gi.assignment_group = ga.sys_id;
                    gi.cmdb_ci = cmdbci.sys_id;
                    gi.insert();
                }
            }
        }
    }
}

- https://docs.servicenow.com/bundle/rome-servicenow-platform/page/build/service-portal/concept/user-criteria.html
- https://docs.servicenow.com/bundle/rome-servicenow-platform/page/build/service-portal/task/create-user-criteria-record.html
- https://docs.servicenow.com/bundle/rome-servicenow-platform/page/build/service-portal/task/widget-user-criteria.html#widget-user-criteria
- https://www.servicenow.com/community/now-platform-blog/a-deep-dive-to-user-criteria/ba-p/2281285
- User criteria enables you to allow access to users based on role, department, group, location, or company - Administrators can control access to pages, widgets, widget instances, announcements, and search sources in a portal by creating and applying user criteria. - User criteria records define conditions that are evaluated against user records. When user criteria are defined, portal records are only visible to users who pass the defined conditions. - User Criteria is used particularly in Knowledge Management and the Service Catalog (Service Portal). - User Criteria does not Replace Access Controls in most situations. - User Criteria helps Group users, so that those users my be granted or denied access to certain resources. - User Criteria (out of the box) only applies to 6 User fields, but may be extended to apply to ANY User field. - Important: After making user criteria additions or changes, you may need to log out and log back in to clear the prior configuration. - Plugin

1. In table sys_plugins, in the name field, search for “Service Portal User Criteria Support”.

- System Property - After activating the Service Portal User Criteria Support plugin, you must set the following system property to true:

1. Service Portal - Properties - “Enable use of User Criteria records instead of Role fields for Service Portal entitlements
2. glide.service_portal.user_criteria_enabled
3. Setting the system property activates user criteria for Service Portal.

- When set to true, any existing roles defined for a page, widget, or search source are automatically converted into user criteria records. - User Criteria can only be CREATED within the Platform UI under “User Criteria” (For Change, Service Catalog, or Knowledge). - But you an APPLY existing User Criteria to records in the Service Portal through “Service Portal - Service Portal Configuration” - Page Editor…

1. Select a page, widget, or widget instance node from the page tree.
   1. In the “Related Lists” at the bottom of the page…
      1. Select “Who Can View…” or “Who Cannot View…”

- User criteria records are stored in the user_criteria table. - User Criteria Evaluation Order - User Criteria is evaluated in the following order for Service Portal:

	1.  User has a role in the override list?		PASS
	2.  User has criteria in blacklist?			FAIL
	3.  Is there NO Allow List?			PASS
	4.  User has matching criteria in the Allow List?	PASS
	5.  FAIL

- Page Access User Criteria is evaluated as follows:

	1.  Is the page public?				PASS
	2.  Is the user Signed OUT?			FAIL
	3.  Is User Criteria Enabled
		YES
			3.1 Pass User Criteria Check?	PASS
			3.2 FAIL
	4. Does the Page have Populated Role Fields?
		YES
			4.1.  Does the user have one of the Roles?		PASS
			4.2.  FAIL				
	5.  Is the "Use Explicit Roles" property Disabled?		FAIL
	6.  Does the user have snc_internal role?	PASS
	7.  FAIL

- Widget Access is determined as follows:

1. If there is a Widget Instance, and the Widget Instance has Roles, the User must have one of the Roles…
2. If there is NOT a Widget Instance…
   1. But the Widget is “Public”, the user will be granted access. PASS
   2. If the user is NOT signed in FAIL

- Find the sys_user record for the MID Server User and change the password there first. - Connect to the MID Server host using RDP or similar technology.

1. Example server from LDMG: LAS1W1SNOWA01.hcp.com

- Open the file at a path such as this: c:\ServiceNow MID Server\agent\config.xml - For the key “mid.instance.password”, change the value to the new password value.

- User Criteria Diagnostics (Tool) - sc_cat_item_user_criteria_mtom (Roles) - sc_cat_item.availability (Desktop or Desktop and Mobile) - sc_cat_item_producer.availability (Desktop or Desktop and Mobile)

Table sys_update_preview_problem Description

"Found a local update that is newer than this one"
	Object
		Activity Stream Fields
	Target Name
		glide.ui.x_fmc_ibfs_coop_site_activity.fields
	Table
		sys_properties
	Update Date on Dev
		2023/01/31 12:06:23
	Update Date on UAT
		2023/01/31 17:06:18
Notes
	- Seems like changes were made directly on UAT after they were made on DEV.
	- Not sure why the sys_id of the record on UAT is different from the one on DEV.
	- Maybe the record was totally deleted and then re-created.  But don't know why that would have been done.