Introduction
These are the tasks required to perform a rollover in Talis Course Reserves. It should be noted that you will likely want to schedule internal discussions to plan for your rollover. Responsibility for each task is indicated.
Should you wish Talis to provide some additional support or consultancy around planning for your rollover, please get in touch.
Steps to success
- If you have Talis CourseFlow it is important that you liaise with the team that manages this. The reading list rollover needs to happen before the digitised content rollover. Updated September 2017 - If you decide to not rollover your resource lists in Talis Courseflow we have now made improvements to the Rollover in order to cater for this scenario, please see Validation checks - Course Reserves.
-
Decide how you wish to queue your rollovers, this can be by course code, dates, time periods or requester. You can see all requests available for rollover from the “Available for Rollover” option in the “Rollovers” menu.
- Only single requests which are in the status “LIVE” or “EXPIRED” can be rolled-over. It is not possible to rollover a referred or rejected request.
- You can filter this view by the relevant reporting period OR time period - these filters will populate the start and end date filters using information in Talis CourseFlow.
- A queue can be no more than 225 requests, so if you have a large time period to rollover you may need to split the job into smaller queues.
- Once selected, you have the choice to:
- Pre-clear - You can only edit the dates using this option.
- Edit and Pre-clear - You can change the dates, course codes, course names and requester details for requests using this step but multi-selection of requests.
-
Pre-clearing the requests sends the requests back through the concierge and this will result in the following outcomes:
- Referred
- Rejected
- Successful
- Successful requests will be automatically rolled over so they are live and available to the students from the start date of the request.
- Referred requests will need to be worked through individually in order to determine if they can be overridden or rejected.
- Rejected requests can also be worked through or removed from the queue if they can't be overridden.
Rollover jobs are run in the background, so a queued rollover request may not process as quickly as a new request, but you can start to prepare another queue whilst one is processing.