Skip to main content

Posts

Showing posts from June, 2020

Targetting specific Multi-SSO provider with URL

the recommended approach by ServiceNow is to store the SSO to use on the user record directly (NY:  https://docs.servicenow.com/bundle/newyork-platform-administration/page/integrate/single-sign-on/task/t_ConfigureUsersMultiProviderSSO.html  ) However this can also be hard-coded in a deep link url using format: https://<instance_name>.service-now.com/login_with_sso.do?glide_sso_id= 5a5e1ee1dbe61b00e2219c44db96xxxx Where the sys id matches the record configured in multi-provider SSO BR Ruen (useful old ref: https://old.wiki/index.php/Multiple_Provider_Single_Sign-On  )

ServiceNow 3-strike rule on RITM (auto-close Service Request in awaiting customer)

ServiceNow 3-strike rule on RITM (auto-close Service Request in awaiting customer) (ordinarily for incident Flow Designer might be used) alas, on New York version this is not possible, and below is a business rule + scheduled job option to avoid having to update all the RITM workflows (though a second workflow to attach to the RITM could be an alternative option) in this particular solution, the customer carried out work at the RITM level as catalog tasks were not yet being used by the fulfilment teams Code assumes a custom field  u_closure_code  is used on the RITM table 3-strike rule for RITMs Contents How it works Build New fields Business rules Event registry ACLs Scheduled job Notification How to test Scheduled job script   How it works   ·        When an RITM is placed in state= on hold and on hold reason= awaiting caller , a business rule will populate a new field:     This field will not be editable by ITIL users or placed on the form but is viewable vi