First, some background...
The new Apps Manage feature is a promising step forward, but for large-scale institutions like Indiana University (IU), it needs additional capabilities to be truly effective. IU's unique scale and processes—which include nine campuses, over 1,000 subaccounts, and more than 30,000 courses per semester—mean we have different needs than smaller schools. We manage over 140 account LTI 1.3 keys, almost 1200 account-level tool deployments, and approximately 1000 course-level deployments each term for our robust eText program.
Indiana University’s eText program offers a mix of publisher courseware and specialized software for instructors to license for the courses (students pay the licensing fees). We use custom scripts to automate the deployment and removal of LTI tools at the course level. This process relies on a naming convention for our tool deployments, which allows us to identify and clean up tools after a term ends. This automated process works well for locally generated LTI keys, where we control all the parameters. However, inherited keys present a significant problem. When Instructure updates an inherited key, it resets all our customized parameters—including our unique tool names—breaking our automation scripts. This issue was recently highlighted when a Microsoft Education tool update overwrote our carefully configured placements. In an ideal world, changes to a developer key shouldn't overwrite custom display names or placements. If that's not possible, admins need to be notified about changes and have the option to accept or reject them.
Apps Manage - Feedback
As suggested above, the LTI apps management needs of large institutions like IU are likely very different than smaller schools. The work accomplished thus far in the Apps - Manage tab is exciting, and probably immediately useful to some schools, but some capabilities do not currently scale well. With IU’s needs in mind, here are my initial thoughts:
General
While the Apps Manage feature duplicates some functions of the existing Developer Keys and Settings > Apps, it lacks a few critical capabilities available:
- Toggling Keys: We need the ability to toggle an LTI key on and off directly within the Apps tool, similar to the functionality in Developer Keys. The toggle could appear on the Manage Apps listing page in lieu of the static on/off status or on the Availability and Exceptions tab.
- Adding Deployments: The ability to add new deployments to accounts and/or courses is missing. Instead, administrators must navigate to the Settings > Apps page in each context to perform this essential function. A New ( or +) Deployment button would be a very welcome addition to the Availability and Exceptions tab.
- Visibility of All Inherited Keys: The feature should show all inherited keys, not just those that are enabled. We need a comprehensive view to manage our tools effectively. Perhaps, the default view would only include enabled Inherited keys with a checkbox or widget to show/hide disabled keys. In fact, it might be helpful to do the same for account LTI keys.
Manage Apps Listing (main page)
For institutions with hundreds of LTI tools, the main listing page needs to be more functional.
- Pagination: It would be incredibly helpful to view the entire list of apps on a single page or have a menu to adjust the "items per page."
- Filtering: The ability to filter the list by account vs. inherited keys would make it much easier to find and manage specific tools.
- Disabled Inherited Keys: Include an option to view disabled inherited keys and change their status
- Date Columns: Adding sortable Created and Last Updated date columns would allow us to quickly identify recently updated keys, which is crucial for our eText management.
- Clarity on Versions: The user interface should clearly state that only LTI 1.3 tools are included in this listing. A clear redirect to the Monitor tab for information on LTI 1.1 deployments would be beneficial.
Availability and Exceptions Tab
The concept of exceptions is very promising, but it requires more robust features to work at scale. Here are several possible use cases for Indiana University
- Piloting Tools: We could deploy new tools as "unavailable" to the root account, and then create "available" exceptions for specific subaccounts like our "Experimental" one. When we’re read to make the tool available more broadly, we would simply remove the exception and make the root deploy available.
- Restricting Access: We could deploy SIS integration tools to the root and then create exceptions for only our campus subaccounts. This is much more efficient than adding tools individually to each subaccount.
- Automating eText Deployments: We could deploy our eText program tools to the root as unavailable and then use exceptions to make them available for specific courses. This would replace our current process of creating hundreds of individual course-level deployments each term.
To make this work for our eText program, two features are essential:
- API-enabled batch import: We need a way to add and remove exceptions at scale, either through the existing SIS Imports tool or a new API. This is the only way to automate the process for our thousands of courses.
- Disallow copying of exceptions: To maintain control over access rules, course-level exceptions should not be replicated when a course is copied or imported. Exceptions should only be created by a deliberate admin action.
Finally, the Availability and Exceptions tab needs a search function. For tools with many deployments and/or exceptions, it's currently impossible to find specific account- or course-level deploys.
Configuration and History Tabs
- Inherited Keys: While the ability to view the configuration of inherited keys is appreciated, we need more control. One possibility would be to allow admins to easily make an account-level copy of an inherited key and manage that copy ourselves, especially if we can be notified when the original inherited key is updated.
I also noticed a possible bug. The documentation says that the Edit button is not available for Inherited Keys, but I do see an Edit button. Attempting to save changes for an inherited key, however, returns an error.
- History Tab: The history tab doesn't currently seem to track changes. It is critical for us to see a detailed history of all changes to a key's configuration and deployments, which would help us troubleshoot issues and ensure our automations are running correctly.
Thank you for your continued efforts to improve the LTI management experience. We believe these changes would make the new tool much more powerful and scalable for large institutions.
