Home 
Integration tips and tools 
Twitter Feed snc tweets 
Downloads SNCGuru apps 
About/Contact 
About about SNCGuru 
Contact contact SNCGuru Follow these guidelines to make sure you’re using the right security technique for every situation!
TUESDAY, FEBRUARY 07, 2012
Posts Tagged ‘ACLs’
Monday, 28 February, 2011 08:28
A
s a Service-now administrator or consultant, you may run into situations where it is necessary to identify the IP address of a user session before performing some action. These situations are almost always security-related. For example, you may want to restrict the ‘Delete’ operation for Change request tickets to users at a specific location, or you may want to show a particular UI action button to users whose sessions originate from a particular IP address.
I haven’t seen this type of request very often, but it is pretty simple to get this type of information in Service-now. This post shows you how.
Monday, 09 August, 2010 13:48
I
often get the request to set up access for group managers to be able to manage the members of their groups in Service-now. This configuration isn’t too difficult to set up but it does involve a few different pieces. It’s also important to consider your group setup in your system before allowing access in this way. If you are bringing in group memberships from a data source like LDAP for example, the last thing you want is to have your managers manually changing those group memberships within Service-now. The configuration shown below could be easily customized to allow access only to non-LDAP groups if you needed to do both however.
Thursday, 31 December, 2009 17:06
O
ne common problem I encounter with Service-now deployments has to do with the sharing of a field between many tables extended off of the same parent table. Because the Task table and the Configuration Item table make heavy use of extended tables this is where I see the problem most often. What is the best way to make changes to a shared field for the table that I’m working on, but not impact other tables that may be using the same field?
Let’s say that I’m in the middle of a Change management deployment and I’m using the ‘Configuration item’ field on my Change form. At the same time, my company is trying to roll out Incident management so there’s also someone from another department trying to make configuration changes to the ‘Configuration item’ field on the Incident form. The Incident management process says that the Configuration item field is optional while Change management says that it should be mandatory. Incident management has a very complex reference qualifier for the field, but Change management doesn’t want a reference qualifier at all. Since there is only one dictionary entry for the Configuration item field, we can’t both have our way if we are making configuration changes on the dictionary entry. Below are a few of the common scenarios where you might see this problem and how you can make it work for all tables that access the shared field.