Why are we here?

Welcome, fellow community members! 

In watching the community grow over the past 18 months and becoming more acquainted with Docebo, I have come to enjoy finding ways to leverage advanced features of the system to build out custom solutions. These often take the form of style changes using CSS, custom workflows using webhooks and the API, and finding ways to integrate an ecosystem of applications in order to better serve learners. 

As a former, strictly learning management front end administrator, I remember the days of hearing the previous sentence and thinking “those aren’t things I can do, I am stuck with what comes in the box.” One of my favorite parts about Docebo is the way they have implemented the API that allows for someone comfortable with it to build out some building blocks using other business tools. Then anyone can quickly build small, medium, and large solutions on their own! The best part? It is not that hard to get comfortable with it!

I have mentioned pieces of some solutions in various posts before, and I think it is time to go into detail of how some of them work. The goal of this series over the coming weeks is to do just that, but more importantly look at the thought process and techniques used in each situation. The goal is not to create a series of checklists to follow, but to inspire what is possible and teach the concepts so that they can be applied to your unique situations and use the programs available to your organization.

What’s on deck?

I want to make this a useful series, so I have mapped out an initial run of articles as a starting point. Each one of these will have a focus on a technique to use that I have found useful and then walk through a few real-world examples of how it is applied.

The order was designed to scaffold the techniques, starting simple and more common (or required), and proceeding to more advanced skills. I looked at all the comments on previous posts and what the community was looking for to design these, but in the spirit of community, if there is something you are truly interested in, frustrated by, or curious about, leave a comment on this article and it will be considered.

How I design

Before we dive into everything, I wanted to take a moment and explain how I generally approach designing solutions to business of system problems. When building tools for people, I often joke that I am too lazy to see folks doing repetitive manual tasks, because it just looks like so much effort. This is at the core of triaging potential builds, and deciding if a problem is worth solving goes through the following triage:

1. Will it solve a problem that will exist for a decent amount of time?

If it is a short-term problem, the return value on the build may not be worth it. On the other hand, I have found that having a bunch of tools that can be quickly modified for one-off solutions helps to mitigate issues that would traditionally not make it past this question.

2. How much human error potential is involved, and what impact does that cause?

For me, this is my number one concern. How many times have you seen (or been) an overworked administrator, rushing through tasks that are like second nature, and you miss things, put the wrong settings in, don’t have time to do it properly, etc.? Then what happens?

You spend longer fixing the mess than it took to do the task in the first place! It’s frustrating!!

If it is a task with many choices and clicks, no matter how good you are, there will be mistakes. My goal is always to eliminate as many opportunities for error as possible.

3. If controllable, can others do it?

Often there are tasks that could easily be delegated to others, but because of certain permission needs, they simply can’t. Often using the API or similar setups, we can get around this, taking the task completely off the admin’s plate. Additionally, it may not be permissions, but a matter of too many details to remember. If you are not the person doing it everyday, it’s very hard to remember to do it accurately all the time. (Shout out to those scheduling ILT sessions!) By reducing the number of choices available to the end user, you can enable them to confidently complete the task with minimal training needed.

4. If it is not possible to solve the complete problem, can we break it into components and solve some of them?

I love this thought for two reasons. The first is that when approaching solutions, it is important to break them down into chunks. What may seem like one impossible problem can often be broken down into smaller problems, which can be easily worked through. Often “componentizing” solutions also helps you in the long run to reuse parts or leverage them for multiple solutions without rebuilding anything.

The second reason is that maybe the mega problem isn’t completely solvable, but if we break it down to six components, and five of them are solvable, a lot of potential human error is eliminated. Did you eliminate it all? No. Is it better than it was? Yes. Better is the goal, not perfection.

5. Should we be doing this, or should a real development team be involved?

Now, this one is tough to describe, but once you get bit by the private development bug, you will start to see opportunities everywhere. It is always important to remember just because you can, does not mean you should.

With each build out, you are adding technical debt to your instance of Docebo, another workflow that needs to be managed and supported, another potential point of failure for what may become a reliant workflow, etc.

If it is serious enough and it would take a week for you to figure out a solution if it suddenly stopped, maybe it shouldn’t be done this way (at least not permanently). Always weigh the true impact and resources required.

Before sitting down and drawing up any possible solution, I make sure some serious thought and discussion around each of the above has occurred. If the decision is to move forward, designing begins. This process begins as simply as possible, using only the tools necessary, as I will try to demonstrate in this series. However, with each build is the potential to add “bonus features” that may be leveraged using multiple applications, and this will also be shown in each article along the way. Each method or application added to the solution will bring its own restrictions, and it is important to begin to understand those and work them into the designs. For example, when using the Docebo API, support is only guaranteed for 1,000 calls per hour per IP address. This is a major limitation, and we will talk about some mitigation measures throughout the series, as it often impacts which solution to use when there are multiple options.

The Full Series

As more articles are published, this section will be updated to provide links to them all in order.

Guide Series:

Getting Started: Building Out Your Toolbox rPart 1] and uPart 2]

Reports: Sending, modifying, and more!

In the Room When it Happens: Act On Events with Webhooks

Bulk Scheduling ILT Sessions with a CSV File

Tag, You’re It!: Tracking and Managing Content Tags

Let Others Do It: The Power of Forms in a Workflow

And We're Back: How to Let Users have a Form as a Wizard Scheduling Tool

You Built It, They Came, Now What?: Scheduling ILT Wizard Bonus Activities

What’s Next?

I hope you enjoy this series as much as I am enjoying putting it together. The next topic is getting your “toolbox” of resources together and organized so that you are set to build some fantastic solutions. It is important to lay this base layer of understanding of API’s and how to interact with them before going further.