ServiceNow Blog

https://www.forbes.com/innovative-companies/#4cb48111d654

OK, so figured out the solution to below problem as per https://docs.servicenow.com/bundle/istanbul-performance-analytics-and-reporting/page/use/dashboards/task/t_ControlAccessToADashboard.html navigate to self-service>dashboards>edit the dashboard>click the cog>click modify. Note that both the 'restrict to roles' AND 'requires roles' seems to affect the access permissions ------------------------------------------------------- User has the role itil / asset, but gets the following error when navigating to cmdb dashboard> CMDB View but gets the following error: " You do not have access to any dashboards. For more information, contact your system administrator." when the fix suggested at https://hi.service-now.com/kb_view.do?sysparm_article=KB0639476 is applied, the error text changes to: "Sorry! The CMDB Dashboard - CMDB View dashboard hasn't been shared with you" the online documentation seems to suggest that itil

For example, only allow user_admins and sys admins to view lists of inactive users this can be achieved using a before query business rule on sys user table BR condition : gs . getSession (). isInteractive () && ! gs . hasRole ( "admin" ) && ! gs . hasRole ( "user_admin" ) BR code to filter out inactive results : current . addActiveQuery ();

For example, in the left hand navigation type in     incident.config this then pulls back all the configurations (client scripts, business rules, etc) defined for that table: pretty neat!

tick the 'conditional' box and paste in the following code: var answer = false ; var now = new GlideDateTime (); //Run only on weekdays var DoW = now . getDayOfWeek (); answer = ( DoW < 6 && DoW > 1 ); answer ;

Enforce unique numbering - avoid duplicates on child tables of task useful reading here: https://docs.servicenow.com/bundle/xanadu-platform-administration/page/administer/field-administration/concept/c_EnforcingUniqueNumbering.html for my solution I went for the recommended business rule solution, and defined the business rule to run on "task" table and inherited by child tables (incident etc) still trying to get to the bottom of how exactly the issue of duplicate incident numbers being generated on the incident form arises, but in the meantime no more duplicate tickets in our instance! examples of how the transaction logs might be checked for the issue: /syslog_transaction_list.do?sysparm_query=sys_created_onBETWEENjavascript%3Ags.dateGenerate(' 2018-05-03 '%2C'12%3A50%3A00')%40javascript%3Ags.dateGenerate(' 2018-05-03 '%2C'12%3A50%3A59')%5EurlSTARTSWITH%2Fincident%5Esql_count%3E0%5Eresponse_time%3E25%5Esys_created_by% 3DSmith

Anyone spotted the " A new record with this value will be created automatically " messages displayed all over the incident form as per the attached screenshot? Anyway, I thought I'd share the explanation provided by ServiceNow... Solution proposed by  (NOW) Hello Ruen, We are placing this incident in Solution Proposed. Reason: I have located documentation that will provide insight on what is happening. Issue: A new record with this value will be created automatically is showing under an empty reference field Solution Proposed: According to the documentation for reference field type : https://docs.servicenow.com/bundle/jakarta-servicenow-platform/page/administer/field-administration/concept/c_ReferenceField.html?title=Reference_Fields#Enabling_Dynamic_Creation Enable dynamic creation : When dynamic creation is enabled, entering a nonexistent value in a reference field creates a new record on the referenced table instead of returning an error. This mean

Where was that incident auto-close property again?? And further auto-close info   system properties> system business rule: "incident autoclose" system scheduler > scheduled jobs updated ref: https://docs.servicenow.com/bundle/utah-it-service-management/page/product/incident-management/concept/c_IncidentResolutionAndRecovery.html (old ref: https://docs.servicenow.com/bundle/istanbul-it-service-management/page/product/incident-management/task/configure-incident-auto-close.html ) the job "Autoclose Incidents" references a job ID "RunScriptJob" (Java class)

I happened to notice an issue which was particularly apparent in Service Portal view, and wasn't made easier by the fact that in Service Portal, test alert messages appear to get caught in a loop until you click out of the tab and back in... I haven't got to the bottom of it yet, but I did notice in my scenario where the following was happening: -onchange runs on a checkbox which sets a number of fields, and resets fields to blank if unchecked -onsubmit vets whether the checkbox is ticked that the onsubmit catalog client script was calling the onchange code, even though the checkbox was not being set in the onsubmit, merely it's value of true or false was being obtained the problem was that the onchange was running and messing up the related fields...so, I seem to have got round it by using the condition in the onchange: if ( newValue == 'false' ){      //reset fields      //...      return ; } Still investigating a better solution...and try