Engageli determines each participant's classroom role by mapping the user's LMS course role to an Engageli role. For example, the mapping used with Canvas LMS is shown in the below table:
| Canvas Course Role | Engageli Class Role |
| Teacher | Instructor |
| TA | TA |
| Student | Learner |
| Designer | Learner |
| Observer | Learner |
When a user has a custom LMS role, Engageli normally falls back to the base role that the custom role was originally derived from.
Engageli also supports direct mapping of custom roles to specific Engageli roles. Instead of relying on the base role, you can explicitly define how a custom role should be interpreted. Enabling this requires two integration updates:
- Inform the Engageli team which custom role you want mapped and which Engageli role it should correspond to (Instructor, TA, or Learner).
- Ensure the custom role is included in the LTI launch payload under the "https://purl.imsglobal.org/spec/lti/claim/custom claim", specifically in the course_roles field. Most LMS platforms allow custom fields to be passed through LTI configuration. For example, in Canvas, you would add: course_roles=$Canvas.membership.roles
Below are important notes about this feature:
- Custom role mapping applies only to custom roles; built‑in LMS roles cannot be remapped.
- Custom roles are sent only during an LTI launch when the user clicks the Engageli link inside the LMS.
- Roster‑sync operations do not include custom role data, so Engageli cannot apply custom‑role overrides during roster sync.
- In practice, this is not an issue because users enter Engageli classrooms through the LTI link, which does provide the custom role and ensures the correct mapping is applied.