I looked into the SailPoint docs on this & wanted to share what I found, in case it helps narrow things down.
So the Workday SaaS connector seems to be treating the XPath mapping as a node lookup, not as a place to actually run XPath functions. It resolves the matched XML node and reads the text value out of it. concat() doesnt return a node, it returns a string, so the connector has nothing to read and you get blank back. The fact that even concat("A","B") comes back blank is what made me lean this way honestly. If it was a bad path or namespace problem the static one would still resolve to “AB”. Looks more like connector behavior than anything wrong on your side.
Couple things in the docs that backed this up for me. The SailPoint Workday SaaS XPath mapping page only ever shows node-path style mappings, no function expressions anywhere. And concat itself is documented as a separate ISC transform operation, not as something the connector runs inline on the XPath.
Also wd: is right for the SaaS connector btw. The ns1: you see floating around in older docs is from the VA based Workday connector, wouldnt mix those.
So what i would suggest, pull the three values separately and do the concat on the ISC side after aggregation. Example source schema attributes:
FIRST_NAME -> wd:Worker_Data/wd:Personal_Data/wd:Name_Data/wd:Legal_Name_Data/wd:Name_Detail_Data/wd:First_Name
LAST_NAME -> wd:Worker_Data/wd:Personal_Data/wd:Name_Data/wd:Legal_Name_Data/wd:Name_Detail_Data/wd:Last_Name
WORKER_ID -> wd:Worker_Data/wd:Worker_ID
Then build the combined value with a concat transform. Replace sourceName with the actual Workday source name in your tenant:
{
"name": "Workday Display Name With Worker ID",
"type": "concat",
"attributes": {
"values": [
{
"type": "accountAttribute",
"attributes": {
"sourceName": "Workday",
"attributeName": "FIRST_NAME"
}
},
" ",
{
"type": "accountAttribute",
"attributes": {
"sourceName": "Workday",
"attributeName": "LAST_NAME"
}
},
" (",
{
"type": "accountAttribute",
"attributes": {
"sourceName": "Workday",
"attributeName": "WORKER_ID"
}
},
")"
]
}
}
If the combined value really needs to live on the Workday account record itself, the cleaner path would be to build it in Workday as a calculated field, expose it through the integration, and then map that single field in the SaaS connector. The connector handles that fine because it is reading a real XML node with text content.
I would probably not keep testing different concat() syntax variants here. Since even static concat("A","B") returns blank, it really does look like a connector-side limitation.