How can you onboard a user to a specific branch using provisioning?
Hello and thank you for reading this,
We have a situation where we need to use Okta Provisioning. Using provisioning puts this user into the root branch. Is there a way we can force these Okta users into a specific branch?
Our new users will not know what branch they are assigned yet. They will be required to enter
first name, last name, and email address, from there can they be put into a default branch?
Thank you,
Page 1 / 1
HI @ncassella not familiar with Okta, however if this works like other tools and it’s based on a file import, you can add 2 columns to your input file that carry the branch name & branch code. Alternatively, you can also set a default branch in the import rules (same as you can see when performing a manual CSV import). Not sure if this addresses your question.
@ncassella
If I understand you correctly
You’d like to use Okta Provisioning but it’s currently putting your users in the root branch.
Your new users will be required to enter First Name, Last Name and Email address (Within the LMS I’m assuming or within OKTA?)
Ideally you’d like this to default to placing them in a specific branch OTHER than the ROOT branch.
In most cases when clients are using SSO and User Provisioning they’re provisioning from some sort of HRS system and their branch structure (Branch names, codes, hierarchy) is configured to match the hierarchy in their HRS system. This is because when we provision users we can map “Branch Name” or “Branch Code” to some field in the HRS (for instance like “Department”). So when a user is provisioned via okta the user will be slotted into their “Department” branch.
It’s not clear from your post whether you have that information so let’s assume you didn’t and instead you wanted all users provisioned via OKTA to land in an “Employee” branch. You could create an attribute/custom field in OKTA called “Branch Name” and then manually assign a value of “Employee” to that field for all users in OKTA. Next you would just need to map that field in the SSO app and ensure that you’re passing those OKTA attributes in your claims.(Some of these details on the sso configuration are a bit murky so I would rely on Docebo Support and your IT team to verify.). The next time the user logs in or the next time a new user is provisioned they should be sorted into the correct branch.
Thank you for that collegiate try Irnlab! Not really importing, sort of like a self registration but they exist in our Active Directory but not onboarded yet to Docebo.
We have a Branch_name field in Okta, and linked it to a specific branch in Docebo using that table showed above that you posted, but it didn’t work.
If fact only the username worked, the rest of the fields didn’t work: first name, last name, email address, or branch. Docebo put this new user into root branch without adding the attributes..
Except for the username the attributes are not populating. I missing something, can’t put my finger on it.
Yes: for users not onboarded in Docebo they will be provisioned using provisioning and OKTA.
We are using a Okta test user with premade attributes. The user has first name, last name, and email address already setup in OKTA, the provisioning did not bring that over.
I hope this described it better.
@ncassella I
Support will be able to turn on saml logging and then have you conduct a test and review how the claims are being passed, formatted and what attributes and attributes names are being passed.
In the meantime I would verify the following:
Doublecheck that the attribute names you have in Okta match the mappings in the SAML app in Docebo
Ensure that you’re passing those attributes as an array rather than parameters in the request.
Good Idea about the logging. I’m realizing it starts with the attributes. I’m starting to figure it out how to map them and got two working.
We can consider this closed. Thank you all for your support and quick replies.
@ncassella Glad to hear you’re making progress!
Could do our community manager a favor and mark one of the replies as “best answer”. This helps us track what threads might need some additional help and which threads we would consider “closed”.
Thanks!
I am currently struggling with this exact problem using Azure AD, not Okta. However, new users that are not in the LMS aren’t even able to use the SSO button. Existing users are able to sign in with the SSO button.
@tommyVan
“However, new users that are not in the LMS aren’t even able to use the SSO button”
Do you have user provisioning box checked in your SAML app?
@pmo Link to my post:
I do have the User Provisioning box checked.
Hi - we are currently using Azure for SSO and am running into the same issue with needing to put users that are created via sso into a specific branch, rather than the root branch.
Our Azure Active Directory has guest and member accounts - is this a filed be used map as an attribute statement? My internal IT contact said that for guest Active Directory accounts, we are only capturing name and email address so I’m trying to think creatively, making what data is already in there work.