SF Connectors aren’t robust enough to account for loading data based on a combination of logical factors, i.e. when you need to load users based on values in a different object than User.
For example, we want to load in external contractors but only when they have been assigned to a Project in SFDC.
Discovered yesterday that Load to User only support Update, not Upsert. This is very restrictive. Need to have the ability to Insert and Upsert into the user table.
That seems really odd. Especially because the Help text still shows all the options. I would agree with@darkknight . Not sure why those options wouldn’t be included.
Adding our use case, today someone has to manually add a user to GS in order to provide access. Dealing with smaller orgs, this is not a big deal but with high number of users in big orgs this is a time consuming effort that is not needed. We literally copy the info from another system into GS. If we could simply check a box in that other system that then pushes to GS that when ingesting that data creates the users it will eliminate this effort.
Additionally,@darkknight an alternative solution could be to use API to create them. Can’t remember if this is a viable option or not.
Are you talking about the User Sync job from SFDC or from Dynamics into NXT?
If an NXT environment is not connected to either of those, that does not solve the use case.
Yes you are understanding the issue correctly.
It’s not an issue in my particular environment. But, I have implemented other customers in the past where this was an issue.
I.E. Some NXT environments can’t be connected to SFDC but data can be brought in to NXT. This requires manual creation of users. Another customer I had was data coming from Zoho, this requires manual creation of users. Another they were connected to SFDC but only wanted users created from an external system, name of the external system is fleeing me right now, this required manual creation of users.
Yeah, this limitation has reared its ugly head for me too. For some reason my SFDC User ID did not populate in the MDA User table in our Sandbox environment, which is causing issues for my access according to support.
I tried to have a colleague upsert my SFDC User ID (using my email as an identifier) into the MDA User table, per support’s instructions, but the Load to User action not only is limited to “update,” it also forces you to use SFDC User ID as an identifier, leaving me in a frustrating Catch-22.
Hi@spencer_engel ,
Sorry for the inconvenience caused. We are working upon it. Will keep you posted once we finalise a timeline for it.
Thanks and regards,
Neha
Adding my input here.
With no access to the User API and the inability to Upsert on User, the presents extra overhead for the GS Admin when users must be sourced from external systems that are not the standard CRMs. It becomes an entirely manual and tedious process.
Hoping for this to change soon. Thanks!
We keep our employee records on a non-commercial system and bring in new & updated records via CSV. We need an Upsert function on the Load to User rule action. The lack of this means we are required to build an API-based integration for this single use case -- which adds a whole new subsystem to our maintenance and support footprint.