I have not. But would love to hear if anyone else has had experience with it.
You have experienced some of the same pain points as we have. For us one of the front runners is power users and the ability to impersonate only being super admin level. That leaves our whole system exposed as we have an entire support organization that needs to impersonate to help users, but they do not need to be able to manipulate course content or anything like that.
@B_Volkman_CAVA
Thanks for asking the question. Very happy to see that I am not the only person who is stuck with hours of time spent on all the admin stuff.
My use case is we need to have an unique identifier built in our Docebo platform, and would like to then cross check with another database system to verify if the person identified has completed certain training. Do you or anyone within the community have a similar use case on this?
Any suggestion would be helpful. I am basically stuck and needs help.
Thanks everyone.
How does your team automate power user profile assignments? Are you able to automate assigning a user as a power user too? For us, we were able to import a csv at the start but I’ve been manually adding power users as an employee moves into a management role in our stores. Would love to get that automated but currently I have to assign a user to a power user role, then assign the correct resources, then assign the correct branch they are a power user over. It takes a while every time I do it.
I’m a little late to the party, but I’ll share my perspective anyway in the hope that it helps somebody. We are using Docebo Connect, and in fact we participated in the Beta program (about a year ago now). I have only good things to say about the product as a whole, but I think it might help if I explain our context a bit, and then raise a couple of things that you may want to consider given the context you already shared in your post, @B_Volkman_CAVA.
A couple of things about me: I can read API documentation fairly well, and I am capable of writing a bit of toy code. This has helped when investigating future integration possibilities and occasionally building a proof of concept. Importantly, however, my coding skills are not sufficient for building robust or reliable integrations between e.g. our HRIS (BambooHR) and Docebo. That, by the way, was the first problem we were trying to solve when we participated in the Docebo Connect Beta, but we knew from an early stage that it would not be the last. We later added connectors for Airtable and Google Calendar to the one we already had for BambooHR, and at this point I’m thinking about which other connectors are at the top of my wishlist (probably Workbot for Slack).
One thing you should understand about Docebo Connect is that it’s powered by an integration platform called Workato. I consider this approach to be a bit of a masterstroke on Docebo’s part, to be honest. As a Learning platform, why get into the business of competing with integration platforms like Workato (or e.g. Zapier) when you can partner with one of them instead? On which note, I’ve tried Zapier as well, and Docebo Connect is so much more powerful.
What does this mean?
- You’re in full control of the logic of your integrations.
- Your recipes (i.e. scripts) are, to a large extent, self-documenting due to the graphical user interface. If your colleague leaves at short notice, his or her recipes can still be maintained.
- If your connector is an “official” or “supported” connector, building the recipes is easier because the most common actions have a guided form to help you set them up correctly.
- Less common actions can still be done with custom API calls (but you’ll need to read the API docs in that case).
- If your target service does not have an official connector, you can still do some things using a generic HTTP connector; this takes care of the authentication part for you, and you can then use custom actions (again, reading the API docs).
This last point may be relevant to you, @B_Volkman_CAVA – unless I’m missing something, I don’t think UltiPro has a connector for Workato. This would make your life harder, in my view, since Docebo Connect would not be that much easier than writing code based on API docs. There are some advantages still: you can use the rest of the Docebo Connect product – the graphical recipes; the triggers/variables/lists, etc; and of course the Docebo Learn connector itself – and you could probably do most of the same things you’d want to do. However, writing and maintaining the recipes would be harder as you’d need to know how to construct the correct API calls for UltiPro.
Regarding the other use cases described in this thread:
Sorry for the wall of text – I’m happy to answer any questions about this.
@Ian love the writeup here, glad you’re seeing (and sharing) the value of connect. I’m adding @daniele.minoia here just for visibility as Connect was his brainchild He’s a smart one, that Daniele.
@gcrawford88 I agree that Connect won’t help solve power user ability to log in as other users. However, we’re developing this capability right now natively! If all goes well we should see it in sandbox in the next month or two, then on to production.
Nate
@B_Volkman_CAVA I’m curious to learn more about the Power User assignment automation you have configured. I think of Power User provisioning has having three steps: Assigning the role, assigning the profile and assigning resources. Have you been able to automate each of these, or are there still manual follow up steps required? Could you point me towards any resources you used to assist in configuring this API?
Has anyone used the Docebo Connect with its Outlook 365 recipes? We are trying to improve upon the ILT calendaring experience and hoping that Docebo Connect can help resolve it for us.
We currently have it setup as POC in our sandbox portal with a SuperAdmin’s Outlook mail/calendar account, and have tested it; however, the ILT invites are still sending the ICS file and they are not being sent through Outlook 365 as a calendar event.
Hoping someone can help us.
One of the original use cases asked about was unenrollments. This is a major issue for us, so I was wondering if anyone has successfully used Connect to handle this sort of thing?
There’s actions for unenroll in sessions so it should be fairly straight forward, the bigger piece is just identifying the users you want to remove.
OK, that’s interesting. Presumably you could use User Additional Fields to target users?
Has anyone used the Docebo Connect with its Outlook 365 recipes? We are trying to improve upon the ILT calendaring experience and hoping that Docebo Connect can help resolve it for us.
We currently have it setup as POC in our sandbox portal with a SuperAdmin’s Outlook mail/calendar account, and have tested it; however, the ILT invites are still sending the ICS file and they are not being sent through Outlook 365 as a calendar event.
Hoping someone can help us.
This seems like a meditated decision to keep this feature (sending calendar invitation instead of ICS) out of the Learn package as stock to push users to Connect. this should be a basic built in option.
OK, that’s interesting. Presumably you could use User Additional Fields to target users?
Hmm, I guess I just figured you were doing something like “the user did not attend a session, unenroll” so that they don’t have to know how and use the switch to enroll in another session at which point a report would do the trick. I guess the question becomes, what are the scenarios for unenrolling you are trying to solve for to be able to answer that question better?
Hi @Bfarkas
It’s actually normal courses in our case. As an illustrative example, imagine a cohort of 100 users who have access to two catalogues, each of which contains a large number of courses. 50 of these users then need to have access to one of the catalogues revoked. However, any courses they are already enrolled on would remain accessible to them. AFIAK, the only way to solve this from the Learn UI is to manually unenroll them from the relevant courses.
I have been wondering whether Connect could help automate this unerollment process - eg, If some User Additional Field = some value then unenroll from all courses in catalogue X.
Ah, yeah that makes sense. Too bad it is catalog based as there’s no we hook for that, could skip the additional field and just base it on when the user is removed from catalog, what are you using to change that privilege, maybe something there can simplify it. I try to use additional field as my last option as it tends to still be a manual one for most people and situations, plus avoids their limit.
I see, so in terms of a trigger would using an automatic group do the trick? ie, when a user enters or leaves a specific group, this triggers the unenrollment from all courses in a catalogue or category?
I see, so in terms of a trigger would using an automatic group do the trick? ie, when a user enters or leaves a specific group, this triggers the unenrollment from all courses in a catalogue or category?
That sounds good, I am guessing you are doing the group based on the additional field which you are manually updating? That’s where I was trying to get to is there a trigger/identifier for you to add the additional field info which could be snagged instead and skip the field and group all together.
Thanks a lot for these insights, @Bfarkas ! It does look like Connect could be a very useful tool to have in the armoury.
We seem to have spammed this discussion a bit . I hope some others also found it helpful!
Alan
So do you license connect and that allows you to do a number of recipes or do you have to pay for each new use of connect? We are interested in using it for integration with Sharepoint but seeing the other use cases here I could easily see several uses.
So do you license connect and that allows you to do a number of recipes or do you have to pay for each new use of connect? We are interested in using it for integration with Sharepoint but seeing the other use cases here I could easily see several uses.
QPretty sure you license the product and then you can build different recipes using it, but you should probably reach out to your CSM for that type of info since they are familiar with your whole account and the nuances of options available.
So do you license connect and that allows you to do a number of recipes or do you have to pay for each new use of connect? We are interested in using it for integration with Sharepoint but seeing the other use cases here I could easily see several uses.
@tonya.clark - My understanding is there is an initial set up fee, and then a ‘per connection’ annual fee. So if you were looking at using it for Outlook and SharePoint as an example, that would be 2 lots of annual fee.
So do you license connect and that allows you to do a number of recipes or do you have to pay for each new use of connect? We are interested in using it for integration with Sharepoint but seeing the other use cases here I could easily see several uses.
@tonya.clark - My understanding is there is an initial set up fee, and then a ‘per connection’ annual fee. So if you were looking at using it for Outlook and SharePoint as an example, that would be 2 lots of annual fee.
ouch, thats a terrible model….
ouch, thats a terrible model….
That’s what I picked up, although cannot confirm 100%. Definitely seems very steep!
@Ian seems to have a lot of connectors on the go in his post above, so may be able to shed some light on the pricing model?
Yes, hello! I’m actually no longer at my previous company, but I think I can still comment on this. So, it’s true, the cost is based on the number of active connectors. There are discounts for bundles of three or five, last I checked.
I think this pricing model has its pros and cons. For example, since you’re not billed for (or limited as to) recipes, jobs or tasks, you don’t need to worry about optimising those too much. This is helpful for those who are not e.g. programmers and therefore perhaps not well versed in how to make your recipes as efficient as can be.
On the other hand I remember thinking there was a case to be made that the HTML connector should be cheaper than “full” connectors, in that it’s trickier to set up and every action has to be a custom action. Then again, it still does the job and handles e.g. the authentication for you.
In the end it does force you to be a bit deliberate about what you’re going to automate, and weigh up whether you think you’ll be able to realise the benefit of the extra connector fee. There were times I might have experimented even more if I’d had unlimited connectors, but for the most part we could quantify what each connector had running through it and justify the cost that way.
Hope this helps.
Edit: I’m not 100% sure how it works with regards to Outlook and Sharepoint; I can imagine that Microsoft might have built those two tools in such a way that separate connectors would be required, but on the other hand maybe there’s some generic Microsoft connector? We were on a Google stack so it never came up for me.
So do you license connect and that allows you to do a number of recipes or do you have to pay for each new use of connect? We are interested in using it for integration with Sharepoint but seeing the other use cases here I could easily see several uses.
@tonya.clark - My understanding is there is an initial set up fee, and then a ‘per connection’ annual fee. So if you were looking at using it for Outlook and SharePoint as an example, that would be 2 lots of annual fee.
There is definitely an initial setup and then an ongoing connector fee. But it is per connector. Some LMSs do these as a one time fee...but because Connect is essentially a low code to no code data connector that has been white labeled? You are paying for the other service.
For clarity - because I needed to reread what was written closely? It is key to realize this isnt at a per user type of connection. What you pay for is the connect-or.
Hmm. That is interesting. Compared to the platforms I’ve worked in where you get a core set and then premium type ones are addons, I don’t know that I’d come up with half the tricks I use if I had to pay to try a new one each time. Oh well.