0

We are trying to develop a SCIM enabled Provisioning system for provisioning data from an Enterprise Cloud Subscriber(ECS) to Salesforce(Cloud Service Provider-CSP). We are following SCIM 1.1 standard.

What are we able to do:

We are able to perform CRUD operations on User object using Salesforce auto-generated userId field

Exact Problem:

We are not able to update/delete User object using externalId provided by ECS. Tried something as below... But it is not working, Unknown_Exception is thrown...

XXX/my.salesforce.com/services/scim/v1/Users/701984?fields=externalId

Please note that it is not possible to store Salesforce userId in ECS's database due to some compliance reasons. So we have to completely depend upon externalId only.

Possible Workaround:

Step1: Read the userId based on externalId from Salesforce Step2: Update the User object using the salesforce UserId obtained in Step1. But this two step process would definitely degrade the performance.

Is there any way to update/delete the User by externalId Could you please guide us on this.. Thanks so much....

Developer
  • 309
  • 5
  • 8
  • 19

2 Answers2

2

I realize this is old thread but wanted to note that you CAN update Users from REST using an external ID. The endpoint in above question is incorrect. Following is how it should be set, send as a PATCH request:

[instance]/services/data/v37.0/sobjects/user/[external_id__c]/[external id value]
  • Instance = your instance i.e. https://test.salesforce.com/
  • external_id__c = API name of your custom external Id field on User
  • external id value = whatever the value of the user's external Id

NOTES:

  • Salesforce responds with an HTTP 204 status code with No Content in the body, this isn't usual for patch requests, but it is 'success' response
  • The external id on user has to be a custom field, make sure it is set as UNIQUE
  • Ensure the profile/permission set of the user that is making the call has the Manage Users permission & has access to the external id field
A.mcm
  • 21
  • 3
1

It is pretty common pattern for other applications, too, to search first and then perform on update on the returned object. Your workaround seems fine to me. What performance problem are you concerned about? Are you concerned about Salesforce not being able to process more requests or are you concerned about the higher response time in your application because you need to make multiple requests? Have you actually measured how much an extra call costs?

Bertold Kolics
  • 892
  • 6
  • 11
  • Dear Bertold, thanks a lot for the quick response. We are in-fact concerned about the higher response time because we need to multiple requests. Thanks for letting us know that this is a common practice in Provisioning. As there seems to be no other go, we'll go ahead with the workaround. Thank you – Developer Feb 05 '16 at 12:35
  • There are few things I would consider to minimize the impact of the response time: 1) keep connections open between calls, 2) use a connection pool, 3) cache the lookups (external ID to user ID) in memory to reduce calls to SalesForce. I hope this helps. – Bertold Kolics Feb 05 '16 at 16:59
  • Sure, definitely. We'll follow all your suggestions. Thank you sooo much – Developer Feb 09 '16 at 08:40