Skip navigation
All Places > Q & A > Release Notes > Release Notes: Canvas LMS > Blog

Update: 2020-04-28


Since Saturday, 21 March, Canvas teams have been aligning release and deploy processes on a weekly basis. The full list of Ready Releases to date can be viewed in the Ready Release Features page, with Deploys listed in the Recent Deploys page


Ready Releases

Our teams have several projects still in progress related to our COVID-19 response. These features may continue to be released weekly when available through May 2020. If no features are ready to be released on a given weekend, no Ready Release will take place. Both the Ready Release Features page and the Canvas Release Feature Archive will indicate if no Ready Release is available for a given week.



Canvas engineers have been branching new code weekly for a deploy, but like Ready Releases, a deploy may be postponed. Both the Recent Deploys page and the Canvas Deploy Archive will indicate if no deploy is scheduled for the current week.


Scheduled deploys will continue to take place on Saturdays until otherwise determined by our teams, at which time deploys will return to their regular weekday schedule.


As per our regular deploy processes, some code may be deployed to the production environment at any time as deemed necessary by Canvas support and Canvas engineers.



March 2020


Our commitment to you, our customers, is to provide resources and functionality that best support education and those of you on the front lines. As part of this commitment, we want to release meaningful features faster than our standard process currently allows.


Ready Releases

Beginning Saturday, March 21, Canvas teams will be modifying our deploy and release processes and providing updates on a weekly basis. This change is a temporary process until further notice. These changes will help us make responsive changes as you are making your own adjustments.


Ready Release Features

Ready release features are designed to provide immediate solutions to institutions. These features are being designed to be implemented as opt-in feature options for Canvas admins whenever possible. The Ready Release page has been linked in the regular Canvas release notes page and will provide announcements about available features.


Please note that some Canvas features do not currently support opt-in functionality. Canvas teams will remain strategic for any necessary updates in those features and how they should be released.


Deploy Notes

Deploy notes will be published each week (instead of every other week). Deploys will take place each Saturday; this process will temporarily replace the weekday deploys. Bug fixes are always included in deploy notes. Deploy notes will be posted in the existing Deploy Notes page.


Process Schedule

The Ready Release process will begin the week of March 23, with the initial release on March 28. As Canvas features are managed by multiple teams worldwide, releases may extend over the entire weekend.


The first deploy adjustment will also take place on March 28—the scheduled March 25 deploy will be delayed by three days.


The recurring weekly timeline for releases and deploys is as follows based on US Mountain Time:

  • Mondays: Deploy to beta environment
  • Tuesdays: Deploy notes published
  • Wednesdays: Ready Release features notes posted
  • Saturdays: Deploy to production environment; Ready Release features available in production environment


For specific dates and times, please see Instructure Time Zone Communications. Dates are also posted in the Canvas Release Calendar Overview


Regular Canvas Releases

On the third Saturday of every month, regular releases will continue to take place as well as any Ready Release. Regular releases contain new or updated features to Canvas but are less impactful to the specific needs of institutions currently facing COVID-19. 


As our main goal is to minimize disruption to the larger needs of all institutions everywhere during this unprecedented time, we are also offering temporary opt-in functionality. All features introduced as part of a regular release date will be opt-in by Canvas admins until July 2020. On 18 July 2020, all previously introduced features will become default for all institutions, unless otherwise indicated.



We hope these changes will be beneficial to you! Please let us know if you have any additional questions or feedback.

Hi, friends! If you haven't seen the Canvas New Feature Screencast (2020-01-18) yet, we've listened to your feedback and are now making the full screencast also available as individual videos. Many of you mentioned you'd like to distribute pieces of the full screencast to share information about a feature. 


We will continue to post the full screencast for those of you who love to use those for your institutions, and full screencast description includes links to the individual videos as well.


Many thanks to the Canvas Doc Team (and specifically Nathan Atkinson) for managing the creation of these videos on a monthly basis!



For the last few years, Canvas Labs has been a magical place full of wonder. Word would spread throughout the Community—admins would promote this magical land in various discussion and question threads—and anyone who hadn’t yet received access was seeking a ticket to enter this coveted area.


Okay, maybe Canvas Labs wasn’t that magical. But it definitely seemed mysterious. It’s time to make this Community space available to everyone and pull back the curtain, because what we have here is not a secret.


What is Canvas Current Issues?

At any given time, Canvas engineers are working to resolve bugs, which we like to refer to as current behaviors or issues. In the interest of openness, we share issues in the Canvas Labs space we have identified as high priority with a broad impact, including issues that may affect the accuracy or consistency of grades or scoring data. These issues are identified by our Canvas support team as potential concerns, even before they’ve received a single support case. However, not every issue will be listed on this page.


And to emphasize that Canvas Labs has adjusted its focus being available to all, we’ve renamed the page to Canvas Current Issues.


Please note that the Canvas Current Issues page is not a replacement for submitting support cases. Our support team helps our engineering teams prioritize bugs based on how many customers seem to be impacted. So we will continue to emphasize and ask that you continue to follow your institution’s process of contacting support, as every support case helps us identify workflows that may be causing the bug and also communicates the impact of the issue.


Once an issue is closed, the issue will be changed to completed and remain in the space for three months. Completed changes are also identified in Canvas Deploy Notes as applicable.


What happened to the previous content in the Labs space?

It’s all still here! We’ve streamlined the page design and placed all the resources in a sidebar. If you’re not a Canvas admin, you probably just want to pay attention to the issues list. And if you are a Canvas admin, all the resources you know and love are just a click away.


As always we appreciate your feedback!

Several months have gone by since we introduced and implemented our new release and deploy processes. We’ve been taking copious notes with each and have made some adjustments to improve your experience.



Deploy Notes Schedule

Our teams deploy to the beta environment every two weeks (Thursday morning US Mountain time). We will now publish deploy notes the day after the initial beta deploy (every other Friday US Mountain time). This change provides advanced notice about items in the deploy that may require customer attention. After the initial deploy notes, any additional code that may require user attention per engineering will be added to the deploy notes and noted in the document’s change log. Please ensure you are following either the deploy notes document (or the entire Release Notes space) to be notified about updates. Deploy notes are posted in the Release Notes Deploys page.



Release Previews

Monthly release previews were originally noted to be available in the beta environment on the same Saturday as the production release. However, since production releases are followed by the beta environment refresh, the new functionality is not viewable until the refresh is complete. Therefore, release previews are now being enabled the following Monday. For example, our upcoming release is Saturday, 19 October; the next release preview for the following release, 16 November, will be enabled in the beta environment on Monday, 21 October. 


Release Notes Schedule

In our current release process, the release preview is available in the beta environment but release notes are not available until the following Monday. Our teams are improving their processes to know what features are to be made available as part of the release preview, and we can now curate that information one week prior.


To help bridge the gap between the release preview and release notes availability, release notes will now be published the same day as the release preview—or to think of the timeline in another way, the Monday following the latest production release. This schedule change has also been updated in the Canvas Updates calendarFor example, our upcoming release is Saturday, 19 October; the release notes document for the following release, 16 November, will be published on Monday, 21 October. 


Canvas Screencast Schedule

Currently the Canvas Screencast for the current release is posted the Monday before the release. To also help institutions prepare for releases sooner, the Canvas Screencast for the current release will now be posted one week earlier, which makes the screencast available for two full weeks in the Canvas Screencast list. Any features that may be removed from the release after the Screencast has poted will be noted at the beginning of the screencast.



We will continue to  make adjustments to better assist you and appreciate your feedback. Feel free to reach out any time.




Way back in 2014—which in Canvas time feels like an eon ago—product and engineering devised the idea of a feature option, which was a way to help each Canvas admin manage larger features that may disrupt the workflow if included as part of a regular release cycle. In the Account Settings and Course Settings pages, this new concept was given its own tab where most included features could be managed at any time. Depending on functionality, features may be able to be allowed or turned on at the account, sub-account, course, and user levels. 


Our Canvas Guides account-level feature options lesson conveys that most feature options will be optional for a short period of time. But most of you are probably thinking, what does a short period of time actually mean? Originally we noted that it would be within a few releases, based on user feedback—but clearly, if you’ve been following the feature option changes within said account-level lesson, some of these feature options have been around since 2015. 


With the recent changes in the Canvas release process, it’s time to reset expectations about the mysteries of feature options. 


Feature Flag vs Feature Option

The term feature flag is a term used by our engineers to indicate functionality that will be hidden until a later date. The functionality of feature flags allows our engineers to keep new and updated features out of sight until our product teams are ready to unveil their work as part of our new release process.


Feature flags are always enabled as part of releases. Since any change that affects user workflows is designed behind a feature flag, the majority of feature flags in a release contain small changes enabled in Canvas by default.


Feature options are feature flags that may change the workflow for common activities in Canvas during an institution's current term and allows Canvas admins to enable the feature based on their preferred timeline. These features are determined by our product team as being optional for a specific period of time, such as the case with the New Gradebook or New Quizzes. However, all feature options will eventually be enabled for all accounts (compared to a setting, which can be enabled by individual institutions on an account- or course- basis).


Resetting Feature Option Expectations

To help set better expectations, we’ll be making several changes to help Canvas admins know which feature options are truly optional and which will not be.


If you’re a Canvas admin, you’ll start to notice the number of feature options start to decline in Account Settings and Course Settings because of three factors:

  1. We’re removing any feature options that have already been enforced so they’re no longer listed in the settings pages.
  2. We’re announcing feature option enforcements that are long overdue, and then they’ll eventually be removed from the settings pages. 
  3. We’re transitioning feature options that will never be enforced and moving them to an account setting, course setting, and/or user setting.


Let’s discuss each of these factors in detail.


1. Removing Previously Enforced Feature Options

Any feature option that displays as On has been previously enforced in Canvas. These options will be removed from the page so you do not have to wonder what they are and why you cannot change them. 


2. Announcing Overdue Feature Option Enforcements 

Beginning January 2020, the following features will be enabled for all Canvas accounts:

  • Enable Dashboard Images for Courses (Course)
  • Rubric Criterion Range (Account)
  • Student Context Card (Account)


Read about the details of these features in the Upcoming Canvas Changes page.


Some remaining feature options will be enforced at a later date, but they’re mostly options that are used with LTI or SIS tools and need to be enabled by a Customer Success Manager. Those types of feature options still display in the Feature Options page when enabled, but we want to change the configuration of those features so a separate feature option does not have to be turned on for an LTI tool to work correctly. We want users to be able to install tools without requiring this extra assistance from a Customer Success Manager. These enforcements will be outlined with their changes in an upcoming release.


3. Transitioning Never-to-Be Enforced Feature Options

As our engineering teams are able, a significant number of features will begin to transition from the feature options page to account, course, or user settings. These feature options have been determined by our product team to never be enforced. 


For reference, the following features will always be optional and will eventually be moved to the following locations:

  • Account-level feature options moving to Account Settings: 
    • K12 Specific features
    • New User Tutorial
    • Public Course Index
    • Anonymous Instructor Annotations
    • Wrap event titles in calendar month view
    • Encrypted Sourcedids for Basic Outcomes
    • Content Security Policy
    • Require Usage Rights for Uploaded Files (can be enabled at the course level)
    • Learning Mastery Gradebook (can be enabled at the course level)
    • Student Learning Mastery Gradebook (can be enabled at the course level)
  • Course-level feature options moving to Course Settings:
    • Moderated Grading
    • Anonymous Grading
    • Final Grade Override
    • MasteryPaths
    • Course Set-up Tutorial
    • ePub Exporting
    • Learning Mastery Gradebook
    • Quiz Log Auditing
    • Student Learning Mastery Gradebook
  • User-level feature options moving to User Settings:
    • High Contrast UI
    • Underline Links
    • Include Byte-Order Mark in compatible spreadsheet exports
    • Use semicolons to separate fields in compatible spreadsheet exports
    • Autodetect field separators in compatible spreadsheet exports


Actual changes will be announced in the release notes as they take place, and changes may take place over several months.



Stay tuned for more updates related to feature options coming soon!

Last November we posted a proposal for Canvas release changes in 2019. Our proposal intends to improve the quality of Canvas releases, resolve bugs more quickly, and create more predictable releases with a more manageable pace. Community feedback proved highly supportive, and our engineering teams have continued to make progress with necessary adjustments. Thanks for your patience as we’ve been working out the specifics to share with you!



Release and Deploy Schedule

Since our initial proposal summary, our engineering teams have explored necessary adjustments for the feature release schedule, non-feature code deploy schedule, and the treatment of Canvas feature options.


To review terminology:

  • deploy means making code available in a specific environment; code may or may not be visible, but it is code that does not change customer workflows.
  • A release represents a scheduled event when customer-affecting code is intended to be visible.


Schedule Adjustments

The original proposal suggested that releases be moved from every three weeks to every month. The proposal also suggested that deploys would take place every two weeks.


After thorough research among all engineering teams, releases and deploys has been adjusted to the following dates:

  • Feature releases in the production environment take place on the third Saturday of every month (originally noted as the first Saturday of every month).
  • Deploys of the main Canvas codebase to the production environment take place on Wednesdays, and beta deploys take place on Thursdays (originally shown in the calendar example with production on Saturdays and beta on Mondays).
  • Deploys of supporting Canvas services are and will continue to be deployed frequently to both the beta and production environment. This behavior is not a change from current practice.

Timeline Implementation

The current date timeline for implementing these changes is as follows:

  • July 13: Last regular Canvas production release with deploy/release on the same day
  • July 15: New feature changes released to beta environment as August preview
  • July 22: August release notes published
  • July 31: First weekday production deploy (recurring every two weeks following)
  • August 1: First weekday beta deploy (recurring every two weeks following)
  • August 17: First monthly production release with new process (recurring every third Saturday of the month)
  • August 17: New feature changes released to beta environment as September preview (recurring monthly on the same day as the production release)
  • August 26: September release notes published
  • September 21: September production release date


The process would then continue according to the established cadence.


The image representation below displays a visual of the deploys and releases for August and September.



  • The beta environment data refresh and test environment data refresh will continue to take place every Saturday and with every production release, respectively, although not represented in the image.
  • The Upcoming Canvas Changes page may display an enforcement date that does not align with a feature release.

Release Strategies

Production Releases

Feature releases will be managed by a feature flag enabled by engineers. The feature flag contains all previously deployed customer-affecting code that is not made visible in the production environment until the feature flag is enabled. This functionality is like a feature option, except that all customer-affecting changes are made available to all customers at the same time.


Feature flags also protect the production environment as the feature flag can quickly be disabled by Canvas engineers if needed.


Beta Releases

On the same day as the current month’s production release, a separate feature flag will also be enabled within the beta environment containing all customer-affecting code that will be released in the following month. This change ensures that you have a full month to experience all upcoming changes in the beta environment and will include all Canvas services, such as Quizzes.Next.


The beta environment data refresh will still take place refreshed every Saturday, which means the updates available in the beta preview will not be available until the refresh is complete.


Beta Release Terminology

To better define the intention of a beta release, terminology is being renamed as a monthly preview.


This change will also align with adjustments to Feature Option terminology, which is being renamed as Feature Previews. More information about Feature Previews will be made available shortly in a separate blog post.


Release Notes

As with our current process, the first week of the beta release is still considered unstable and subject to change as engineers continue to verify the newly available code within the beta environment. Therefore, feature release notes will not be available until the following week. As our new processes become more reliable, release notes may also be able to adjust appropriately in the future.


Deploy Strategies

Non-feature deploys contains code changes that are intended to fix bugs, improve performance, and prepare for new features. We know through experience that smaller, more frequent deploys leads to a higher quality product. And when there are problems, our teams can fix them faster.

Production Deploys

Our overall deploy process has matured enough to move the primary Canvas deploys to a weekday. Deploys of supporting Canvas services are and will continue to be deployed even more frequently. To ensure that deploys are non-disruptive to customers, our teams have been planning and are already implementing several new safety precautions, including tightening our processes on how we characterize a change in Canvas (e.g. feature vs bug).


Canary Deploys

In the current release process, deploys and releases take place at the same time. Code is incrementally deployed around the world by region, and the first regions have always been the first to experience and report unintended behaviors.


The new process will slightly modify this behavior. Deploying code to a small group of end users is called a canary—inspired from historical reference of placing canaries in coal mines as a warning system. Canary deployments slowly distribute the changes to this small subset of users before they are made available to the entire infrastructure, and its impact is usually minimal. Code can be reversed or corrected before resuming deployment.


The scheduled production deploy takes place every other Wednesday, but the Canary deployment begins a day earlier on Tuesday under close monitoring. Deployment only proceeds if no problems are detected.


All customer accounts will go through a rotation as the canary for the release. Being part of the canary deployment should occur infrequently. Customers will not be notified when they are placed in the Canary deployment. Any unintended behaviors noted by an institution should be treated as part of that institution’s support protocol.


Bug Fixes

Only changes characterized as a bug fix can be deployed to the production environment at any time. Our tightened processes ensure that bug fixes are only restoring intended behavior. If a bug needs to be addressed by adjusting functionality or the user interface, the bug will be changed to a feature-type categorization and placed behind the monthly release feature flag for future visibility.


Beta Deploys

Deploys of the main Canvas codebase to the beta environment take place the day after a production deploy. Deploying to the beta environment allows our engineers to confirm the newly deployed code is not causing unintended behaviors and ensures the production deploy will be as accurate as possible. Engineers may continue adjusting code in the beta environment up to the production release.


Deploy Notes

Because engineering is creating smaller teams with quicker releases, up-to-date deploy notes would become difficult for our teams to maintain—as well as customers to reference. Notable entries for the main Canvas deploy will be available as deploy notes on the same day as the production deploys. Additionally, customers with a greater interest in the full deploy can access our open-sourced canvas-lms Github repository deploy list.


When the new production deploy process goes into effect beginning July 31, deploy notes will still be created manually and added as part of the Canvas Release Notes page in the Canvas Community. However, our goal is to make deploy notes more automated while ensuring that notable bug fixes, for instance, are properly highlighted. Automating the notes may affect the future location of the deploy notes. Discussions about automation are still ongoing, and more information will be posted as we have additional updates.


Previous Comment Concerns

We had several topics weaving through the comments we received in our first blog post. This second post expands on many of the received questions, but we want to ensure all underlying questions have been addressed. Presented in a question-and-answer-type format, the remaining content summarize the topics that concerned you:


Will this change place more focus on fixing issues discovered in the beta environment?

Our teams are redefining the process for how features are being deployed; some that are designed as feature options will undergo beta testing with a small group of customers before being available to all customers.


Will this change place more focus on fixing bugs?

Quicker deploys will allow our teams to be able to fix bugs more timely. Bugs are prioritized as part of each planning meeting depending on severity. We obviously do not want to release features or changes prematurely and we anticipate that this new process will also help us improve our quality in our feature deliveries.


Will some features still deploy straight to production?

All features will eventually be available in the beta environment, although their use may include some caveats.


Other services are currently planned and will be announced at a later date.


Will this change increase development of Community feature ideas?

Engineering's goal with this release change is to improve product quality and be more efficient, which may come back as a benefit to allow them to work on more ideas! The feature process itself won't change, and our product team always considers ideas against existing priorities and timelines. Stay engaged in the feature idea process so our product team is aware of the workflows and functionality you’d like to see incorporated into Canvas.


Can same-day deploy notes be posted in advance?

As noted, we’re tightening our process on how we characterize a change in Canvas so that deploy notes are not a concern. Official deploy notes will most commonly include notable fixed bugs, considering the majority of Canvas code is deployed for future functionality and infrastructure improvements. If there is any question as to whether a change will affect existing functionality, that change will be changed to a feature-type categorization to be available as part of an upcoming monthly release. And if a code change slips through the cracks, our teams always review the prior release to identify what needs to be improved to prevent unintended future situations from occurring.




If you’ll be joining us at InstructureCon, we’ll be hosting a session that will review these upcoming changes as well.


As always, thank you for your interest in upcoming Canvas changes. Let us know if you have further questions that we can address.

In 2019, Canvas teams are researching an adjustment to the Canvas release schedule focusing on two key objectives: make new features more predictable and improve the quality of Canvas code. We hope you will consider these thoughts with us and provide your feedback!


Release Background

Let’s start with the status quo—we know that three-week releases are fast. Canvas loves agile development because it helps our teams move faster and brings features more quickly—more and more software companies are moving to cloud-based continual deployments because of both the engineering and customer benefits. Visit any Instructure office and our teams may seem calm and content (and quiet!) working away on their computers, but if you could peer inside our network of Slack chat channels, you’d find the constant chatter among developers and QA and product teams reviewing changes, brainstorming code workflows, checking the status of outstanding tickets, and providing good-natured banter (my favorite part, really).


Canvas Code Quality Improvements

Our three-week releases include code deploys for predetermined features, fixed bugs, backend changes, performance updates, API modifications, platform upgrades, and other code adjustments completed by our engineering teams. All of our changes are code reviewed and tested by our Software Engineers and Software Engineers in Test to ensure it meets our (and your!) standards. These practices allow us to prepare and deliver new Canvas code in remarkably short cycles.


Releases and deploys don’t have to be synonymous terms—in fact, our teams would prefer that they weren’t. What if we could put all this code into smaller deploys so teams can focus better and fix bugs even faster? What if you had more time to prepare for feature updates? These are the questions we want to answer, and these results can be done without adversely affecting you as the customer.


Predictable Feature Changes

From the customer standpoint, we know that three-week releases include a lot of content that may not pertain to your user role. Or, you’re an admin who gets overwhelmed at the idea of training your entire institution about all the upcoming changes. We’ve been working hard to ensure our release notes give you more tools to help you be the superhero you are, and our new proposal would also give you more time to do just that—we want to ensure consistency on your side so you know exactly when a release is happening and when, without having to consult a calendar.


From Instructure’s side, we want to be more mindful about what changes impact your experience, not simply focusing on changes in the interface. We realize there are plenty of behind-the-scenes adjustments that may affect Canvas behavior, and to improve your experience with Canvas features, we want to improve how we release these changes to you.


Canvas Release Proposal

Current Release Cycle

The current release cycle includes the following 3-week structure:

  • All new code is deployed to the beta environment with the scheduled beta release (week 1)
  • Canvas release notes are published in advance of the production release (week 2)
  • All beta environment code is deployed to the production environment with the scheduled release (week 3)


To clarify terminology, a deploy means making code available in a specific environment; code may or may not be visible. A release represents a scheduled event when code is intended to be visible. Currently, deploys and releases are treated as the same thing.


Proposed Release Cycle

To be more mindful with what code we release and when, the proposed change includes a monthly feature release overarching two-week code deploys.


New features are defined as any changes that change user workflow for any Canvas-related product. Some new features may be managed by Canvas admins or instructors as a feature option in account and/or course settings. Other features may come from fixed bugs that require a workflow change or an interface change, or API/SIS integration adjustments. The Canvas product team can directly control these features for all products and manage when they should best be released. Feature releases would still follow the regular process of releasing to the beta environment, followed by the production environment.


Non-features are defined as non-customer-affecting backend changes, code for new projects, fixed bugs—basically any code that does not affect any Canvas workflows or functionality, or code that improves unintentional behaviors. Two-week deploys allow engineering teams to verify less code at one time, improve quality, and fix bugs twice as fast. Deploys still follow the regular process of deploying to the beta environment, followed by the production environment.


The proposed schedule is as follows:

  • Non-feature code is deployed to the beta environment and then to the production environment two weeks later; public-facing deploy notes (such as fixed bugs) are published the same day as the production deploy
  • New features are released to the beta environment a month before the production environment release to allow advanced planning
  • New feature release notes are published three weeks in advance of the production release
  • New features are released to the production environment on the first Saturday of every month; the Test environment is also refreshed to match production data


Proposed Implementation Timeline

Our teams are excited to consider these changes, and we hope you are, too! But rest assured, these changes will not be implemented until all aspects have been thoroughly reviewed. And because we’re aiming to minimize disruption, we’ll make the release cycle change when we feel the change is best suited for you as well. Our approximate timeline looks like this (and is subject to change):


  • November 2018: Publish Canvas proposal
  • December–February 2019: Review and explore needs for engineering process changes
  • March–May 2019: Implement engineering changes
  • June/July 2019: Implement new release cycle process


We look forward to your feedback!

Every day, we come to work with one purpose in mind: we want to help you achieve your goals and find success within the life-changing field that is education. Canvas is the LMS that makes teaching and learning easier. And every day we want to give you our very best, no matter what it takes.


Every new or updated feature in Canvas goes through a specific life cycle—whether the feature receives future enhancements or is replaced by the latest technology. Our product team’s main priority is to improve fundamental Canvas features without significantly disrupting a user’s workflow and provide our Canvas admins with peace-of-mind preparation.


To determine the best dates for these changes, we collaborate frequently with various departments throughout the company to compile as much customer information as possible. We are also continuously mindful of academic schedules and preferences in both northern and southern hemispheres. Changes are exciting, and we recognize some work may be involved! But we’re here with you every step of the way.


First, to our commitment to transparency, our new Upcoming Canvas Changes page provides a central location for communicating all our significant upcoming changes that affect all institutions. This page will always be current so you can have up-to-date information any time you need it.

  • We recommend you click the Follow button at the top of the Upcoming Canvas Changes page so you will receive all updates as they are made available.
  • Announcements will also continue to be posted in individual Canvas release notes as updates are made available.


Second, when we announce a change, our product and marketing teams ensure we provide you with release notes and other resources you need for change management. We’ll not only help you prepare for the change, but we’ll give you the tools you need to get everyone on board.


And last but not least, our Customer Success team is always available to brainstorm those challenges that may not involve a cookie-cutter solution. Our goal is nothing but your success, so reach out to your Canvas admin or Customer Success Manager to see how we can help solve your specific needs.


Please let us know if you have any specific concerns or have additional ideas about how to help you prepare for these types of changes.


Table photo created by jcomp -