Skip to main content

​
Register a user to a learning path

Depending on the learning path settings, users can register by themselves (only to the public trainings) or be assigned to the learning path by administrators or managers (to any training). In both cases the same mutation createLpIndividualMembership should be used.
In case if the user is being registered to a learning path not by themselves, the current API user should be associated with ADMINISTRATOR scope. See more about the user context scope here.
The mutation accepts the following arguments:
ArgumentTypeDescription
lpIdIDRequired; ID of the learning path to register a user to.
userContextIdIDRequired in case of registration by the manager. Should be left empty in case of self-registration. Represents context ID of the user who should be enrolled to the learning path. By default, the current user from the API request will be taken.
As a result, CreateLpIndividualMembershipResponse object will be returned that contains the following properties:
PropertyTypeDescription
errors[Violation]Contains the list of validation errors, if there are any.
responseIndividualMembershipRepresents the created membership object (see below).
IndividualMembership object
PropertyTypeDescription
idIDRequired; represents the unique identifier of the membership.
learningPathLearningPathRequired; the learning path associated with the membership.
cta[Cta]An optional list of call-to-actions (CTA) that define the allowed user interaction with the related learning path based on the created membership. The full list of learning path CTAs can be checked here.
Below is an example of the registration of the user with the context ID 242 to the learning path with ID 40: 
mutation createLpIndividualMembership {
  createLpIndividualMembership(lpId: 40, userContextId: 242) {
    response {
      cta {
        actionId
        arguments {
          key
          value
        }
      }
    }
  }
}

​
Unenroll a user from a learning path

In general, the unenrollment process follows the same rules and behavior as enrollment: a user can be unregistered from any previously enrolled learning path by themselves or by administrator. In both cases removeLpIndividualMembership mutation should be used. Mutation accepts the same arguments as createLpIndividualMembership. As a result, SuccessResponse object will be returned:
PropertyTypeDescription
errors[Violation]Contains the list of validation errors, if there are any.
responseBooleanIf true, the mutation has been successfully executed and the membership was removed.
Below is an example of mutation to unregister the current API user from the learning path with ID 40: 
mutation removeLpIndividualMembership {
    removeLpIndividualMembership(lpId:40) {
        errors
        response
    }
}
⌘I