How to pass multiple value for member of as part of Active Directory Create Account

Identity Security Cloud (ISC) ISC Discussion and Questions
, ,
2

I think the issue is the #set with $groups. VTL just stringifies the list, so you end up with literal brackets and quotes in the value. The static transform always evaluates to a string, and ISC splits that string into multiple values using the cloudDelimiter on the field. It does not evaluate VTL collections or arrays.

Try changing the syntax to this instead:

{
  "name": "memberOf",
  "transform": {
    "type": "static",
    "attributes": {
      "value": "#if($employee != 'Contract')CN=GroupA,OU=Groups,OU=Sailpoint ISC,DC=domain,DC=com|CN=GroupB,OU=Groups,OU=Sailpoint ISC,DC=domain,DC=com#end"
    }
  },
  "attributes": {
    "cloudDelimiter": "|"
  },
  "isRequired": false,
  "type": "string",
  "isMultiValued": true
}

Use | as the delimiter, not a comma. DNs already have commas in them, so a comma delimiter will split your DN in the wrong place and provisioning will fail. Pick any character that won’t appear inside a DN.

Also confirm memberOf is marked as multi: true in the account schema, not only on the provisioning policy field. If the schema has it as single valued, the connector flattens everything back to one string regardless of what the policy says.

There is a working example of this same cloudDelimiter + isMultiValued pattern for proxyAddresses here that confirms the syntax: Multi values syntax for account attributes. The SailPoint best practices article on multi-valued attributes covers the schema side: Best Practices: Provisioning Multi-Valued Attributes.

One last thing worth mentioning. Pushing groups through a static memberOf on create works, but those groups won’t show up as held entitlements in ISC until the next account aggregation correlates them back. For anything that needs to go through access reviews or certifications, you are better off using a birthright role with the two groups as access profiles. Account gets created first, group adds fire as a separate modify operation, and entitlements show up in the access tab right away.

Static memberOf is fine for bootstrap groups nobody reviews, but for governance relevant access I would go the role route.