nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Child Item

Changing Beta's cadence doesn't make sense to me

eruiz

I wanted to get a sense of how others are feeling about the change to the Beta refresh schedule moving from weekly to every 21 days.

I’ll be honest, this feels like a pretty short-sighted shift.

The weekly refresh is what makes Beta useful for us. It gives us a recent snapshot of production data that we can rely on for troubleshooting and quick validation. Stretching that to three weeks introduces enough data drift that it becomes harder to reproduce issues tied to recent activity, which is where we use Beta the most.

It also raises a question about the distinction between Beta and Test. If both environments are moving toward longer cycles and more persistence, they start to overlap in purpose.

More than anything, I’m not sure what problem this is solving. The weekly refresh hasn’t been broken in my experience.

I’d be interested to hear how others are using Beta:

Is it primarily for troubleshooting, UAT, or something else?
Does a 21-day refresh help your workflow, or make it harder?
How are you thinking about Beta vs Test after this change?

4/17/26 Update from Instructure regarding our feedback about Beta istance:

https://community.instructure.com/en/discussion/665853/you-spoke-we-listened-an-update-on-canvas-beta

Find more posts tagged with

Accepted answers

All comments

saustin

There are so many levels of problems with this, the first, being, "who" are they talking about when they say, they based this change based on feedback from the community. Here is the quote from the email:

Why are we making this change? Based on feedback from our community….

What community are they talking about? Where and when was this raised, and to whom? When I found out about this, I went through every community post and blog I could think of, including one dated that day, and saw absolutely no mention of this. Whatever community was consulted, we, the users were not. We are the community that works problems where the rubber meets the road, and who are the face of Instructure to our faculty, staff, and students. This certainly wasn't publicized before its release via email, and to say in that email that it was based on feedback from the community feels disingenuous to me.

When we work problems, only some are actually technical in nature. The rest are user error. We rely heavily on Beta to track that user error. With Beta, we have a timely window into "before" and "after" configurations — configurations of something they have set up, something they have deleted, something they have turned on or off. I cannot emphasize enough that, in academia, the cadence is a weekly one. Faculty usually set up their work flows on a weekly basis, because of the modular nature of education. Significantly, because they tend to prepare the week prior, if we move to a schedule in which Beta is refreshed every three weeks, then we lose the snapshot of what they have done the week before in preparation.

As far as testing in Beta, if we were to go to a three-week refresh with Beta, we would be putting way too many eggs in one basket. If anything is not working in Beta, we have more to deal with, not less, because there will be more variables we will have to address.

What's the point of TEST and its monthly refresh if we have a three-week refresh with Beta? Addressing the points made in the email;

Greater Persistence: Test configurations and data will now remain active for 21 days, allowing for more thorough, long-term testing. Response: Instead of extending Beta, give us test configurations in TEST instead, remaining active for 30 days instead of 21 days. Leave Beta as a weekly refresh.
Environment Stability: Less frequent refreshes mean a more consistent environment for your developers and administrators to work within. Response: TEST does this already.
Better Planning: A predictable 21-day cadence allows your team to better align testing with your institution's internal sprint or release schedules. The Beta environment will be refreshed every three weeks on a Saturday. The first few refresh dates are: May 2nd, May 23rd, June 13th, July 4th, July 25th, and August 15th, 2026 Response: It is far easier for me to remember that Beta refreshes on a Saturday rather than having to remember dates. Planning is harder, not easier.

In short, if the authors of the email are seeking the advantages they outline for an extended refresh, then the answer is to make TEST be capable of anything that Beta can do — not to change the weekly cadence of a Beta refresh.

Thank you for listening.

Sharon Austin

University of Tampa

ellietf

I’d like to add my voice to those requesting that no change be made to the Beta environment refresh cadence at this time.

As a Canvas Admin at a University, the short refresh cycle is useful to me in the following ways which have already been mentioned in the blog post comments:

Retrieving content that was recently accidentally changed by an instructor/TA for features outside of Pages where there is no version history (Syllabus, Assignments, etc)
- Ex: accidental course imports into live courses
Various troubleshooting where version comparison is needed
Complex feature testing wherewe might unintentionally disable access to the environment or mess up course content badly and we don’t want to wait a long time for the environment to refresh

Without other means to accomplish these tasks, we would experience this change to the refresh cadence as a loss of functionality. Please consider pausing this change until further discussions can take place.

DL1919___

I also don’t really see the benefit of having one environment refreshed every three weeks and the other every four. Would it not be more practical to align them on a two‑week cycle instead? We rely heavily on Beta for support because it’s a copy of last week’s data it allows us to act as the student and reproduce issues we know occurred recently.

It would be really helpful if institutions had some flexibility in choosing how often environments are refreshed, based on our operational needs.

James-Kocher

Throwing my 2 cents in….

Without a legitimate way to restore previous versions of courses, having a weekly beta fresh has been critical in the past in situations where a course is inadvertently ruined, and the only recourse was to export the course from beta and bring into prod. As others have mentioned, beta has been valuable in troubleshooting issues, especially if we need to check things like due date or status changes, as we have no access to logs what would inform us of these things as well.

JenniferBunnell

As others have noted, it is very important that we maintain the weekly refresh schedule for the Beta environment. This cadence plays a critical role in our troubleshooting efforts. There have been numerous occasions where I’ve needed to export courses or retrieve grading information due to accidental deletions or course revisions, and the regular refresh has been invaluable in those situations.

We also strongly value keeping the Test environment on its current refresh cycle. We rely on this instance for extended testing within an environment that closely mirrors our production setup, which requires longer testing windows. An additional benefit of Test is that it does not have all the upcoming Feature Options enabled. This allows us to create tutorials for new applications that will soon be released to Production without disabling extra features, making our preparation process much more efficient.

I hope these considerations are taken into account and that the current refresh schedules remain unchanged, as they are essential to our workflows.

rajendra_singh

Chiming in to reiterate and support many of the points already raised by others and to echo that without a viable replacement for the benefits that beta's weekly refresh currently offers us, this change will have a negative impact for us here at CU Boulder.

We are also part of the group that did not receive any communications regarding this change and were left to rely on information being shared by peer institutions. I want to give the benefit of the doubt and assume that this was done in error, but this, coupled with the rushed timeline, not being prompted for feedback, and the change seemingly not being documented elsewhere (blogs, release notes, etc.), leaves a lot to be desired.

Robert

Everyone is making so many good points that I agree with. @SarahBlanton asked specifically if the refresh is separate from the code deploy to beta—an important distinction.

Reviewing the schedule, the code deploys are still separate from the data refresh. Beta releases happen every third Monday, while deploys/hotfixes happen every second and fourth Thursday. This is crucial for identifying break/fix issues in Beta before they are sent to production, as was the case with branding the responsive menu a few months ago, or the Native Login testing/review. It is vital that this code frequency continues ahead of the production release cycle; Beta is how many institutions flag issues and report bugs before they are pushed to production, or ensuring custom dev is ready for future changes. According to the calendar, this appears to remain the same.

The data refresh, however, is the copy of production data. Data is not copied on the Monday and Thursday deploys—just new code. With that clarification, there are many use cases for having the data refresh weekly. Several services we have developed require weekly refreshes to "reset" and try again, literally doing things so we can start over on Monday. A 21-day cycle means we either wait three weeks to re-test or must develop complex processes to manually reset data scenarios. Resetting conditions is not always possible, and when it is, it simply shifts the workload to the customer.

I'm with those who disagree with this change. A better solution would be to put this in the hands of the customer (perhaps a CSM-level setting). Setting a 3-week default would meet Instructure’s rationale (maybe cost) while meeting the needs/expectations of customers who rely on the current cadence.

james_whalley

@InstContentTeam @InstDocTeam We could really use some sort of response from Instructure here, even if it is some version of what our CSM has sent us:

…Thank you for reaching out and for your candidness regarding the upcoming change to the Beta refresh cycle. I completely understand your concerns and recognize how disruptive this feels for you and your team at Cornell.
I want to assure you that we are taking your concerns seriously. I am actively sharing this feedback internally with our R&D and leadership teams, and we are doing our due diligence to thoroughly review the impact of this decision. We ask for your patience as we continue to evaluate this feedback and determine next steps…

dbrace

I completely agree when it comes to remembering that (currently) beta is refreshed every Saturday and that test is refreshed every third Saturday (with production).

If this change happens, remembering a three week (21 day) cycle is going to be difficult and require looking at Instructure's calendar more often.

-Doug

hockin

This is not a welcome change.

I understand that there must be cost savings, and new institutions are not given a test instance; however, I firmly advocate for the continued weekly refresh of a non-production tier even if our Test instance were to be decommissioned.

At our institution, we have a central LMS support desk, as well as a distributed support model that allows individual schools and campuses to support the unique practices and culture of their units. Our central support desk and our distributed support all log into our beta instance to help instructors, especially since back-ups are unavailable. If a course instructor has multiple tabs open or if they accidentally import content into a site more than twice, Beta has been a lifesaver.

I would like Instructure Support to count the times in a week that their agents log into Beta to recover content.

Here are my answers to the questions:

Is it primarily for troubleshooting, UAT, or something else?
- Both! Support staff uses Beta to pull recent copies of content that was overwritten in production. Our developers use Beta as the initial tier to deploy updates and changes. Since it refreshes weekly, we do not have qualms about making significant changes that are erased weekly.
Does a 21-day refresh help your workflow, or make it harder?
- This will greatly hamper our support staff and increase end-user frustration.
How are you thinking about Beta vs Test after this change?
- I am hoping Instructure will post another "We heard your feedback" blog post and rescind the decision. One instructional designer said that Beta makes her a hero to the instructors she supports. Let us be the heroes.

How do I feel about this upcoming change? I want to stay in the denial phase; I will gladly bargain our Test instance for retaining weekly refreshes.

Do weekly refreshes impact our development process? No. We have 1 dev who spends an hour resetting Beta weekly. I also use Postman's automated API runs to reset certain features weekly. This is the cost of doing business, but the availability of a weekly backup is far more valuable than 1 developer's time.

CMcC1

Chiming in to echo the sentiments shared by others here. UC Berkeley also did not receive consistent comms about this change. Our support teams rely on the Beta environment for troubleshooting content and gradebook issues directly with instructors, as well as short-term testing, investigation, and feature experimentation (including to give feedback to Instructure on feature development). We use Test as an actual Test site, so keeping distinct environments on different refresh cadences is preferred. I would be happy to talk more with Instructure about reconsidering this decision.

JV72405063

I have some concerns about moving the Canvas beta refresh cadence to a 21‑day cycle. Earlier visibility into changes during the beta phase has been valuable, as it allows issues to be identified and addressed sooner rather than later.

The current weekly cadence has worked well for me, particularly when reviewing changes that impact custom in‑house applications. It supports a steady feedback loop and helps align build and test cycles more effectively. Extending the refresh window to 21 days would slow that feedback loop, increase the risk of late‑stage issues, and potentially result in design changes or project delays.

M_Rhinehart

I completely agree that changing the refresh schedule does not make sense and will not be helpful at our institution. I often troubleshoot 8-week courses and now, I would be almost to mid-term in those courses before my troubleshooting would refresh.

hockin

What is truly concerning is that this change will take place in 2 weeks; however, several of our root account admins who have the permission Account-level settings - manage did not receive this email. Officially, I have never been notified of this change. My email address is associated with at least 3 root admin accounts with the permission "Account-level settings - manage". I should have received 3 emails.

Click 👍️ if you received a notification.

Click ❤️ if you have not.

dbrace

Something interesting to note about receiving the notification is that my Canvas Free For Teachers user account received a notification, as well as my institutional Canvas admin user account (which is a separate Canvas user account that is not enrolled into anything).

-Doug

thackead

It feels like this change is coming from a very specific interpretation of feedback and then being applied as if that represents how Beta is primarily used.

I understand the concern that weekly refreshes can interrupt longer testing cycles. That’s valid. But reading through this thread, and based on how we use Beta, that’s only one slice of the picture.

Beta isn’t just a UAT or development environment. It supports a lot of short-cycle, operational work. We rely on it for troubleshooting, validating issues against recent production data, and in some cases recovering content. The weekly refresh is what makes those workflows possible.

Moving to a 3-week cadence makes those use cases harder, not easier. It introduces more data drift, reduces the reliability of Beta as a recent snapshot, and makes it less useful for day-to-day support.

It also creates confusion around the role of Beta vs Test. Right now, the distinction is clear because of cadence and purpose. If Beta moves to a 21-day cycle, it starts to overlap with Test, especially for institutions that already use Test for longer-term work or, in some cases, don’t have Test at all.

What stands out most in this discussion is how consistent the feedback is. The issue isn’t that weekly refreshes are universally a problem, it’s that they were solving a different, equally important set of problems that this change now disrupts.

It feels like the feedback of “weekly resets interrupt long-term testing” was taken and treated as the primary driver, without fully considering how widely Beta is used for short-term validation, troubleshooting, and recovery.

If the goal is to support longer testing cycles, that makes sense. But removing the weekly cadence from Beta reduces flexibility for everyone else. It solves one problem by creating several others.

Do I really dislike losing testing work I’ve done in Beta after one week? Yes.
Do I want to lose Beta as a reliable, recent snapshot for troubleshooting and recovery? No.
This change feels like trading a manageable inconvenience for a much bigger loss in functionality.

ruvi

Jumping in to add my dissatisfaction with this change.

Yes, I acknowledge that acting as a backup was never Instructure's intended reason for creating the BETA copy and the 7 day refresh cycle, but lack of an alternative has resulted in BETA becoming our go-to solution.

I cannot count the number of times the BETA copy has saved users at Arizona State University when a instructor or ID has accidentally deleted something or reset scores that cannot be undone through Canvas (or super helpful the "undocumented feature" of …/undelete )

Without consistent versioning/rollback capabilities, the loss of the (…up to 7 day old) copy in BETA will significantly impact our ability to restore content inadvertently deleted content.

cwittrock

Will there be a way to tell where the update is in the 21-day cycle? Previously, I could say Beta every Saturday, and Test on the middle Saturday of the month.

But, on a 21-day cycle, it is not easily repeatable. You gave the first few dates Awesome!

How do I determine the day of the cycle stage next fall or even a year from now….. example: if I need something next October 14th, is there a way for me to determine/know where we are in the 21-day cycle????? 🤔 Like others, I use the Beta to recover data or compare data.

dbrace

I see that https://community.instructure.com/en/kb/articles/664262-what-are-the-release-schedules-for-beta-production-and-test-environments was updated recently.

-Doug

dbrace

The general guide is https://community.instructure.com/en/kb/articles/664262-what-are-the-release-schedules-for-beta-production-and-test-environments and it contains links in the "Canvas Release Calendar Summary" section for the various ways to see the schedule, for example https://calendar.google.com/calendar/embed?src=instructure.com_u3bufsip887n3qb6fht3rgnbts@group.calendar.google.com.

-Doug

saustin

I am pretty sure I checked that exact page on the day that email came out, and did not see the schedule as depicted now. Thank you for calling that to our attention. To me, it speaks to something that has already been decided….and to say that such a change is already there in writing troubles me. It feels like they are moving full steam ahead, even now.

dbrace

A Google Search (https://www.google.com/search?q=canvas+beta+refresh+schedule&oq=canvas+beta+refresh+schedule) picked up on it too.

-Doug

saustin

Thank you to @dbrace for calling the schedule change yesterday, on April 14, out to our attention https://community.instructure.com/en/kb/articles/664262-what-are-the-release-schedules-for-beta-production-and-test-environments

ByInstContentTeamLast Updated:Apr 14, 2026

Casey Sato

Hi Edual + all everyone who has added their comment to this thread.

I'm Casey Sato, Sr. Director of Customer Success at Instructure. Thank you — genuinely — for taking the time to share your thoughts here. This kind of direct, honest feedback is exactly what helps us make better decisions, and we don't take it lightly.

I want you to know that this conversation has been heard. We are actively reviewing your feedback alongside teams across Instructure as we evaluate our path forward. We're taking a pause and being thoughtful and deliberate with your feedback, and we'll share more as soon as we're able to.

We're grateful to have a community that cares this deeply. That matters to us.

More to come via community and direct email communication — thank you for your patience and continued partnership.

djdeter

@Casey Sato thank you for your response.

As an admin whose university is just beginning a long transition process into Canvas, the idea of Beta moving away from its every Saturday refresh is, quite frankly, horrifying. We am already using Beta heavily to test items in Canvas as we transition, and it has been great to know that if in our learning process we mess up badly on Beta it will be wiped away over the weekend and we'll have a fresh patch to start on which matches our production instance.

Additionally, we are already using Beta as a resource to recover courses and pages that an instructor may have mangled accidentally (as they are just learning Canvas as well) that is only a week old or less. I will note that this is already a step backwards for our faculty as in our old LMS we have the ability to restore from at worst the previous day, if not even earlier in the day. At this time it appears that Beta is the closest we can get to that in Canvas. Unless Canvas adds the ability for us to restore courses to a previous state then I cannot express strongly enough how much we desire to keep the weekly Beta refresh intact.

LoraHaasl1

Agreed. We have been on Canvas for a almost a year now and have a few instances where faculty were able to delete student submissions. We were able to find them on Beta since it is information that at the most is 7 days old. If it had been 3 weeks old I am not sure how this would be restored since it appears Canvas does not have the regular nightly backups like our old LMS had. We too only would lose the last 24 hours if we requested a restore file from the old LMS and we could unzip it in a sandbox course and retrieve the submissions that way. We are very concerned about this notice to change Beta.

abbyrosensweig

Just adding our voice to the chorus of people asking for a reevaluation of this change.

We often use Beta, with its week-old data, to recover information that was changed or deleted from prod. Having that data be up to three weeks old, especially given our 10-week terms in most programs, limits our ability to troubleshoot and assist instructors.

Having a 3-week refresh cycle for beta and a 4-week refresh cycle for test doesn't make much sense to us. With the deploy schedule still on a 2-week cycle, there isn't alignment between the beta refresh cycle and the deploy notes schedule.

In lieu of genuine version histories and recover functions (which is what we really want!), Beta is the best tool we have right now to help users when things go sideways and data seems to be lost. Please don't take away the utility of that tool.

Todd_E

To confirm. by taking a pause, that means this change won't be happening on the early may deeadline?

herbert_serrano

I wish I had more hands so I can give this decision 4 thumbs down!

A 21-day refresh would make BETA nearly useless because the data would be too old after 1 week. My team and I go into the beta environment at least 1 time a week and as we approach finals we are going there more and more. I honestly do not know what the difference between 3 weeks for beta and 4 weeks for test would be. Please do not move forward with this decision.

⛔️⛔️⛔️⛔️⛔️⛔️⛔️⛔️

rfoshee

This choice has a negative impact on our support capabilities. We've shared our concerns with our CSM but wanted to add them to this conversation as well.

Administrators and instructors need systems for good version control, including reversing destructive changes to course content. Until there’s a better solution, we advise keeping Beta on a one-week refresh frequency, as our teams rely on this for version control.

We believe that the following should be addressed before changing Beta sync frequency:

Offer an alternative system for restoring historic versions of content
Improve admin logs to capture dates and times of course content changes
Make “undelete” user-friendly, with the ability to sort deleted content, view all content items, and search for individual content pieces

Losing the weekly updated data in beta will reduce our ability to troubleshoot and resolve issues in-house, and will result in an increase of escalations to Instructure support for this information

melodyc_lam

I never got the email either (on either my main or my 'backup' account) and I manage 2 instances of Canvas and have field admin privileges on both. I would say at least the field admins should be getting the email at least once. According to my CSM I should've gotten the email and they're checking on it right now but that is really strange (and they're aware I'm a heavy user of the beta instance too)

ldew

We at ISU have the same feelings as others:

Key Concerns

Delayed troubleshooting due to outdated data, especially during critical grading periods
Limited course recovery for recently deleted or overwritten content
Reduced testing accuracy across courses, assessments, and gradebook functionality
Gaps in LTI and integration validation with less current data
Increased support workload and longer resolution times
Potential data inconsistencies across systems and middleware

The weekly refresh is essential to timely, effective support. Moving to a three-week cycle would significantly reduce our ability to serve instructors and students at the university.

hechla

Thanks for explaining this @Robert. Just to clarify, the data refresh includes any settings changes, lti changes, etc. and not just user data added/deleted from the system?

Robert

From what I understand it is a copy of the production data, I am not aware of any exclusions that would limit settings or LTI configurations being copied. I can't speak for whether every LTI has beta functionality. One other thing is that some (maybe all) feature flags in Beta persist. They are not disabled if they are not enabled in production. For instance, I've had New Canvas Login UI enabled since it was available, but the deploys or weekly refreshes have not disabled it, while the code has changed, as it is not currently configurable in Auth Settings.

audrey_p

Having a 21 day refresh would make it harder to rely on Beta’s accuracy. Everyone on the team would have to always put things back the way it was in order for us to trust Beta. That is unrealistic.

I use Beta for:

figuring out faculty requests. It usually requires recent data*/submissions. It helps our velocity that testing will reset after one week.
testing the fixes Instructure deploys
testing brand new features

I use Test for:

long term testing including adopting older features
testing with no unknown beta features enabled

Both environments are needed:

when more than one team is testing at the same time. They’ll choose one environment and we’ll use the other.
Historical reference - we need to compare what happened in Beta to Test to Prod very often to figure out what happened.
correcting testing that did not work out in the other test environment that requires actual course data/submissions

*Some examples of recent data that would affect large parts of the course that would be hard to put back the way it was if Beta was 21 days:

re-working a course’s grading structure
set up and especially submissions from team projects/peer reviews
changing roles en masse from SIS imports
blueprinting

LindseySharp

I strongly advocate for this change to be rolled back. This change breaks our workflow for testing and development. Please seriously reconsider, particularly given the communication issues around announcing this. We would need a far longer runway to locally source a solution to the problem this creates.

ErikaRydbergHall

I have heard from my colleagues at USNH similarly as presented above. It sounded to me like this week, Instructure noted that Beta would also be our only testing environment going forward? Do we have confirmation on this front or are things on hold? I think most of our use cases have been presented by previous users.

At its core a weekly refresh and a three week refresh have value to us for different needs from our Application Administrator's perspectives and from our Educational Technologists and Instructional Design perspectives - there are valid purposes for the environments to be different. Thanks

AmandaPage1

I will chime in and reiterate similar sentiments to what others are expressing in this thread. Moving the beta refresh cadence from weekly to every three weeks has several negative impacts on our institutions and reduces the effectiveness of the beta environment overall. A few negative impacts we have identified for us include:

Troubleshooting and debugging: When issues arise in production, having beta data that is no more than a week old allows us to replicate and investigate problems more efficiently. Under the new schedule, we may need to wait up to three weeks for relevant data to refresh into beta, significantly slowing down our ability to solve issues.
Data quality in beta: With a three week refresh cycle, test data accumulates much longer, increasing the likelihood that outdated data will impact testing scenarios.
Responsiveness to Instructure updates: Less frequent refreshes mean new or upcoming changes will only appear in beta every three weeks, which will negatively impact our ability to prepare for changes before release.
Release timing concerns: The new refresh cadence is also not aligned with the release schedule, potentially resulting in a beta environment that refreshes shortly before a release window and then remains unchanged for an extended period afterward.
SIS Import Issues: It is not uncommon for us to run into delays with SIS Imports on nonprod and the response is usually, wait until refresh for resolution. Putting beta in this delayed state drastically reduces our development/testing turn around time. This puts our institutions at risk if we run into issues with our SIS process.

Overall, the reduced refresh frequency materially impacts our ability to test, troubleshoot, and prepare effectively, and diminishes the value of beta as a pre‑release environment.

rsc

I also heavily rely on beta's weekly refresh for troubleshooting and recovering data or deleted submissions. Instructure should instead focus on enhancing this feature such as providing daily snapshots of current courses and the ability to restore previous versions of a course as it's possible in other LMSs.

julian_ebeli

I entirely agree with what you have written here. If there is some utility in a 3 weekly update to someone, why don't they just use test?

Beta's weekly refresh is what makes it useful. I use it every day to find recent changes to prod which I can roll back.

Their proposal makes no sense to me at all.

julian_ebeli

In my organisation, the IT systems guys use the test environment to test systems integration. Its stability is useful in this situation

As a Canvas admin, I use beta everyday for troubleshooting problems in prod. Its instability is useful to me.

Please don't change this.

Andy_Kalin

Is the main reason for this change to offer a longer testing window for customers that only have a beta and don't have a test instance? If so, it seems worth considering adding test environments for those customers who don't have one but want one, rather than impacting the plethora of customers who already have beta and test environments and utilize their current refresh periods as essential parts of their service offerings. The feedback in this thread has made clear that many customers are reliant upon the current service state for a variety of reasons. Why force those customers to change a value stream that works, rather than value-add for the customers who aren't currently offered both? Just my two cents, good luck to all.

Casey Sato

Sharing this Product Blog Post on my reply thread. Thank you for the feedback that everyone has provided!
https://community.instructure.com/en/discussion/665853/you-spoke-we-listened-an-update-on-canvas-beta

We’re reversing our decision with the Canvas Beta Environment.
The Canvas Beta environment will remain on its current weekly refresh cadence, with no changes planned.

What this means for you: Nothing about the Beta experience is changing.

Weekly refresh cadence remains in place
Continued early access to upcoming Canvas updates
The same reliable environment you use today to prepare for production changes

Casey Sato

Thank you both for your feedback and helping us understand your perspective. Here is a link to the product blog update that announces the reversal of that decision.

https://community.instructure.com/en/discussion/665853/you-spoke-we-listened-an-update-on-canvas-beta

Unanswered Questions

Bulk aligning outcomes to New Quiz Questions at the Quiz level
Does anyone have suggestions for bulk aligning questions at the quiz level, not the item bank level? I don't know much about API keys, but would one of these work for a bulk alignment? We have a school that is preparing for accreditation next year and they must get their quiz questions aligned to outcomes. We know they…
Why aren't question banks and quizzes showing up in course import tool?
The most recent quizzes and question banks (including renames) are not showing up as options in the Course Import Tool. As I was creating a new quiz in one course (Classic), I went to add the questions from the Question Bank, but what I needed wasn't there. I went back to the other course to make sure everything was…
Gradebook Color Status for Incomplete 2-Part Discussions (Discussion Checking-point)
Hi all, Quick question about the Gradebook color status for a 2-part checkpoint discussion. If a student completes the first due date (initial post) but does not complete the required replies by the second due date, is there any way for Canvas to automatically show a color (e.g., missing/late) instead of staying as…
Enhancing Collaborative Evaluation Workflows Using Canvas Portfolios
Canvas Portfolios provide a powerful platform for students to document their learning journey, reflect on their progress, and showcase competencies. However, in programs where multiple educators are involved in assessment—such as team teaching, moderation, or competency-based evaluation—there are important questions about…
IB MYP reporting for assignments and Grade book
Hi There, We are in the process of transitioning to Canvas this year and were wanting to connect with any other MYP schools to see how you setup Assignment and grading under your modules. Or you could guide us to any resources you may have.