Recently, while working on a Cornerstone integration with SailPoint ISC using the Web Services Connector, I spent some time understanding how Organizational Units (OUs) and Custom Fields (CFs) are mapped and provisioned.
One of the key learnings was that the OU IDs and Custom Field configurations in Cornerstone must align perfectly with the mappings configured in SailPoint. Even a minor mismatch can result in provisioning failures, such as missing required fields, invalid OU values, or custom field validation errors.
I’m currently exploring different approaches to manage OU and Custom Field mappings more effectively and troubleshooting some challenges around Custom Field provisioning.
If anyone has experience working on Cornerstone integrations with SailPoint, I’d be happy to connect and learn from your insights. Your suggestions and guidance would be greatly appreciated.
For managing OUs I would recommand to use a before account operation rule (for Web Service Connector) or Customizer before create and before update account (for Web Service SaaS Connector)
The Ideas will beto resolve the Cornerstone OUs Internals IDs.
For example, if an OU called business unit have an OUID which is mapped with the departmentId in Sailpoint.
In before operation rule, you can retreive the deparmentId from the plan and use the Cornerstone Organization APIs to search the internal associated with the departmentId :
Thanks for the suggestion. This is actually the current approach we have implemented, where the Before Operation Rule resolves the Cornerstone internal OU IDs using the Organization APIs before provisioning.
One thing we’ve noticed is that CF updates were working fine a few days ago, but they are now failing without any changes to the SailPoint configuration. Have you encountered similar behavior before, or are you aware of any Cornerstone-side changes that could impact CF updates?
No, we haven’t noticed any changes, and it works fine in our case.
Have you checked the logs? Did you notice any specific errors?
Note: Between Cornerstone Employee API V1 and V2, the data format has changed. For example, the V1 endpoint requires the OU type name (e.g., "Business Unit") when assigning an OU to an employee, whereas the V2 API requires the typeId (the internal ID of the OU type). There are also several other differences in the object structure and payload format between the two API versions.
The actual issue was related to the permissions assigned to the service account we were using. Since the service account did not have all the required privileges, it was unable to update certain fields.
After we reached out to the application team and they granted the necessary permissions to the service account, everything started working as expected.