My organization is trying to use the Salesforce app to push data from Docebo to Salesforce. I know it is supposed to work the other way around, but this is a specific use case. My question is whether it is possible to sync courses and enrollments only without the user push from SFDC to Docebo (assuming users have identical IDs in both). When we try to turn off the users and leave the other two categories “on” we get a 500 or other sync errors.
Also, I am trying to find the log file of the actual data that is being pushed back and forth from SFDC to Docebo and synced from Docebo to SFDC. What type of file is this and where can I find it? I thought maybe it would be a JSON file in the log, but all of those that I can see only say “null” for content.
Page 1 / 1
I wish you luck with the Salesforce Integration. If I had it to do over again I would use the connector. It is cheaper and more flexible.
I went into our Sandbox, it is not a completely working integration but I was able to turn on the content sync without the user sync.
Regarding logs there is only the event logs and sync logs in the Docebo area. One of our goals was for users to be able to take training in Salesforce. But there is no way to report whether the user logs into Docebo and takes the training or they do it through the Salesforce interface.
I wish you luck with the Salesforce Integration. If I had it to do over again I would use the connector. It is cheaper and more flexible.
I went into our Sandbox, it is not a completely working integration but I was able to turn on the content sync without the user sync.
Regarding logs there is only the event logs and sync logs in the Docebo area. One of our goals was for users to be able to take training in Salesforce. But there is no way to report whether the user logs into Docebo and takes the training or they do it through the Salesforce interface.
So in your screenshot it looks like the enrollments is not syncing. Were you able to get both courses and enrollments to sync without the user sync? Did it throw any errors?
For reference, we can get content to sync without the user sync, but the system is not happy… it is throwing errors every time. I am just wondering if there is something I need to change with our settings.
And just to clarify, when you said if you had to do it over again you would use the connector, which are you referring to?
@amber - correct, that is the sandbox. I cannot mess around with production in the same way. But at least it let me switch the settings.
It makes sense it would through errors. We had many growing pains. Users in Salesforce that were in our system but had differences in their settings (such as switched spelling of the username) caused lots of duplicates. Then the duplicate accounts took training and that started throwing odd enrollment errors.
Eventually found that as we get a handle on detecting and fixing the duplicates the enrollment issues went away. But we are still limited with how the synced users are limited to username match and how they are placed in our branches. It is very limiting.
The user sync adds an SFDC_ID to the Docebo users and this is how Salesforce know that user A in Docebo and user B in Salesforce is the same person. Without this, there is no way to associate the records in Docebo to the user in Salesforce.
The connector, info below, appears to be much more flexible. Plugging in through the API and having object based interface for setting up the connectors.
The user sync adds an SFDC_ID to the Docebo users and this is how Salesforce know that user A in Docebo and user B in Salesforce is the same person. Without this, there is no way to associate the records in Docebo to the user in Salesforce.
The connector, info below, appears to be much more flexible. Plugging in through the API and having object based interface for setting up the connectors.
Ah okay - this is extremely helpful- thank you. I will review the documentation further because I do not understand why we are get user sync errors due to mismatched emails. I am assuming it is because the SFDC_ID is simply a lookup field and not a primary key. So if we are using email addresses as people’s username (which is the Docebo primary key) it will throw the error that the user already exists (with a different username).
Our actual use case is that both SFDC and Docebo get populated with users via our SSO solution, although maybe at different times -- I am trying to figure that out as well. We only need to send certification data from Docebo to SFDC. Right now it is going across as learning plan completions.
I am trying to figure out the best approach to redo this so it works. I am happy to try the API or middleware connector option, but looking to figure out what I can user for a primary key in Docebo versus SFDC since our user name and email info changes so often.
@amber - correct, for example, in our Salesforce their usernames are their email addresses with .eu at the end. As a result, the usernames on our side have to match. Same with email addresses. If a user has a couple of letters flipped, pretty easy with longer names, then it generates a duplicate user on the Docebo side.
Our Salesforce instance also had duplicates in their users. They setup a dashboard to identify duplicate users in their system. This is checked every day or at least often. We have similar reporting checks on the Docebo side to do this.
Having a duplicate user is one problem, having a duplicate user where the user logs in and takes training is a bigger problem. Not detecting this for weeks and trying to fix it all is not fun at all!!!
SFDC_ID is the internal ID used by Salesforce for a user, similar to what Docebo does. If I recall correctly, they index those points on both sides.
We tried the SSO solution. Due to some of the items above it generated a LOT of duplicate users.
If a user is SSO, whether internal are external, they are added to Salesforce and then come into Docebo via a sync. This reduces the tool tickets to add users to both tools by half.
Our Salesforce users sync into an SSO branch with sub-branches for internal and external users. Due to this limitation, we could not use SSO to create users. In addition, our practice was to move inactive users to an inactive branch. But if they are still in Salesforce, then they are pulled back into the associated internal / external branch.
So, yea, I would do it differently if I had a choice.
So, yea, I would do it differently if I had a choice.
Totally makes sense. The rabbit hole just gets deeper and deeper with all the possible iterations of messy data.
@amber - Yea, you got a big chuckle out of me on that one. I had looked at the Salesforce user data prior to integration and it was a mess. But I was told (by SF folks) that we could filter around that.
That wasn’t the case. It took a while to get the data cleaned up. Stuff still crops up periodically.