Administering Concourse

Administering Concourse

Administering Concourse as a whole is a huge step of any implementation process. For example, what level of access should a Dean have? Who will be able to configure integrations? Load courses in bulk?

This article describes the two highest tiers of Concourse administration, system and domain permissions. These are the highest level of permissions in Concourse and are leveraged on a user by user basis. Typically, those who have either system or domain permissions have more responsibility within the Concourse platform than the average faculty member would have access to: reports, multiple syllabi in a given set of disciplines, etc.

System and Domain permissions are also independent so you might have "super users" who need a combination of permissions so we recommend reading this entire article to see if 

 

System-level Administration

The highest level of Concourse administration is at the system level. Individuals here will be responsible for the setup of domains (below), integration with other systems, permanent removal of courses, and assignment of lower-level administrators, just to name a few. As you can imagine these are folks who should be the most expert and trusted regarding all the Concourse functions and be limited to a very small group of people. In most cases we find that a few individuals from IT together with Academic Affairs (and possibly eLearning if they are separate) take on these responsibilities.

System-Level Permission Checkboxes

Below is an exhaustive list of all the functions administered at the system-level. There are three system-level permissions options:
  • Administer System: Allows a user to handle system-wide functions, including
    • The assignment of additional system administrators (i.e. the three main rights bulleted here)

    • The processing of feed files for bulk user, course, registration, and content creation

    • The setting of course and item-level permissions en masse

    • The permanent purging of courses and users

    • The organization and labeling of domains

    • The configuration of LTI-based integrations

  • Set Domain Permissions: Allows a user to set domain-level permissions for other users. (This does NOT give a user domain permissions)

  • Create Courses: Allows a user to manually create new or cloned courses.

When you are ready these three system permissions can be assigned to users individually through the Admin > Users area. 


Domain-level Administration

Domains refer to the second tier of Concourse administration, which is typically (but not necessarily) mapped to the organizational structure of your institution, such as campuses, schools, and departments. What is important to remember about domains is that they should model how you anticipate distributing the administration of Concourse in terms of managing templates, providing auditing capabilities, granting reporting rights, and general support access.

How is your institution organized now? What administrators will need to access Concourse, and what will they need to be able to do? Do you have a process for auditing course syllabi and who’s involved? Template maintenance? These are important questions and the answers will affect your domain setup.

The Roles

There are four domain roles that you can leverage to assign permissions to users that need more access than what instructors might but less than system administrators:
  1. Administer: Edit syllabus content and files, Update audit status* and trail, Manage registrations, Modify course settings, Set group permissions
  2. Edit: Edit syllabus content and files, Update audit status* and trail
  3. Audit: View syllabus content and files, Update audit status and trail, Receive audit notifications
  4. Report: View syllabus content and files

Domain Scope

In addition to provisioning one of the domain roles above, one concept that is central to domain administration is establishing scope over what “range” of courses will the administrator be able to perform their duties. These are formed by mixing and matching triplets (campus + school + department) to create an appropriate set of domain permissions for an individual. Here are four examples of how access may be granted to individuals with various responsibilities in your institution:

  • Provost: Will be able to operate across every course (i.e. all campuses, schools, and departments).

  • Dean: Will be able to operate within their school regardless of campus location.

  • Chair: Will be able to operate within only their department.

  • Site Director: Will be able to operate across schools and departments at their location.

*Note:  Although “Campus,” “School,” and “Department” are the default labels used in Concourse, the Syllabus Geeks can relabel these to fit your institution. Some other combinations we’ve seen include:

  • Campus-Division>Department

  • Campus-School>Program

  • Campus-Division>Cluster

  • Level-Discipline>Program

Again, what is key is how you plan on distributing the responsibilities of Concourse management.


What may be a more important decision surrounding domain permission is just how distributed you expect said permissions to be. In smaller implementations it’s likely that there will be a core few people that will administer and audit all courses. In fact they will likely be system-level administrators as well.

As the complexity increases and responsibility gets more distributed, you may find that you add a few designated auditors from each school, and later each department, not to mention those administering templates. At this point you can imagine that you are managing domain permissions for say less than 100 individuals.

For the most dispersed situations, say where there are also select faculty members who are simultaneously content experts managing a small subset of a massive template collection (i.e. >100 administrators), it is likely that domain-level permissions will need to be combined with course-level permissions to make the situation manageable. If this sounds like you, get in touch.

To help you get thinking about how you'd leverage the different domain sets and role, here is a list of common positions/departments that one might need domain permissions with varying levels of responsibility:

  • Academic Affairs: To maintain template content and settings; occasionally audit courses and generate reports

  • Deans: Audit all template syllabi, Report on instructional syllabi within school

  • Chairs: Audit all instructional syllabi

  • Site Directors: Report on instructional syllabi at their campus

  • Institutional Effectiveness: Generate outcome reports

  • Faculty Developers: Support instructor training and help resolve issues


Considerations While Setting Domain Permissions 

As you go about determining the segmentation of responsibilities for your Concourse administrators, it is helpful to understand the two primary constraints about how you may elect to organize your domains. The first is the relationship between campuses, schools, and departments, as shown below.

Within Concourse two important relationships exist:

  1. Campuses are related to Schools, and

  2. Schools are comprised of Departments.

This will have a material impact on how you label and organize your domains, namely that:

  • every department must belong to one and only one school,

  • a school can be associated with multiple campuses, and

  • each course must relate to one and only one department, school, and campus.

The second consideration is that each domain listing must consist of a name (e.g. Accounting) and unique external ID (e.g. ACCT) pair. Being able to match the external IDs with something your student information system can easily generate is particularly important if you eventually expect to automatically create courses from feeds in the next phase of your implementation.

 

*Note: If your organization is small, does not have campuses, or all syllabus management will be performed centrally, you may not need to take advantage of such thinly sliced segmentation and can drastically simplify your implementation. For example if you never expect to assign domain permissions for a campus, you might include a single Campus called “All” to represent every school, department. You can always expand the granularity of domains at a later time as the complexity of your implementation grows.

 

Domains and Templates

Since a large motivation for implementing Concourse is often the ability to distribute template (both uploaded or structured) management, we dedicate a section here to how these play a role with domains.

Let’s say you have a template for Calculus 101. Should this course be placed in the Main-Science>Math domain? Not necessarily, because it’s not only for the Main campus. Or what about the institutional template which applies to every campus, school, and department?

Furthermore, what if you want to have a dedicated team of people to manage templates separate from chairs who up till now are able to edit all syllabi in their department?

For this reason it is usually necessary to introduce a “dummy” domain to organize templates, in other words a campus, school, department triplet of Template-Template>Template. In fact you can further breakdown template management with Template-School>Department domains for more complex/distributed template administration. 



Final Reminders

There are a few other points to keep in mind when deciding how you will administer Concourse.

Growth:  First, give some consideration for growth. Given how intertwined administrative domains are with templates and integration, it behooves the implementation team to think about future adoption possibilities as the institution expands or restructures. For example, even if you are a single department piloting or using Concourse, think about what the solution might look like at full scale. Even though campus might not make sense for you right now and you may be tempted to change it to something like program, is that in the best long term interest of everyone later on?

Test:  Try everything in the sandbox first. See how different domain structures fit your needs. Assign permissions. Create dummy accounts to experiment with interactions. Try to edit content or audit syllabi you should or shouldn’t have access to. All of this is especially important as a predecessor of template design but before you embark on integration and automation.

Simplify:  Don’t attempt to cover every nuance of every situation from the get go. Start with a simplistic administrative structure with only a few administrators assigned. Centrally manage templates (or even start without templates and allow faculty to upload existing syllabus documents). Hold off using audit until a future term. Maybe you needn’t assign reporting capabilities because your guest access doesn’t restrict any content. The key is introducing complexity over time and only when it’s needed.


    • Related Articles

    • Integrating Concourse

      Integrating Concourse with your institution’s existing systems means that your students, faculty, and staff will be able to seamlessly work with Concourse while significantly reducing manual processes, duplication, and errors. It’s truly the way to ...
    • Concourse Audit

      Audit is the process through which syllabi are reviewed and approved. This is often useful for new course approval, template finalization, and section (i.e., instructor) syllabus review. The audit process has several stages and is exclusively ...
    • Planning for Concourse Implementation

      We are excited that you are ready to hit the ground running with Concourse! The following information will not only assist with your planning for each phase of the implementation, but should also serve to mitigate as much as possible the roadblock ...
    • Themes for Concourse

      A system-wide theme can be applied to your installation that is consistent with your brand. This includes a prominent login image, placement of your logo on the top of every syllabus, and colorization of menus, icons, and syllabus accents. Theming is ...
    • Group Permissions in Concourse

      Concourse employs mass permissions for groups to assist institutions with enforcing access and editing capabilities within the system. The Syllabus Geeks understand that differentiating between these groups within Concourse can be somewhat ...