How are you managing permission lock-downs on Master ("MSTR") course offerings without breaking auto

Jen.D.9760

We are currently evaluating options to lock down our Master Course Offerings to prevent unauthorized or accidental edits by Course Builders, and I’d love to learn how other institutions handle this.

Our Setup & Constraints:
Hierarchy: Organization > Department > Course Template > Course Offering
Master Location: Housed directly at the Course Offering level (identifiable by MSTR in the Course Name and Code).
Cascading Roles: Course Builders have a cascading role assigned at higher org units.
Auto-Course Copy: We cannot move Master courses out of their existing Departments or hierarchy structure, as doing so breaks our automated course copy pipelines.

Goal: We need an easy, repeatable way to "toggle" edit access on and off for Course Builders on these MSTR offerings (e.g., locking during active terms, unlocking during review/maintenance cycles) without restructuring our org units.

What we are considering:
Using Bulk Course Enrolment (BCE) to swap Course Builders between standard and "Read-Only" custom roles on MSTR offerings.
Automating role shifts via Intelligent Agents or API scripts.
Leveraging course active/inactive dates or section-level role overrides.

Questions for the Community:
How does your institution restrict edits on Master courses while keeping automated copy processes intact?
If you use a custom "Read-Only Course Builder" role, which specific permissions did you find critical to strip out at the Course Offering level?
Has anyone implemented an API or Intelligent Agent workflow for this that worked particularly well?

Thanks in advance for sharing your strategies and lessons learned!

Francisco.V.8251

Hi Jen,

Thank you for sharing the details of your current setup and the options you are considering.

In general, using a custom read-only role at the Course Offering level could be an option worth exploring. Brightspace roles determine what a user can see and do within an org unit, and users can have different roles across different org units. Cascading roles can also provide access to Course Offerings based on an enrollment higher in the org structure.

For a read-only type of role, I would recommend reviewing permissions related to areas such as Content, Manage Files, course activities, enrollment management, and course administration to ensure the role retains the required visibility while removing the ability to make changes.

Intelligent Agents can also perform enrollment actions, including changing a user's current role, provided the appropriate permissions are configured. This could potentially be useful depending on how you would like to manage the lock/unlock workflow.

That said, because your Course Builders are using a cascading role and your MSTR offerings are also tied to an automated course copy process, I would recommend submitting a Support case before implementing a solution. This would allow us to review the actual role configuration, hierarchy, and one of the affected MSTR Course Offerings in your environment and provide guidance based on your specific setup.

This would also help make sure any changes made to restrict Course Builder access do not have an unintended impact on your existing course copy process.

I hope this provides a helpful starting point.