I think there is significant area for improvement of the Auto Provisioning functionality when dealing with referenced fields.
For example, the user table within ServiceNow looks similar to the sample snippet below:
TABLE - User [sys_user]
FIELD - Username [username] - string
FIELD - Name [name] - string
FIELD - Email [email] - string
FIELD - Department [department] - references Department [cmndepartment] table
FIELD - Location [location] - references Location [cmn_location] table
FIELD - etc. etc.
Provisioning from Azure - in the cloud - is an awesome alternative to the previous configuration of having ServiceNow communicate with on-prem AD via LDAP/LDAPs/MID server/etc. because both Authentication and Provisioning can happen from the same source.
One limitation is the ability for Azure to create new values within tables that are referenced from the user table (such as Department and Location in the example above). The value has to already exist within ServiceNow for Azure to properly map it.
Given the following use case... it is tough to fully transition from on-prem configuration to a fully automated cloud configuration without the need for additional “swivel-chair” work.
I have and am mapping all of my users into ServiceNow from Azure, with the exception of service accounts, etc.
Those users are spread across 4 locations and 8 departments for example.
Finance, IT, DevOps, HR, Facilities, Engineering, Sales, Marketing
Baltimore, Philadelphia, D.C., Boston
If I know all of this information when initially setting up my ServiceNow environment, there isn't too much of an issue. I can create the 4 location records in the Location table and 8 records on the Department table. Then, I set up the provisioning integration with Azure and users will get assigned to those locations as long as the string value in physicalDeliveryOfficeName or city (whatever I have mapped to that attribute) something of the sort contains the same value as the record in my referencing table.
The situations where this becomes an issue, is for example... if I want to create 10 new Locations and 40 new departments for my users. Not only do I have to update users accounts in Azure to list them in the new locations, I also have to make sure to create every value (as it exists on the users’ record – no differences in spelling – example “D.C.” vs “DC”) within ServiceNow as well (within the corresponding tables)
So, when I add the location of "Chicago" I also need to make sure that the location table within ServiceNow contains a location called "Chicago" that we can reference. If not, that user will exist in ServiceNow with no location.
This isn’t so bad for the small example that I mentioned above, but when you apply this concept to a large enterprise with 100s of Locations and 100s of Departments changing regularly… it is really hard to manage user provisioning entirely from Azure into ServiceNow.
The (old “non-cloud”) alternate of have ServiceNow pull AD users via LDAP allows for the following concept when dealing with reference fields.
“The ‘department’ attribute is mapping to the Department table within ServiceNow”
Is a match found for this department (eg. “Maintenance”)?
Yes – associate that user to the “Maintenance” related record.
No – you can choose how you would like it to proceed
1. Create – meaning if I find a value that doesn’t exist yet while pulling in new users, create the record on the referencing table
2. Ignore – meaning if I find a value that doesn’t exist yet while pulling in users, don’t create the new record just skip over assigning the user’s department
3. Reject – meaning if I find a value that doesn’t exist yet while pulling in users, reject the users insert/update entirely… move on to the next object in the list of users
This is one disadvantage of pulling the “logic” of user provisioning out of ServiceNow and having it handled from with Azure
Thanks for the feedback. We are looking into revamping our ServiceNow connector. Will update this thread as we make progress.
Informative list. Thanks for sharing the useful stuff. Will be very helpful.
Is there any update on this idea?
Asato-CW, Wesley 36377 commented
This should be a fairly simple thing. Stop the AAD script from querying the ServiceNow location and department tables for matching values. Have AAD write the location and department values to ServiceNow.
Advise the ServiceNow admin to enable "Dynamic Creation" on the field definition for location and department in the user record.