THURSDAY, JANUARY 19, 2017

Category: Imports

Execute Scheduled Jobs From Script

Scheduled jobs are an extremely useful way to automate processes in Service-now.com and lift some of the administrative burden of the tool off of the shoulders of your Service-now administrators. It’s very easy to create a scheduled job or a scheduled import. Typically there’s no scripting or advanced configuration involved at all. Just set it up with a schedule and let it run! There are some situations where you might need to execute a scheduled job outside of its normal schedule. You can always open up the scheduled job entry and click the ‘Execute Now’ button, but there are also probably times where you’d really like to automate the process based on some trigger in a workflow or state change in some ticket or CI.

This article shows you how you can use script to execute an already-scheduled job on-demand. To do this, you simply mimic the behavior of the ‘Execute Now’ button by querying for the scheduled job you want to execute and firing off the job. Here’s the script…

Read more ...

The Simple Power of XML Export/Import

Service-now.com makes extensive use of the XML format for storing and transporting system updates and changes. Update sets, System Import Sets, and certain export methods all make use of XML files in one way or another. One feature that a lot of people don’t know about until somebody shows them is the ability to export and import XML files in a Service-now instance. A manual XML import/export can be extremely helpful in the right circumstances and is something that every Service-now consultant or administrator should have in their tool belt. In this post, I’ll explain how simple it is to transport system changes from one Service-now instance to another with a few clicks.

Read more ...

Deactivating Users From LDAP

One of the most common LDAP integration requirements is to disable users in ServiceNow when they become disabled in the LDAP source.

It is probably worth mentioning that you always want to deactivate user records (and most other records too) in ServiceNow instead of deleting them. Once a user record has been created in ServiceNow it should always remain in ServiceNow because that record could be linked to hundreds of other records (tasks, CIs, etc.). Deleting the record kills the relationship to those other records. Deactivating the record keeps that relationship in place.

Because the exact steps to set up this behavior vary depending on your LDAP setup and processes, this configuration isn’t something that can be predefined in ServiceNow. Typically a ServiceNow consultant assists with this setup and specific requirements are determined on a client-by-client basis. It has been my experience that there are two common approaches that can be used to disable ServiceNow users from LDAP. This article explains these approaches and how you can implement the needed functionality.

Read more ...

The Best LDAP Integration Tip You’ve Never Heard Of

O

ne of the basic (but often forgotten) guidelines that should be followed whenever you consider importing any data into your Service-now instance is to only import the information that is actually necessary within the tool. Just because you CAN import the data into Service-now doesn’t necessarily mean that the data SHOULD be imported or that it has any value. Even if somebody thinks the data has value within Service-now, you should also consider if that value outweighs the work and trouble of importing and maintaining that data going forward. This is particularly true for CMDB and old ticket data but is also true of user data imported from LDAP. One thing that a lot of people don’t realize is that you can end up with ‘garbage’ data from LDAP but that it is also very simple to configure your system to prevent this from happening.

Read more ...

Defining the ‘Run as’ User for a Scheduled Import

Recently I had a client ask me why all of their imported records showed up as being updated and created by the person who initially created the import. The problem, they said, was that the imported records were being created and updated on a scheduled basis by the system so it really wasn’t a particular person who was creating the records. While I agreed that it was a problem, I wasn’t sure at the time why it was happening or what the solution was. Now I know!

Read more ...

Latest Comments

  • David: It appears that I can hit sys_properties table with REST. This works, but I haven’t yet discovered the...
  • Mark Stanger: Hey David, It doesn’t surprise me that scoped apps have made this more difficult. I’m not...
  • David: Mark, do you have an example of how to do this in a scoped app? It seems there are many hoops to jump through...
  • Mark Stanger: The only possibility is to create a system property to override this in your application. Check out the...