Best Practices in Role Management


Published on

Presented at D2L's FUSION Users Conference in July 2005 in Madison, WI.

Published in: Education, Technology, Business
  • Be the first to comment

Best Practices in Role Management

  1. 1. Best Practices in Role Management Changing needs and solutions Kyle Mackie Shawn Vance eLearning Program Manager Technical Support Manager
  2. 2. Role Management  Introductions  Definitions and Literature Review  The Slippery Slope  How’s, Who’s, Why’s of Role Creation  Recommendations/What to think about  Future directions in Role Management  New ideas brainstorming session
  3. 3. Quick intro – Kyle  eLearning Program Manager – Technical support team, development and maintenance of websites – Training Instructors on D2L platform tools – Creating Roles and assigning permissions
  4. 4. Quick intro – Shawn  Technical Support Manager – Manage day to day support operations – troubleshoot and assist with technical issues – Provide input to development/product management based on client feedback – Seeks ways to improve customer service ie) new 24/7 Support initiative.
  5. 5. Quick intro – Open Learning, UofG   250+ DE courses  18,000 enrolments  9 org units  “legacy client”  do things a bit differently
  6. 6. Definitions  What is meant by role? – A role is comprised of a collection of security settings in the D2L system. Roles are applied to users at the orgUnit level. Users can have different roles and different orgUnits. Assigning permissions to a role dictates what the role will be able to see and do within the system. By default, organizations are set up with three roles: student, instructor and administrator.
  7. 7. Definitions  What is meant by role? (cont’d) – Organizations have full control over the roles in their system. For example, administrators may create a “Student Helpdesk” role for students who are responsible for the student helpdesk. This role may be similar to the role of a typical student, yet the helpdesk role will have more permissions surrounding sending out login information and unlocking student accounts.
  8. 8. Definitions  What is meant by permissions? – Permissions are rights or privileges that are organized by tool and granted/denied by OrgUnitType. A set of permissions define what a role can and cannot see and do within the D2L System.
  9. 9. Why are roles so friggin’ important?  If tools don’t work properly, it might be a permissions issue. (401 Not Authorized Errors)  Every school is different, every program is different  D2L’s tool is almost infinitely customizable BUT…
  10. 10. The slippery slope  Instructor  Coordinator  Teaching Assistant  TA without grades access  TA with read-only grades access  Instructor with access to quiz management  TA with access to quiz management  Guest instructor
  11. 11. The slipperier slope  Info Desk  Production and Info  Assignment Coordinator  Operations
  12. 12. The slipperiest slope  Importing users from different orgs  Different tools  Different configurations  Different needs  Cascading…forever
  13. 13. How roles are defined  Default settings  Customization options  Copying, naming
  14. 14. a million checkboxes…
  15. 15. …and not much sense
  16. 16. Who defines roles  Default settings  Administrative person/group – defining who gets to define roles – editing/viewing permissions – how information is shared among team  Keeping track – users in different orgs – descriptions, etc.
  17. 17. Why roles are defined  administrative needs  control versus freedom  institutional policies (privacy, AUP) especially grades, class list  individual whims  special circumstances (award submission)  new tools, new versions
  18. 18. Recommendations  Keep it simple  Dedicated staff for role management – NOTE: We recommend that only high-level administrators have access to the Manage Roles and Security tool.  Clear naming convention and description  Try to make new needs fit into existing structure, before creating new role  Clarify "wants" versus "needs“  Things are always changing
  19. 19. Recommendations - continued  uber org vs. multi orgs  copy roles to preserve originals when experimenting with different setups  new users -> plan out what roles you think you may need in advance  20 questions  and test again – At orgHome and course offering level  Examine D2L release notes and consider impacts
  20. 20. The future – new ideas  Per user security settings (Windows-based permissions. User/group type)  Import/export and sharing roles  Select all  Set permissions for multiple roles/orgs  Diagnostic tool  Linked permissions – class list, IDs…  Easier to read screen layout? Suggestions?  Other ideas?
  21. 21. Questions?  Questions about Role Management?