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; } } }

Resetting Release Conditions - clarity in documentation

Steve.B.446

The guidance for release conditions at About Release Conditions - Brightspace states:

Note:

Once a learner meets a release condition, the condition is cleared for that learner and cannot be reset. For example, if you attach a release condition to a discussion topic requiring learners to achieve more than 60% on a quiz before they can access that topic, and one of your participants receives 72% on the quiz but you adjust their grade to 55%, they will be able to access the topic because they did meet the requirement at some point.

However this isn't true. For example, if you release something based on "Has not received a grade item", the item disappears when a grade is assigned. However if you release something based on the grade score, it does remain released when the score changes to something outside of the rule parameters.

Equally, conditions based on group membership seem to reset when the user is removed from the group.

Is there any more accurate documentation available for which rule types do reset? I need to find a workaround for something that we used to do with groups that has been broken by the recent change restricting group size to 3000 members.

(I get the impression from recent PIE contributions that there is a lot of appetite from the community for release conditions to be more flexible, but not much enthusiasm from D2L to prioritise this at present, hopefully somebody is taking note and can change that.)

Find more posts tagged with

Groups

Release Conditions

Accepted answers

Krizzy.S.9720

Hello @Steve.B.446,

Thank you for raising this! You're right that our current documentation does not accurately reflect how certain release conditions behave, particularly “not” conditions and those tied to group or section membership.

Clarification on “Not” Release Conditions
For conditions like “Has not received a grade”, the logic works in reverse compared to typical release conditions:

Initially, the condition is met (i.e., the user has not received a grade), so the associated activity is visible.
Once the user receives a grade, the condition becomes unmet, and the activity is unreleased.
Importantly, if the grade is later removed, the condition does not become met again — it remains unmet.

This is because “not” conditions are not re-evaluated once they transition to unmet.
This behavior is different from standard release conditions, which typically remain met once satisfied.

Clarification on Group and Section Membership
Conditions based on group or section membership behave more dynamically:

If a user is enrolled in a group or section, the condition is met.
If the user is removed, the condition is reset — meaning it can be met again if the user is re-enrolled.

This is similar to how course enrollments work and reflects the system’s design to treat group/section membership as a re-evaluable state, unlike “not” conditions.

Next Steps
We acknowledge that our documentation needs to be updated to reflect:

The non-reversible nature of “not” conditions.
The resettable behavior of group and section membership conditions.

We’re working on updating the relevant articles on our Community page to provide clearer guidance and examples. In the meantime, if you need help identifying workarounds for workflows impacted by these behaviors (e.g., due to the 3000-member group limit), we’d be happy to assist.

All comments

Piero.d.211

Hello, Steve, how are you? Thank you for your participation in the Brightspace Community today.

I have reached out to our internal teams to confirm if we do have more documentation about these scenarios were a Release Condition can be reset.

While I wait for an answer, would it be possible for you to share more details about the workflow with Groups that you can no longer follow now? Depending on what you would like to do, there might be work-around solutions that can be applied.

Please, let me know, okay?

Thank you kindly,

Piero de Sá
Bilingual Product Support Analyst

Steve.B.446

Hi Piero

Thanks for that. We have an Academic Integrity training course which all students are required to complete. Some students are required to retake an advanced version after being found guilty of academic misconduct at either Stage 1 or Stage 2 of our procedure.

To avoid confusion, we only want students to see a single instance of the content, depending on whether they are doing the compulsory training or one associated with a Stage 1 or 2 penalty. We therefore have a group category with three groups, Compulsory, Stage 1 and Stage 2, and our automation process uses the API to enrol students in Compulsory by default, and then they are manually moved as required. These groups are used with release conditions to release the appropriate content, and if a student is removed from a group they no longer see the content released by that rule. That is contrary to the documentation but has worked for at least 7 years!

The recent change caps the Compulsory group at 3000, which is insufficient for our needs.

The workaround I have implemented is using a grade item as the flag for which stage the student is at, with a "no grade received" rule for Compulsory and the explicit points received for Stage 1 and 2. Entering a score of 1 in that grade item will hide the Compulsory content and release the Stage 1 content. However if a student has a further penalty, changing Stage 1 to Stage 2 means that they can see both S1 and S2 content.

So it kind of works, although it has also created a lot of work in redeveloping Analytics Builder reports to take the student's stage from either source to allow for historical comparisons.

I think I have a longer term solution using three separate courses (which might be more sustainable as we seem to be relying on undocumented bugs), but the changes in SITS to implement that couldn't be implemented given the timescales and how busy our course admin team are at the start of term.

Thanks

Steve