Which IIQ version are you inquiring about?
8.4p2
Please share any other relevant files that may be required (for example, logs).
create-user | SailPoint Developer Community
get-schemas | SailPoint Developer Community
Share all details about your problem, including any error messages you may have received.
Dear experts,
we are currently working on a requirement to create a special identity type which is not flowing in through our authoritative source via SCIM API call.
This works very well but we are wondering if there is any chance to already set the
correlated and correlatedOverridden flags on the identity cube directly through the SCIM call.
This would safe us some work.
We checked the SCIM schema but it does not seem to contain those attributes.
If you know any way to achieve the goal your input is highly appreciated.
Thanks in advance.
Best regards,
Daniel
A possible solution, although not elegant, but would be a ‘work-around’, is to set your own custom attribute that identifies the newly created identity as one that you wish to make correlated and set the correlated/correlatedOverridded flags. For example, you can add a custom identity attribute such as scimCreatedMakeCorrelated, a boolean you can set to “true”. You can then have a scheduled ruleRunner task run every so often that would search for identities which are not correlated, but have this custom attribute set, and make them correlated. It’s a hack, but it would definitely work.
Another option would be to write a custom workflow that can be launched by the SCIM API that would accept an identity name (or other identifiable information) and set the correlated / correlatedOverridden flags on the identity after it has been created. That way the consumer invokes the SCIM API to create the identity, and then immediately invokes the SCIM workflow to make it correlated.
Of course, the best option would be to have it set in the create SCIM call from the very beginning.
Hi @kevinwoodbury ,
thank you very much for your valuable input.
We already have a “source” attribute which was introduced to distinguish between
a) IIQ created identities
b) IDs aggregated from the authoritative source (also visible via link)
c) IDs created via SCIM API.
This will definitely help us to set the above mentioned flags during e. g. our Joiner workflow (as per my understanding there’s no need to introduce another workflow to achieve the goal).
However -as you also mentioned- the most elegant solution would be to set the attributes already via the SCIM call.
Thanks,
Daniel