SIS Integration ID vs SIS Source ID? Custom params in LTI 1.3 launch id_token
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
Hello,
I am trying to grasp what certain custom fields / "lti variable substitutions" mean that come through the LTI 1.3 id_token.
Since I currently am just working off of test users that are not rostered/enrolled through a SIS/IMS flow, they are all null for me.
Specifically these values:
"userSisSourceId": "$Canvas.user.sisSourceId", // known dupe of $Person.sourcedId
"courseSisSourceId": "$Canvas.course.sisSourceId",
"accountSisSourceId": "$Canvas.account.sisSourceId",
"courseIntegrationId": "$com.instructure.Course.integrationId",
"userSisIntegrationId": "$Canvas.user.sisIntegrationId"
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
Hi @DigVargasDye,
I'm not sure that anyone will be able to give you a 100% accurate answer here, as the values you're asking about can vary by school/district/insititution depending on how their SIS integration works. I would say that in general the sisSourceId values are the ones you'll see in the Canvas US as "sis id", so they are probably the more common ones than the sisIntegrationId (or IntegrationId) values, which are used more rarely.
As for the naming disparity between sisIntegrationId and IntegrationId, I'd say it might be something that was overlooked years ago... Once something like that goes out to the public, it's a hard thing to go back and change later as it might break working integrations, and asking customers to all update their code in sync with a change from Instructure is very hard to coordinate.
I know your current environment doesn't have real values to test, but if at all possible I'd ask the school/district/institution to add some fake, but real-ish looking data o all of the fields in question so you can see how things play out on the LTI side.
Hope this helps a bit!
-Chris