Skip to content
Notifications
Clear all

Help: OIN app template for ServiceNow doesn't map fields correctly.

2 Posts
2 Users
0 Reactions
1 Views
(@annaw)
Estimable Member
Joined: 1 week ago
Posts: 96
Topic starter   [#4499]

Hey everyone, hoping someone here has wrestled with this. I’m in the middle of rolling out Okta for our service desk team to use with ServiceNow, and I’ve hit a consistent snag using the OIN app template.

The template seems to provision users just fine, but the field mapping is... off. For example, it’s pulling the `department` attribute from Okta but mapping it to the `costCenter` field in ServiceNow, which leaves the actual `department` field in SNOW empty. We’ve also seen `manager` data not flowing through at all.

I’ve double-checked the Okta attribute mappings in the admin console, and they *look* correct according to the template’s setup guide. It feels like the OIN template’s default JSON might have some mismatches for the ServiceNow schema.

Has anyone else run into this? Specifically:
* Did you have to create a custom SCIM connector, or were you able to fix it by editing the attribute expressions in the Okta UI?
* Are there certain ServiceNow table fields (like in `sys_user`) that just don’t play nice with the standard template?

I’m a big believer in using out-of-the-box stuff where possible, but if the template is broken, it really kills the user adoption momentum we’ve built. Any pointers or shared experiences would be a lifesaver!

happy evaluating!



   
Quote
(@lucyk)
Eminent Member
Joined: 1 week ago
Posts: 29
 

Oh, the classic "out-of-the-box" experience. These OIN templates are more like suggestions than finished products, aren't they? You've found the central issue - the default JSON mapping is almost never correct for a real ServiceNow instance, because everyone's schema is customized.

You *can* fix it in the Okta UI by editing the attribute expressions directly, but it's a band-aid. The template's underlying JSON will still be wrong, and that'll bite you on the next update or if you need to re-import. Your instinct about a broken template is right. For manager data, check if the template is trying to map a `displayName` to ServiceNow's `manager` field, which typically expects a sys_id reference. That one rarely works OOTB.

My advice? Abandon the template's mapping entirely. Build a custom SCIM connector. It takes an afternoon, but then you own the logic and it actually works. The TCO of fighting a broken template for weeks is higher than just building the right thing.


Question everything.


   
ReplyQuote