I've been conducting a detailed analysis of our identity provisioning metrics and have isolated a significant data quality issue stemming from the official Okta Integration Network (OIN) template for ServiceNow. The core problem is systematic field mapping failure during user provisioning and updates, which is corrupting our downstream HR analytics dashboards. Specifically, the `employeeNumber` and `department` attributes are not being written to the corresponding ServiceNow `u_okta_employee_number` and `department` fields, despite the mappings being declared in the OIN template JSON.
I've spent the last week tracing the SCIM calls and comparing the intended schema against the actual payloads. The template appears to define the mappings correctly, but the transformation logic within Okta's provisioning engine seems to be applying them incorrectly, or perhaps there's a version mismatch with the ServiceNow SCIM API. Here is a simplified view of the relevant section from the provisioning configuration I've extracted via the API:
```json
{
"mappings": [
{
"source": "user.employeeNumber",
"target": "userName",
"expression": "SubstringBefore(userName, '@')"
},
{
"source": "user.employeeNumber",
"target": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:employeeNumber",
"expression": "user.employeeNumber"
}
]
}
```
The issue manifests in two observable ways:
* **Data Inconsistency:** The `employeeNumber` value is sometimes placed in the `userName` field in ServiceNow, while the actual `userName` is overwritten.
* **Data Loss:** The `department` attribute sent from our HR source (Workday) is simply dropped and never appears in ServiceNow, creating null values that break our employee headcount reports by business unit.
This isn't just a configuration nuisance; it's a critical data pipeline integrity problem. Has anyone else deconstructed this template and validated the field mappings? I'm particularly interested in:
* Any modifications you made to the default attribute mappings to achieve correct synchronization.
* Whether you encountered specific behaviors with the `urn:ietf:params:scim:schemas:extension:enterprise:2.0:User` schema versus the core `User` schema.
* If you bypassed the OIN template entirely and built a custom SCIM integration for more granular control.
My next step is to build a validation dashboard in Looker to monitor provisioning failure rates by field, but fixing the root cause in the mapping is essential. Any detailed workflow reports or specific JSON snippets from a working configuration would be invaluable.
- dan
Garbage in, garbage out.
That truncated JSON snippet is interesting, but it looks like you're showing a `userName` mapping, not the problematic `employeeNumber` or `department` ones. The devil is usually in those specific expression details. Could you share the exact mapping definition for those two fields from your extracted config? I've found the OIN templates sometimes use complex nested `expression` logic that fails silently if a source attribute is null or in an unexpected format.
Also, have you ruled out ServiceNow's side? The `u_okta_employee_number` field needs the correct SCIM attribute `urn:ietf:params:scim:schemas:extension:okta:user:1.0:employeeNumber` mapped in the ServiceNow SCIM schema, which sometimes isn't activated by default even with the OIN app.
—Alex
You're spot on about the ServiceNow side needing a check, that's tripped me up before. The OIN template often assumes the custom SCIM schema extension is active, but you've got to manually verify it's listed in the ServiceNow SCIM Resource Types.
For the expression logic, I've seen those fail when the source attribute isn't a simple string. If `employeeNumber` is stored as an integer in Okta's profile, the template's expression might need a `toString()` wrapper that it doesn't have. Could you pull the exact expression block for those fields? That'll tell us if it's a format issue.
Measure twice, automate once.