I am trying to provision an account to the Governance connector source in ISC. How ever the provisioning fails, hence the user is not being added to the Governance group. I am interested in what attribute we need to map in the Create Profile to make the provision successful.
I see below error. it is expecting the id of the identity, which the ISC system generates automatically!Errors
[ConnectorError] invalid output format: Schema validation error in path: [{allOf all_of_item_mismatch Value does not match the allOf schema at index {indexs} map[indexs:0]} { {Valid:false EvaluationPath:/oneOf/0 SchemaLocation:http://connect.sailpoint.com/schemas/object_output#/oneOf/0 InstanceLocation: Annotations:map[] Errors:map[required:Required property ‘uuid’ is missing] Details:[]} map[]} { {Valid:false EvaluationPath:/oneOf/1 SchemaLocation:http://connect.sailpoint.com/schemas/object_output#/oneOf/1 InstanceLocation: Annotations:map[] Errors:map[required:Required property ‘key’ is missing] Details:[]} map[]}] (requestId: 9ba05cda089a48caa20ca844781b7df0)
I have referred few articles in the developer forum, but I couldn’t find anything related to the create profile mapping!
Any help would be appreciated
Looked into this a bit. This looks like ISC is firing a Create Account request on the ISC Governance source instead of a Modify request on an existing account.
For this connector, the account is the ISC identity. Governance Groups, User Levels, and Roles are managed as entitlements on that account. The connector documentation also mentions that it manages identities as accounts, and manages user levels, roles, and governance groups as entitlements.
I would not try to fix this by mapping or generating a UUID in the Create Profile. The user should already exist as an aggregated account on the ISC Governance source. That uuid / key error means the connector expected the provisioning result to return an account object with either uuid or key, but it got neither. In this case, that usually happens because the request is going down the Create Account path instead of modifying an already aggregated ISC Governance account.
Check these in order:
-
Run account aggregation on the ISC Governance source.
-
Confirm the user has an account on that source.
-
Confirm the account is correlated to the correct identity.
-
Retry the Governance Group request.
It should then go through as a Modify / Add Entitlement request. I saw the same behavior reported in another thread: when the request showed as Create Account, provisioning failed. Once correlation was fixed, requests went through as Modify.
I would start with aggregation/correlation first. If the retry still shows Create Account, then ISC still does not see a linked account for that identity on the Governance source.
Hope, this helps 
Thank @punna0001 I was able to arrive at the same conclusion, that this should be handled as a modify request rather than a create request. However, I’m still unclear about the reference to a “Create Account” document, since account creation isn’t supported in this context and the create policy wouldn’t be applicable on the source system. It makes me wonder if this might be a documentation oversight.
That said, thank you for your response - I appreciate your help.
I would lean toward documentation oversight too. A few older threads (here and here) raised the same point and the consensus landed on the same conclusion. Create on this source isn’t a real provisioning path, only Modify works.
Might be worth raising it with SailPoint support or as a doc feedback item so it gets clarified officially. Glad you got it sorted. 
Another question I have is , will this connector support delimited sources ? As I was not able to aggregate users into the Governance source, so was just wondering, if this connector doesn’t support users from delimited sources! Can anyone confirm?
I believe the ISC Governance connector does not pull users from the delimited source directly. It aggregates identities from the ISC tenant itself and represents those as accounts on the Governance source. So if your delimited source users are already correlated to ISC identities, they should show up when you run account aggregation on the Governance source. The origin source does not matter delimited, AD, HR feed, whatever. What the connector cares about is whether the identity exists in ISC and is visible to it.
Here is what I would check:
-
Confirm the delimited source account is correlated to an ISC identity
-
Confirm that identity is active and searchable in ISC
-
Run a full account aggregation on the ISC Governance source
-
Check the aggregation task result and the account list on the Governance source
If the identity exists in ISC but still does not show up after aggregation, I would check the PAT permissions configured on the source, then open a Support case with the aggregation task details attached.
The delimited source is the HR source. I see the identities created in ISC, but I don’t see them in the Governance connector source. Hence the question!
Got it, so the identities are already in ISC, just not showing up in the Governance source after aggregation. That narrows it down. Since the identities exist in ISC, the connector should be picking them up. A few things worth checking:
1. Run a full aggregation, not delta If you have run aggregation before on this source, make sure you are doing a full reset aggregation, not an incremental one. Delta can miss identities that were not captured in the initial run.
2. Check the PAT on the Governance source The PAT needs enough scopes to read identities from the tenant. If the PAT is tied to an account with limited visibility or incorrect scopes, the connector can pull back fewer accounts than expected, sometimes without any error.
3. Pull up the aggregation task logs Go to Admin > Account Aggregation history on the Governance source and open the task details. Check how many accounts were discovered vs processed. If discovered shows zero, the problem is on the connector or auth side, not the identity side.
4. Check if any filters are set on the source Look at the aggregation settings on the Governance source. If there is an identity filter or user level filter applied, it could be quietly excluding those identities without any obvious indication.
If the task finishes clean but the accounts are still missing, worth opening a case with SailPoint Support.
Check this thread that reported the same aggregation issue on the ISC Governance connector: Issue with SaaS connector - ISC Cloud Governance Connector