Add business information to the database (for searches, importing to HubSpot, etc.)

[mkdir-washington-edu]

Request There are types of business information that we need internally in order to better serve our partner institutions. This information can be manually entered into a CRM, but for certain types of information it's more efficient to have the information calculated and available in the database than entering it manually in a CRM.

For example, there are several types of Canvas install. You could have:

• Course level installs without a Dev Key (each active course uses a different Key/Secret)
• Course level installs with a Dev Key
• Sub account or account level installs without a Dev key (all active courses use the same Key/Secret, indistinguishable from course level installs using the same Key/Secret but in a practical sense that's ok).
• Sub account or account level installs with a Dev Key
• Installs with a Dev key that have disabled Sections
• Installs with a Dev key that have disabled Files

Future product offerings will increase this complexity, with Groups availability in Canvas, to file and group access in other LMSs, etc.

It can be difficult for our team to track what internal decisions a school made when installing. Here's an example of a school where one instructor definitely doesn't have Canvas Sections access, the Canvas admin says they want to wait to upgrade until the semester break before upgrading to the Sections integration, and a different instructor claims to have used the Sections integration successfully this current semester.

[klemay]

Questions:

• Can you tell me more about the value of having this stored in the Db and then sent to the CRM, rather than storing in the CRM in the first place? I understand that automatic data collection/storage is more convenient than manually entering, but what about info that isn't available automatically? For example, we have no way of knowing whether a Canvas install is at the course level or account level based on the launch info. That's always going to have to be manually recorded by the team.
• Exactly which data points would be needed? You helpfully listed out some for Canvas, but we would need a full picture of the type of data the team would expect to see in the Db.
• If we're able to collect some but not all of the desired data, would the team keeping track of what's automatic vs what needs to be manual be workable?

A couple notes:

• Sections vs no Sections is already noted in the Db
• I didn't think it was currently possible to disable Files access with the Canvas Dev Key. The only way a school should have no Files access is if they don't have a Canvas Dev Key associated with their install. I thought disabling any part of a Canvas dev key which is used by our app would cause the app to crash (I believe that's a limitation of the Canvas API). Am I wrong here?

[mkdir-washington-edu]

Can you tell me more about the value of having this stored in the Db and then sent to the CRM, rather than storing in the CRM in the first place?

It can be difficult to parse what is happening install-wise at an institution, and manually entering this in the CRM for every partner school isn't going to scale. The complexity is also going to get worse as we build more features for more LMSs. Even without knowing whether we're installed at the course, sub-account, or account level in Canvas, here are the different install scenarios we encounter.

For courses with a group creation date within a certain time frame (meaning courses that are probably used in the current semester/quarter):

• All courses use the same Key/Secret, without Dev Key

• All courses use the same Key/Secret, with Dev Key

• Some courses (at the same tool_consumer_instance_GUID or LMS URL) use different Key/Secrets, none with Dev Key

• Some courses (at the same tool_consumer_instance_GUID or LMS URL) use different Key/Secrets, some with Dev Key

• Some courses (at the same tool_consumer_instance_GUID or LMS URL) use different Key/Secrets, all with Dev Key

• All courses with Dev Keys have Sections turned on

• Some courses with Dev Keys have Sections turned on (in the scenario where we upgrade an institution to Sections, but some courses have already launched Hypothesis)

• No courses with Key Keys have Sections turned on (either using a Key/Secret form before the Sections upgrade, or where we have "downgraded" an install to remove Sections at an LMS admin's request).

• Some courses (at the same tool_consumer_instance_GUID) using different Key/Secrets have different LMS URLs (indicating probable incorrectly made Key/Secrets).

Looking ahead:

• Institution has turned off GDrive (once we implement https://github.com/hypothesis/support/issues/179)
• Institution has turned off Canvas Files (again, once we implement https://github.com/hypothesis/support/issues/179)
• Similar info about OneDrive, once that integration has been created.

Once the API integration with Groups has been built we can expect to see the same scenarios we see with Sections:

• Institution has turned on Groups for all courses
• Institution has turned on Groups for some courses (where, like with Sections, we've upgraded an isntitution on our end but some courses already launched Hypothesis)
• Institution has turned off Groups for some or all courses (because they have a pre-Groups Key, or because we "downgraded" them at their request).

I hope the list of present scenarios and future scenarios (as we build more features) makes it more apparent why we can't do stop to figure this out for every partner institution, especially as institutions may change their installs (by generating a new Key/Secret after new feature are created) without telling us.

[mkdir-washington-edu]

Exactly which data points would be needed? You helpfully listed out some for Canvas, but we would need a full picture of the type of data the team would expect to see in the Db.

I hope the list above spells that out. The data needs are only going to grow as we build new features.

If we're able to collect some but not all of the desired data, would the team keeping track of what's automatic vs what needs to be manual be workable?

I think everything in the above list can be tracked automatically. The goal would be to not have any manual tracking of this data.

Sections vs no Sections is already noted in the Db

It can be time consuming to pull this up every time it's needed, and more importantly it's difficult to tell when we run into scenarios where it's enabled for some courses and not others.

The example school I link to also shows where we can't rely on LMS admins to tell us for sure whether or not Sections is enabled.

I didn't think it was currently possible to disable Files access with the Canvas Dev Key. The only way a school should have no Files access is if they don't have a Canvas Dev Key associated with their install. I thought disabling any part of a Canvas dev key which is used by our app would cause the app to crash (I believe that's a limitation of the Canvas API). Am I wrong here?

It is not currently possible. We've received requests to make this possible (for Files and/or GDrive) and have an issue (linked in the scenario list) to do this work. I anticipate we'll get more requests for this once we've enabled OneDrive since at that point OneDrive schools will want to cut off instructor personal GDrive or Files access.

[mkdir-washington-edu]

Making a note for when I can get back to this. It would also be really helpful to have an in-database way to distinguish piloting, paid, and free partners. It's frustrating to try and run analytics without this information.

[mkdir-washington-edu]

Much of the above is handled now either in our LMS or by the data pushed from our DB to our LMS. In addition we're making more improvements to available internal data. I on longer this this issue is relevant and am closing.