Child Item

Simplifying App Access: Introducing Canvas Apps Availability & Exceptions

The Need

We've heard you—installing and managing LTI 1.3 tools has been a challenge. Getting an app running should not take a full page of technical instructions spanning across at least 3 web pages. As we’ve built out Canvas Apps, we knew that this was a core issue we needed to resolve. Our initial steps with the Discover page and Dynamic Registration started to chip away at this problem, but we knew we could do better than requiring you to still copy and paste Client IDs for deployment.

Beyond installation, we know tool management is a major undertaking. Tracking where a tool is available (down to the sub-account and course level) often requires keeping separate, complex spreadsheets. Making a tool available “everywhere except…” was next to impossible, requiring a tool to be installed in every context individually except. Plus, dealing with unique deployment IDs for every context added unnecessary overhead.

The Solution

To simplify these processes, we’re introducing the post-install tool details page, including the Availability and Exceptions tab. This is the new command center for app access controls as of the February 2026 production release! The core concept is straightforward: Available or Not Available.

When you configure a new tool, it starts out as Not Available by default. You can then switch it to Available to make the tool accessible organization-wide if needed. Or, if you prefer, you can leave it as Not Available.

Modal enabling you to add additional contexts for a tool to be available or not available in

From here you can create “exceptions” to the root availability. For example, you could leave the tool as Not Available at the root level and make it available only in one Sub-Account (Carkeek Park Middle School in the screenshot below.)

List showing a tool which is not available at the root level but available in a sub-sub-account.

If you later decide to deploy it to a second school, you can do that and it will use the same Deployment ID.

This model also supports the concept of making a tool available “everywhere except…” Now you would simply make the tool available everywhere and set up an exception for the excluded context. In the example below you can see that the tool is available in the entire school district except the Elementary sub-account.

List showing a tool which is available in a sub-account, but not available in a sub-sub-account below that.

This feature is designed to give you granular control with centralized visibility.

Honed by customers

A huge thank you to customers who have tested our early experiences! Their feedback has been invaluable in shaping this feature leading up to General Availability. We’ve incorporated several thoughtful suggestions:

Each context listed is now a direct link, making it easy to jump in and verify your settings look exactly as expected.
Sub-accounts now appear first when browsing for contexts, streamlining the most common way availability is managed.
You can now use the ID from a course URL to search and add a tool's context—perfect for when instructors send a direct link to their class.
When a course is copied, its course-level exceptions are not copied, preventing the accidental spread of tools into new courses where they aren't authorized, needed, or funded.

History Tab

We know that when a tool stops working, you need answers fast. That's why, alongside Availability and Exceptions, we’ve created the new History Tab.

This tab provides transparency by logging every update to a tool:

When the change occurred
Who made it
Which fields were affected (including availability and exceptions)
Before and after values for the fields

Detailed history modal showing specific scopes and placements which have been updated

If a tool disappears or suddenly breaks, you can instantly check the full change log for configuration or availability/exception updates to troubleshoot quickly. This should simplify troubleshooting and improve transparency across your organization.

What’s Next?

We’re not done yet! We’re continuing to work on improvements to make tool management even smoother, including:

Linking directly to the documentation
Taking you to the Availability & Exceptions page immediately after installation
Enabling you to modify the default icon for an app

The planned work will not change major functionality, but we hope it continues to make the process easier and more efficient. If you have feedback, please let us know in the comments or join the Feature Group which will be available until April 17, 2026.

We are also conducting research about the impact of Canvas integrated apps on teaching and learning. We invite all administrators to participate in this survey.

Find more posts tagged with

Canvas LMS

Comments

dtod

This does not appear to work for inherited apps? I get a consistent error when I try to adjust, e.g. placements.

dtod

But it is, broadly speaking, a massive and welcome improvement!

dtod

…and if Instructure updates the app, it overwrites any adjustments we have made. This has always been the case, but is still annoying.

dbrace

Hi @AlexisNast,

For an LTI 1.3 app, if a specific placement is turned off and/or on, will that cause an entry to appear under "History"?

I am asking because on "late Friday night", an LTI 1.3 app and one of its configured but intentionally disabled placement was changed from disabled to enabled.

From what I could tell by looking at the API for external tool before disabling the placement, its "updated_at" information was also "late Friday night" and I believe it is related to this release.

-Doug

AlexisNast

Unfortunately we don't support modifying inherited keys through this UX yet. The Edit button being available was an error and we're currently working on a fix. We also have a project we're currently in the middle of to rearchitect Inherited Keys and allow for permanent customizations to be made which will persist even when we update the key. I can't give a specific date on that yet, but it will be available before the end of the calendar year for sure (hopefully much sooner than that!)

AlexisNast

Was this an inherited key? Those work a bit differently, unfortunately. If it was not an inherited key then yes, the placement changes should show in history.

dtod

Thank you. I assumed that was what was happening.

dtod

What permission is required to be able to Monitor usage at a sub-account level?

AlexisNast

LTI Registrations - Manage (per the release notes.) Note that there is no Discover or Manage at the sub-account level and no concept of configuring a tool at the sub-account level, so this will NOT grant those users access to Discover & Manage unless they have root account access with the role granting the LTI Registrations - Manage permission. My team has a plan to try to simplify and clarify these permission names, but it will likely take a bit as there are other items with higher priority right now.

Child Item