Searching for this source history, i find that has been created with name RACF, But in the Target field, the name “RACF [Source]” appears. I used this name in the API and it worked correctly.
The question is: why is what appears in the name field of the Source not accepted as the name of the Source? I saw somewhere that the source has a fixed name that cannot be changed after creation, but I can’t find this “RACF [source]“ name by searching through the API itself: get-source | SailPoint Developer Community
Hi @raibom - have you tried using VSCode with the ISC extensions? Once you connect to the tenant you can browse the json of all the objects which makes finding names and Id’s a little easier than doing API calls.
What you’re seeing is the difference between two values SP assigns to a source.
Display Name: This is what you see in the UI everywhere (but not in the events, like you have posted here). This display name can be changed after the source is created.
Technical Name: This is an internal identifier SP generates when the source is first created. It typically looks like the Display name [source] in your case its RACF [Source]. This value cannot be changed once the source is created.
Some API’s including the one you’re using expects a technical name and not the UI display name.
The reason there’s a separate technical name is so that automations, rules, and API calls don’t break if someone later renames the source in the UI. The display name can change, but the technical identifier stays fixed, so anything programmatic always points to the same source regardless of UI edits.
One thing worth mentioning - we had ran into an issue with the technical name because of a change SailPoint made recently around how source technical names are generated.
One fine day, SP changed how they calculate the the technical name, it wasn’t just Name [source] anymore. It can now include a longer identifier, something like Name [source-xxxxxx]. Name [source-timestamp]
There was a thread I created about it here, if you want the full context:
Because of that shift, anything that depends on the technical name - like rules, or in your case the query-password-info API - will only work when you use the internal name rather than the display name shown in the UI.
At the time, we thought it was a bug and opened a support ticket, but it turns out this was intentional behavior. They eventually rolled it back for us (and possibly more widely), but it wasn’t clearly communicated.
The main takeaway is: this feature could roll out again without much notice, and if you’re not aware of the change, new deployments or automation could break unexpectedly.
To be fair, the reason behind the change made sense - it allowed creating sources with similar or reused names, since once a source named abcd exists, deleting it normally blocks you from creating another with the same name. The timestamp suffix solved that nicely - we just would’ve appreciated a heads-up before it landed.
In ISC, the technical name of a source is always cocatenated with [Source]. If you try to catch an provisioning plan content (using webhook for example), you’ll see that ISC added [Source] :
Just like for roles for example :
here the role’s name is “InStaff“, but the technical name has additional information.
To avoid being confused, you should always check what you have in the provisioning plan for the case you’re working on, and the problem will be solved
yes, look for aggregation activity and look at the “Aggregate Source” events, refer the target attribute value This has consistent hit the nail on the head for me. [Incase you cant find the source creation event]
