Curriculum Management Permissions

Overview:

  1. User roles
    1. Categories of roles:
      1. Workflow roles
        1. Specifies what actions within a workflow a user can take by granting access to buttons within a workflow state.
        2. Determines what workflow a user is required to take an action within - i.e. what workflow a user is going to review and approve proposals within.
        3. The workflow role a user is assigned will send email notifications when a proposal they have the access role for, is within this workflow state.
      2. Access roles
        1. Specifies which course and program (i.e., departments, colleges, etc.) folders a user has access to. These folders are where the proposals sort when going through the workflow states.
        2. Higher level access roles inherit the rights of lower access roles - i.e., a user who has access to a program also has access to all courses within that program.
      3. User Roles
        1. Roles created using a combination of the required roles for a given user. A user role can contain the workflow role and access roles needed to complete access for a specific user. The user role will be labeled with the access it provides and allow the ability to simplify assigning roles to users by combining the roles needed for assignment. For example, a user role labeled "Dean English Department" would have the workflow role that accesses the Dean workflow state as well as the access roles to the folders that are containing proposals related to the English Department. When the single user role is assigned to the user, it provides them with the full access without having to maintain the knowledge of exactly what roles the user needs for this access.
    2. A user can have one or multiple workflow and/or access roles depending on when they have to approve a proposal in the workflow and what types of proposals they need access to to accomplish this.
    3. Roles are created based on the workflow and access needs of the institution.
      1. The institution provides a list of departments (programs) and course subject codes that determine the roles created for that institution. These become the "cm access" roles for the folders where the proposals will be sorting upon submission within the Proposals folder in the Curriculum Management System.
      2. The access roles assigned to user profiles for the CM systems, are accessing the sorting folders that specific proposals are within during the workflow process.  These are commonly labeled the department, program or course subject code that the proposals are associated with.
      3. "CM Full Access" roles do not grant full access to the user assigned - this role is to access the "Full Access" folder within the sorting folders. Proposals will sort within this folder when they are in a workflow state that is not relevant to the department/subject code they belong to. For example, a Registrar workflow state. Usually the registrar reviews all proposals regardless of their department. The proposals will sort into this folder so the registrar has access to all of them for review during this workflow state.
      4. Role naming conventions may be different but the functions share some common characteristics. Access roles are always accessing an item within the content tree while the workflow roles are always accessing specific workflow states and the buttons within them for the review and approval of proposals.
      5. Curriculum Management profiles are similar to the catalog. Each user who participates in promoting proposals receives a workflow role and this role is the workflow state that they are approving proposals at.
      6. Any number of custom roles can be created for an institution.
      7. A user who is only going to need access to submit proposals only requires a "basic user" role to access the system. These roles are usually titled "cm basic user" and grant the user access to the forms as well as read access to the dashboards.
  2.  Workflow, Notifications & Dashboards
    1. As work moves through the workflow, an email notification can be sent to the appropriate user(s) alerting him/her of new work items.
      1. Email notifications can be set up to be instant, an email goes out to the user(s) when it moves through the workflow, OR they can be set up to scheduled and all go out on a specific day of the week. There cannot be a mix of these.
      2. Email notification roles are also available to send notifications to users who may not have the workflow roles, but need to receive the notification of proposals in a specific state, of a specific form, etc. All notification roles are set up as instant email notifications and are the one exception that can be mixed with scheduled notifications.
    2. Dashboards are available to users to view work items in queue.
      1. All Curriculum Management systems have a common dashboard that shows all proposals in progress, a My Items dashboard that displays the logged in users drafts and any proposals that require their action to be promoted, and an Archived Proposals dashboard that holds all proposals that have been approved throughout the history of using the system.
      2. There is a default set of columns/filters set up on the dashboard. Other fields present on the forms can be added as another column on the dashboard for proposals to be filtered by.
    3. Workflow is provided by the client and set up by SmartCatalog in advance.  Any change to the workflow (or role definition) must be communicated to and configured by the SmartCatalog team.
      1. A 'draft' state is always the first step in any work flow. (Unless requested to be titled differently)
      2. Workflows can be forked (i.e., exception/divergent paths) as needed by the institution. If the forked path is disabled, the work continues to the next stage within the pre-defined workflow.
      3. Fields on the forms can act as workflow triggers and send specific proposals through workflow routes determined by checkboxes or options chosen on the form.
      4. It is important to retain documentation of the requested workflow and any changes requested so you are fully aware of how the workflow is supposed to function when requesting changes to it.

All users have access to see all proposals on the dashboard and preview them, but they may not have access to edit a proposal unless they have the appropriate combination of access and workflow role to edit the proposal.  This type of access is determined by roles assigned to each user's profile. 

All users within the system are assigned permissions to grant them access to the Curriculum Management system. For users who are not expected to approve proposals throughout the workflow, they are assigned a "basic user" role to allow them access to the dashboard and for their ability to populate and submit a form.  The roles determine what they can access to change/edit/review/approve. A user must have at least a "basic user" role to access the dashboards. 

The Admin role is designed to access all proposals and workflow states. This enables the admin user to perform all duties within the Curriculum Management system. When a user is made an administrator, the only role that is required for the user profile is the institution\admin role.  Adding other workflow roles to the same profile can interfere with the admin role's access. Due to this, it is recommended that admin users not have other Curriculum Management workflow roles assigned to their profile. If an admin needs to receive email notifications for a specific workflow state so they can take action on proposals, there should be a request for an email notification role to be set up. 

Access to both the User Manager and the Role Manager is available from the Launchpad:

Launchpad Buttons Permissions Management