Hi @Eric M VanAuken yes you can do this in any of the methods you wish but you need to have a file that will take your raw data and transform it to “Docebo” format I order to make it work. If using a fully automated solution where you have an FTP server, you can write rules to transform your raw data to the format yo need. If using something like the automation app or CSV import, you would transform the data outside Docebo and then load those ‘final’ files. We had to get the services of a developer for the fist option.

What we want here is the native ability to do this via SAML. Having linked numerous fields to an EE instance of SAML, it is strange we can’t link ‘Is a Manager’ or ‘Direct Manager’. We want to have a fully automated solution stemming directly from Active Directory to Docebo. As this doesn’t seem to be possible, we were wondering if there was some workaround via tying User Additional Fields to the actual ‘Is a Manager’ and ‘Direct Manager’ fields. You can provision essentially anything in Azure, but seemingly not in Docebo.

Using CSV is our current state, but we are moving away from that as people make mistakes on spreadsheets, it is time consuming, and while it works, our customer is requesting better automation. An FTP server is sort of a last resort here, as we were unsuccessful coaching this same client to set it up in the past.  

Let me know if that clarifies the dilemma.

@tommyVan  and @Eric M VanAuken 

At this time it’s not possible to map manager status and manager assignments via the SSO. The only options are via API or having the LMS pick up a CSV file on a specified cadence via the SFTP and the automation app (as well as manually loading a csv). 

We have many customers who are accomplishing this via active directory and our APIs and my suggestion would be to use the batch import users api which can be used to both create and update users.
 

Post - /manage/v1/user/batch

You can read more on the parameters and schema by navigating to the API browser at yourdomain.com/api-browser. 

I’d also suggest reviewing the API Documentation located here

I searched through the ideas portal and discovered that there’s a technical reason we don’t support it. 

thanks for this idea and apologies for the delay in updating the status. The team reviewed and determined that they do not plan to implement this because Saml attributes map to user attributes and manager is not a user attribute, it is a relationship between two users. If the manager did not exist (never logged in, etc), there is no way to create the relationship. We have the ability for both users and/or managers to select their subordinates/managers if you don’t want to rely on a csv or similar to make these associations.

Unfortunately that is what I expected to hear.   Most other LMS systems have moved away from CSV files as they are not easy to maintain and are much older technology.    

II would love to use the API approach but the agency that needs this does not have an API expert to manage this.  

In short the best long term solution would be to modernize your SSO so that it includes all the appropriate fields.

@pmo Unless I’m fundamentally misunderstanding how relationships are built between users, this answer doesn’t cut it for me. Theoretically here is how I see it working:

1. Associate ‘Is Manager’ with field in AD
2. Associate ‘Direct Manager’ with field in AD
3. User A with ‘Is Manager’ field Logs In for first time; account is created.
4. This triggers them to have the My Teams view (if set up this way)
5. User B with ‘Direct Manager; field logs in for first time; account is created.
6. The value for User B’s ‘Direct Manager’ is filled with User A’s name by IDP Admin
7. Since User A ‘Is Manager’ and User B indicates that their ‘Direct Manager’ is User A, the communication completes. 

Perhaps you could provide a technical expert to explain why this isn’t how this works. I have a gut feeling that the team simply didn’t want to build this functionality.

@tommyVan I understand your frustration and I understand the difficulties of managing an LMS with a limited technical resources.  I would definitely work with your account manager to see what they can do to help you find additional information outside of the community. 

I would like to reply to your post though and mention that the limitation I posted is that when “user B” logs before “user  A” then there would be no “user A” to map to which isn't covered in the post above. I’m just an LMS admin and don’t work with product so I can’t really expand more on the technical reasons persistent with SAML/Oauth/OpenID  but I’m wondering if that might be the issue since it was mentioned as a previous reason for not moving forward with the change. I’ll continue to see what I can find internally and report back with anything that I find. 



 

@pmo Appreciate all of the effort being put in! 

Thank you for your response.  The real issue is that we already have the option to make that same mistake in doing a CSV type file approach.    I believe this should be re-evaluated as this is how other LMS systems operate and they do not seem to have this issue.

• Eric VanAuken

@pmo Any updates on exactly how direct manager is a relational field? I’ve done some digging into APIs and when you call a user, one of the user fields that is returned is Direct Manager. That would seem to indicate that this isn’t a relational field after all. 

Furthermore, in the example you gave 

 “user B” logs before “user  A” then there would be no “user A” to map to

the field for direct manager for user be could be written something like:

function returnsNoDirectManager(){ if (userB && !directManager) {

return ‘No Manager Found’}

}

There’s clearly something Docebo isn’t explaining correctly about why the user field Direct Manager cannot be mapped via SSO.