Skip to main content

SalesFORCE and Branches - How do other organizations manage this?

  • August 28, 2023
  • 1 reply
  • 31 views
N
Novice I

 

WE are still having an issue with SalesFORCE and Branches with users being moved into the root folder if the branches do not sync.  This has become such a manual process, that seems to be never-ending since we have over 600 users and we have many reorgs, therefore, users are constantly moving, or new hires joining.  Does everyone that has SalesFORCE and the stand-alone app have this same issue??  When you create a users on the stand-alone app and put them in a certain branch, then the CRM teams gives that user SalesFORCE access a week or so later, and they go into Docebo through SF - they end up moving the user out of the branch I created and instead back to the Root folder?

We have 2 diff teams that work on this - the CRM team who runs SalesFORCE and our LMS team.  Therefore, this has become such a process (bc we have about 900 users and counting) that are constantly being moved or updated if we are not quick enough to provide the CRM the exact branch name we created. We also have to rely on them to update the branch for us, which has now added so much more work onto their job.


I cannot see how an org with thousands of users is dealing with this?  again, yes, our org def has new users and user structure so this is def not ideal.  Looking for ideas, help or feedback!  How do you make this work for your organization???

Did this post help you find an answer to your question?

harnish17
Contributor II
Forum|alt.badge.img
  • harnish17
  • Contributor II
  • March 24, 2025

Hi Nikkic,

I can describe how we manage this. Our use case is a bit different as we’re focused on external (customer) education for now, but I hope some of this is helpful. 

We treat Salesforce as the single source of truth and then force Docebo to align to Salesforce. It sounds like you almost have two sources of truth (Docebo and Salesforce) and are struggling to keep them aligned because the synchronization of data is done manually.

Here’s how we treat Salesforce as the source of truth and pass that data to Docebo. Each Salesforce contact has a contact ID and account ID. These are visible in the web link. So when I navigate to my contact in Salesforce, the url shown in the browser looks something like this: https://company.lightning.force.com/lightning/r/Contact/0030z00002QJCQeXY3/view. So my contact ID is 0030z00002QJCQeXY3. If I open the account that contact is associated with there will be a different url and the account ID will be visible in the same location in the URL. 

So how do we get that to Docebo? We created two additional fields in Docebo: Salesforce Contact ID and Salesforce Account ID. We use SSO to login users to Docebo and pass this information from Salesforce to Docebo automatically via SSO. In the SAML SSO configuration we have mapped the Salesforce account ID to the branch code. If a user’s account ID matches the branch code, they will automatically be moved into that branch. This happens on each login so if somebody’s account ID changes, they will be moved into the new branch the next time they login (assuming there is a branch with that branch code; otherwise they will go to root as you know).

If you are not using SSO to synchronize this data, I imagine you could use Automation/API/Docebo Connect, etc. to automatically synchronize the data at a regular interval. 

In your case I believe your 600 users are internal employees? If so, is Salesforce the source of truth for the org structure or do you have an HRIS system which is the source of truth? When we move on to expanding our use cases for employees, I will likely use HRIS data to set the branches for employees and Salesforce for customers.

Apologies if I missed the mark and didn’t directly answer your question, but hope some if it is helpful.

 

 

Reply


Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings