Introduction
The Docebo Connect connector is responsible for communicating with the Docebo platform using the provided actions which, in the background, communicate with the platform’s APIs.
This article describes enrollment actions available for use in the Docebo connector.
Users actions supported by the connector
These actions allow you to create, get lists of, delete and update users. Unless otherwise stated, all input fields are optional.
Get users
The Get users action retrieves a list of users based on various filters, such as ID, status, and search text. It includes options for pagination, sorting, and cursor-based navigation.
Field | Required | Description |
Pending | No | Get pending (1) users or all others (0). |
Branch ID | No | Filter results to users in a specific branch. |
Status | No | Filter results by user status. |
Search text | No | Filter results using a text search. |
Page | No | The page to return. Default value: 1 |
Page size | No | Maximum number of results per page. |
Sort by | No | Choose the sorting attribute and direction. Examples: alpha_asc
deadline_desc
score_asc
|
Sorting direction | No | Sorting direction. Possible values: asc (ascending)
desc (descending)
|
Custom fields | No | Filter results by additional field values. |
Fields to include | No | Specific fields to include in the response. |
Fields to exclude | No | Specific fields to exclude from the response. |
Show learners only | No | Restrict results to learners only. |
Show active users only | No | Restrict results to active users only. |
Show pending users only | No | Restrict results to pending users only. |
Show confirmed users only | No | Restrict results to confirmed users only. |
Show users with no branch | No | Restrict results to users not assigned to a branch. |
Show users with no manager | No | Restrict results to users with no manager assigned. |
Show users with no group | No | Restrict results to users not assigned to a group. |
Show users with no | No | Restrict results to users with no course assigned. |
Show users with no | No | Restrict results to users with no learning plan assigned. |
Show users with no skills | No | Restrict results to users with no skills assigned. |
Show users with no certifications | No | Restrict results to users with no certifications assigned. |
Show users with no enrollments | No | Restrict results to users with no enrollments. |
Show users with no sessions | No | Restrict results to users with no sessions. |
Field | Description |
Users
| The repeatable list of user records retrieved. |
ID
| The unique ID of the user. |
Username
| The user's username. |
First name
| The first name of the user. |
Last name
| The last name of the user. |
Email
| The email address of the user. |
Active
| Indicates whether the user is active. |
Pending
| Indicates whether the user is pending. |
Confirmed
| Indicates whether the user is confirmed. |
Branch ID
| The ID of the user's branch. |
Manager ID
| The ID of the user's manager. |
Group IDs
| The IDs of groups assigned to the user. |
Course IDs
| The IDs of courses assigned to the user. |
Learning Plan IDs
| The IDs of learning plans assigned to the user. |
Skill IDs
| The IDs of skills assigned to the user. |
Certification IDs
| The IDs of certifications assigned to the user. |
Enrollment IDs
| The IDs of enrollments associated with the user. |
Session IDs
| The IDs of sessions associated with the user. |
This action is equivalent to calling GET /manage/v1/user
This action does not generate a event.
Get user by ID
The Get user by ID action retrieves a single user record using its unique ID.
Field | Required | Description |
User ID
| Yes | The ID of the user to retrieve. |
Field | Description |
User
| The user record. |
ID
| The unique ID of the user. |
Username
| The user's username. |
First name
| The first name of the user. |
Last name
| The last name of the user. |
Email
| The email address of the user. |
Active
| Indicates whether the user is active. |
Pending
| Indicates whether the user is pending. |
Confirmed
| Indicates whether the user is confirmed. |
Branch ID
| The ID of the user's branch. |
Manager ID
| The ID of the user's manager. |
This action is equivalent to calling GET /manage/v1/user/{user_id}
This action does not generate a event.
Create user
The Create user action creates a single new user record.
The Create user action does not require you to supply a value for mandatory user additional fields. This matches the platform API's behavior, which allows a mandatory additional field to be left blank on creation via the API.
Field | Required | Description |
Username
| Yes | The username of the user. |
First name
| Yes | The first name of the user. |
Last name
| Yes | The last name of the user. |
Email
| Yes | The email address of the user. |
Password
| Yes | The password of the user. |
Branch ID
| No | The branch to assign the user to. |
Manager ID
| No | The ID of the user's manager. |
Active
| No | Indicates whether the user is active. |
Pending
| No | Indicates whether the user is pending. |
Confirmed
| No | Indicates whether the user is confirmed. |
Additional fields
| No | Custom fields related to the user. |
Field | Description |
User ID
| The ID of the newly created user. |
This action is equivalent to calling POST /manage/v1/user
This action will generate the Webhook event User has been created (user.created).
Create users in batch
The Create users in batch action creates multiple user records in a single request.
There is currently no hard limit on the number of users you can include in a single Create users in batch call but Docebo suggests a maximum of 100 users per batch.
You cannot perform concurrent batch actions.
Field | Required | Description |
Users
| Yes | An array of user objects to create. |
Username
| Yes | The username of the user (within each user object). |
First name
| Yes | The first name of the user (within each user object). |
Last name
| Yes | The last name of the user (within each user object). |
Email
| Yes | The email address of the user (within each user object). |
Password
| Yes | The password of the user (within each user object). |
Branch ID
| No | The branch to assign the user to (within each user object). |
Manager ID
| No | The ID of the user's manager (within each user object). |
Active
| No | Indicates whether the user is active (within each user object). |
Pending
| No | Indicates whether the user is pending (within each user object). |
Confirmed
| No | Indicates whether the user is confirmed (within each user object). |
Field | Description |
Created Users
| The list of successfully created user records. |
User ID
| The ID of the newly created user (within each created user record). |
This action is equivalent to calling POST /manage/v1/user/batch
This action will generate the Webhook event User has been created (user.created).
Delete users
The Delete users action deletes multiple users by ID.
Field | Required | Description |
User IDs
| Yes | The IDs of the users to delete. |
Field | Description |
Deleted Users
| The IDs of the users that were successfully deleted. |
This action is equivalent to calling POST /manage/v1/user/batch_delete
This action will generate the Webhook event User has been deleted (user.deleted).
Delete user
The Delete user action deletes a single user by ID.
Field | Required | Description |
User ID
| Yes | The ID of the user to delete. |
Field | Description |
Success
| Indicates whether the deletion was successful. |
This action is equivalent to calling DELETE /manage/v1/user/delete
This action will generate the Webhook event User has been deleted (user.deleted).
Update user
The Update user action updates an existing user record.
The Update user action does not block an update if a user's additional field is left empty, even if that field is configured as mandatory. This aligns the connector's behavior with the platform API, which allows updates to proceed with a mandatory additional field left blank.
Field | Required | Description |
User ID
| Yes | The ID of the user to update. |
Username
| No | The username of the user. |
First name
| No | The first name of the user. |
Last name
| No | The last name of the user. |
Email
| No | The email address of the user. |
Password
| No | The password of the user. |
Branch ID
| No | The branch to assign the user to. |
Manager ID
| No | The ID of the user's manager. |
Active
| No | Indicates whether the user is active. |
Pending
| No | Indicates whether the user is pending. |
Confirmed
| No | Indicates whether the user is confirmed. |
Additional fields
| No | Custom fields related to the user. |
Field | Description |
User ID
| The ID of the updated user. |
This action is equivalent to calling PUT /manage/v1/user/{id}
This action will generate the Webhook event User has been modified (user.updated).
Additional Fields
When setting a user's additional field of the yes / no type through Create user, Create users in batch, or Update user, the connector also supports a null value (in addition to yes and no), letting you explicitly clear that field rather than only choosing between the two set values.
Best practices
When working in specific branches, be aware that user creation and update behavior via Create users in batch can become more complex than single-user actions; test your recipe thoroughly in a sandbox before relying on it in production.
Keep individual batch calls to Create users in batch at or below the suggested maximum of 100 users, even though no hard limit is currently enforced.
Use Get user by ID or Get users with specific filters to confirm a user's current state before running Update user, to avoid unintentionally overwriting fields you did not mean to change.