Share all details related to your problem, including any error messages you may have received.
We recently updated our test environment to patch 3 of IIQ 8.3. During testing we noticed that when we tried to disable a salesforce account, Salesforce returned an error that ContactId wasn’t a column on entity User: "No such column ‘ContactId’ on entity ‘User’
Apparently in patch 3, Sailpoint made some changes to the salesforce connector including a query to get some data from an existing user.
The query used to be: select Id, UserRole.Id from User where Id=…
But they changed it to include ContactId: select Id, UserRole.Id , ContactId from User where Id=…
(the query is done even if you don’t use the new functionality to create a Contact during User creation)
In the patch notes Sailpoint said they added new functionality for Portal Users/Contacts and that you need Manage Contact permissions for this functionality.
The problem is that our customer doesn’t use Salesforce for Portal or Partner functionality. and they never configured Salesforce for those features. That’s why they can’t add “Manage Contacts” permissions. And maybe that ContactId attribute isn’t actually even available.
They also don’t want to make fundamental changes to their implementation for features that they don’t even use.
Is there a way to solve this issue without having to configure Salesforce for functionality that the customer doesn’t even use?
(we also didn’t check the box: “Create Contact on User Creation” in the application configuration)
In the IDN discussion section, we saw a similar post. But it was closed with the remark that the customer should just add permissions like “Manage Contacts” to the user that IIQ uses. But apparently, they can’t do that here because they never configured support for portal and partner users (perhaps it’s not even a right issue)
Hi,
Thanks for the reply, but we don’t have ContactId in our account schema of the Salesforce application. The select query, where that attribute is included, is hardcoded in the connector.
We already have unchecked Manage Active Accounts Only. And we also have a “custom” SearchStringForUser value. This is used for the aggregation.
But during (for example) a disable action, the connector tries to get certain values for a specific user and that’s when the hardcoded select statement is used:
select Id ,UserRole.Id, ContactId from User where …
This is in sailpoint.connector.salesforce.ForceProvisioning.getExistingUser
Which is used internally in several locations I think.I don’t know if there’s a way to bypass that query like what you could do with the SearchStringForUser.
There’s a similar post like mine in the IDN section: