Holding Tank Transition Planning
With the End of Life of SIS – Holding Tank announced for September 1, 2022, you may be wondering how to prepare for the change. Do not worry, D2L is ready to help ensure this is a smooth transition for your site. Dedicated resources will be assisting you throughout the process and this page will provide some of the relevant information about the transition for your planning purposes.
Table of Contents
Step 1: Review the Getting Started Materials
End of Life Notice for: SIS - Holding Tank
First Steps for Transition Planning
Determine if you are using Holding Tank
Fill out the introductory questionnaire
Begin communicating with the transition team
Join the Holding Tank SIS Transition Community Group
Step 2: Deciding which Integration Product to use
Is D2L Standard CSV the right option for your environment?
What is D2L Standard CSV?
How does D2L Standard CSV differ from Holding Tank?
But I need additional features in D2L Standard CSV!
Are push-button integration available?
Alternatives to D2L Standard CSV
Can more than one integration be used at once?
Step 3: Holding Tank to D2L Standard CSV Project
Project Goals
Project Milestones
Project Resource Commitment
Project Time Commitment
Project Timing
Step 4: CSV File Development
Beginning file development
Step 5: Going live with your new integration
Go Live day planning
Step 6: Future Options
What options are available for future expansion once you are using D2L Standard CSV?
Step 7: Keys for Success after the Integration Change
Preparing your Brightspace Admins for the Integration change
Looking for additional information?
Frequently Asked Questions
Related Links
Feedback
Step 1:
End of Life Notice for: SIS - Holding Tank
The End of Life Notice provides information about the effort to transition off of Holding Tank as well as timing information to begin your planning activities.
First Steps for Transition Planning
Determine if you are using Holding Tank
Years of chugging along with the same product that you may not call by the same name that D2L uses can leave you confused about which integration product you are using. There are a few places where you can check for what product is in use. D2L is also here to assist if you need further details about what integration product is used in your environment.
Areas to check when determining if Holding Tank is being used:
- If you check the Course Mapping Interface and SIS Integration Logs when troubleshooting or working with your integration, these are components of Holding Tank.
- If your SFTP account uploads files to a Holding Tank folder, this is a Holding Tank setup.
- If you view your configuration from the IPSIS Administration page, that is the IPSIS family of products and not Holding Tank.
- If your data is synced from the Luminis Message Broker, that is the Banner Integration Component, not Holding Tank.
If you are still in doubt as to which integration you might be using please contact the transition team for assistance.
Fill out the introductory questionnaire
The transition team has created a questionnaire with a variety of questions all intended to provide D2L with some background regarding who we will be working with on your side, timing or potential conflicts that would affect when we can start working with you, as well as details about how you are using your environment. D2L can see your Brightspace configuration details, however, that doesn't give the complete story of how and why you might be doing certain things as it relates to your integration.
Once the questionnaire is completed, D2L will be in contact with you to further discuss your specific transition project, within a week. Although not required ahead of time, the questionnaire will be one of the first requests from the transition team.
Begin communicating with the transition team
The transition team is ready to assist you with this change. If you have questions about the transition plan for your site, you can contact the dedicated team at D2L using the SIS Transitions email address or by contacting Customer Support or your TAM. If you have questions about how to use D2L Standard CSV we recommend adding those to the Holding Tank SIS Transition Community Group established for this purpose so other clients can benefit from the same information.
D2L will be directly contacting all affected clients by June 2021 to begin planning their transition if it is not already in progress. If you haven't been contacted yet but are ready to get started, that is great and you can contact the transition team to get started or fill out the questionnaire and we will contact you regarding the information you provided.
If you have not been contacted by the end of 2020 and believe you have Holding Tank in use at your site, please email the Transition team so we can assist you further.
Join the Holding Tank SIS Transition Community Group
A Brightspace Community Group has been created for Holding Tank SIS Transitions to allow for a forum where clients and D2L can work together to share knowledge as the end of life program progresses. Our desire is for this Community group to be a place where you can learn from peers who have already completed transitioning and share your experiences to help others in the future. D2L will be participating and adding Key Facts, Interesting Changes, and other items to help along the way.
Brightspace Community members can join the group to post or reply to questions or conversations.
Step 2:
Is D2L Standard CSV the right option for your environment?
For most clients D2L Standard CSV will provide all the features needed to integrate with Brightspace. D2L is evaluating all configurations and customizations to ensure we are providing clients with the best advice based on their current integration setup. In many cases slight alterations will be needed to the integration process to accommodate the changes within D2L Standard CSV but the end goal of consistency for end users would still remain the same.
What is D2L Standard CSV?
IPSIS is an Integration Product within Brightspace that allows for multiple integration types. These integrations are designed to allow org structure, user, and enrollment information to be added or updated within Brightspace typically from an external information system ie SIS/HRIS/etc. D2L Standard CSV is a type of integration within the IPSIS product family that uses a D2L proprietary standard for sending fields within a set of CSV files. Access to the data within your information system will be needed to create the extract files. Normally the files are created by specialized code the information system vendor has written or by the client writing custom code to pull the data for their needs.
D2L Standard CSV is designed to allow for processing of data that has changed often throughout the day. ("Differentials"/"Deltas") All current data can be sent ("Fulls"), rather than only changed data, but that does cause extra processing and should not be sent multiple times throughout the day. D2L Standard CSV is built to be performant and not to cause negative performance impact to your Brightspace environment. Holding Tank, as an older product, could cause performance issues when run during business hours. However, even though the performance of D2L Standard CSV is better than Holding Tank, clients should evaluate their data update needs and only provide updates as required by their business processes. The data updates that occur change live user and course data so care should always be taken to ensure the integration does not cause issues for end users by incorrectly updating information. A large benefit of D2L Standard CSV over Holding Tank is that data will not be updated if it is not included in the CSV files. That means smaller files take less time to process and you won't have to worry about changes made within Brightspace being overwritten by the integration unless the data is synced and your configuration allows for the updates.
How does D2L Standard CSV differ from Holding Tank?
D2L Standard CSV has many exciting differences from Holding Tank that will make administration of your integration easier. The most important change being, no middle database for processing information. With Holding Tank, your XML files were processed and the data was saved to a separate database. Then that database was compared to your Brightspace database to determine what data to update based on your configuration. This meant that even if you didn't send any XML files the Holding Tank would still compare what it already knew to what was in your Brightspace environment which prevented direct updates within the Learning Environment and required tasks such as End Semester Batch.
Key differences:
- No middle database maintaining previously sent data, allowing for easier switchover to managing the data within Brightspace when the integration sync is no longer needed
- No End Semester Batch, if you stop sending updates for specific data it will no longer be updated
- New, more modern, and easier to use administration pages
- CSV standard rather than XML making raw files easier to build and understand
- No D2L determined schedule, you send your files when you need to
- Processing as often as every 10 minutes, so you can send your files more often without building an API integration
- No multiple parsers, one standard is in use that will function the same for everyone. You can select your configuration but you don't have to worry about confusing differences based on "type" of file
- More features
- No implicit enrollment changes, enrolling and unenrolling users is controlled by exactly the records you send either UPDATE or DELETE commands rather than based on a comparison of what you sent and what exists in your environment
- SFTP Password reset can be done in the administration page by you, no support case needed
- Changing a user's OrgDefinedID can be done in the administration page by you, no support case needed
- Files are processed in alphanumeric order so you determine the sequence files are processed in, rather than based on object type. Allowing for more freedom to create objects when needed such as a 1-parentusers.csv and a 2-studentusers.csv to create parents before processing students with their parent relationships
- SFTP site will change, to a dedicated IPSIS site for your environment so no more worries about putting the files in the wrong folder
- No more archive location to view your previously processed files, instead coming soon you will have the ability to download the previously processed files from the last 30 days
- Notifications can be setup in the regular Brightspace notifications page, no support case needed
- Semesters and Departments are created by the CSV files, eliminating manual creation tasks in Brightspace
- Mapping of the roles in your CSV files to your Brightspace roles can be done directly in the IPSIS Administration page, no support case required to send additional roles
- Ability to re-run a batch is available within the IPSIS Administration page, no support case required
- No Auto-Group required, courses and sections are connected based on the relationship you send in your CSV files. There is no need to run a separate process to connect the two objects. If you need to associate two course sections into one course offering within Brightspace there is a Section Association tool available.
But I need additional features in D2L Standard CSV!
If there are additional features needed that are not current functionality of D2L Standard CSV, please start by informing the transition team of these needs. Reasonable alternatives using things like Brightspace APIs or PIE requests for future functionality are some of the avenues the team might suggest.
Are push-button integrations available?
In some cases your information system provider might already have a developed integration that will work with Brightspace using a recognized standard such as LIS or OneRoster. We have even seen vendors creating integrations using D2L Standard CSV. D2L continues to add information system partnerships so options might be available to you now that were not available during your initial Holding Tank Implementation. D2L maintains a list of information system providers with verified working integrations that can be generally used (compared to custom built integrations from an information system that might not be available to additional clients). Providing your information system provider information via the Questionnaire will help us enable you with the latest information about integrating with that system. In some cases your information system provider may create a custom integration for you that is not generally available to their other clients. Please connect with the transition team about this type of work so we can work with you and your provider to transition your site.
Alternatives to D2L Standard CSV
There are a few alternatives to using D2L Standard CSV which all serve differing needs. The options include LIS, ILP, API, and OneRoster.
The IPSIS product family includes LIS, ILP, OneRoster, and D2L Standard CSV.
- ILP is specifically for Ellucian clients using the Banner or Colleague products. A transition to ILP would involve resources from Ellucian, the client, and D2L as well as requiring specific product versions on the Ellucian side to be used by the client.
- LIS provides the most flexibility but that comes with added complexity. A move to LIS would need additional consulting to ensure all use cases are planned out to prevent issues.
- OneRoster is usually used by K-12 clients and has a CSV and REST option. Several information system providers are able to integrate using OneRoster, if your information system provider can use OneRoster and you would like to evaluate this option contact the transition team.
APIs also allow for a lot of flexibility but again at the cost of complexity. It would be a bespoke solution built by and for the specific client. Undertaking an API integration would require a longer commitment from the client development team as well as potentially a more complicated ongoing support requirement than D2L Standard CSV.
D2L Standard CSV was selected as the ideal solution for clients migrating from Holding Tank because of its simplicity. The files are in CSV format which is inherently easier to create than XML. The fields are in plain language and directly correlate to objects you see within Brightspace. D2L Standard CSV will serve the use cases of current Holding Tank users while providing the flexibility should you choose to add future products to enhance the Brightspace experience such as Brightspace for Parents, Auditor Relationships, Manager Dashboard attributes, Preferred Names, and Upper Org Unit Support to use with Custom Login Logic.
Can more than one integration be used at once?
D2L does not recommend using more than one integration at once. It is very easy to intersect data between multiple integrations causing data to be potentially incorrectly updated. For this reason, the ideal transition is between semesters when there can be a clean cut-off of Holding Tank prior to turning on IPSIS - D2L Standard CSV functionality. Some clients do use APIs to round out integration functionality for specific use cases. That is an option when needed but does require careful planning. D2L's recommendation is not to use a standard integration and APIs to manage the same objects. For instance, APIs could be used to add a Profile Picture for users, but D2L Standard CSV manage the users. Creating users through API and D2L Standard CSV is not recommended due to the risk of data collision.
We wanted you to have all the information you need for this transition but it is a lot of information. If you have read everything so far, Congratulations! Now take a break and stretch your legs before continuing on.
Step 3:
Project Goals
The goal with these transitions is to allow administrators more flexibility and a more performant experience while not disrupting the end user experience. The no cost transition will involve configuring IPSIS to be as close to the workflows used in Holding Tank as possible. If an evaluation of the integration process, org structure, or more in depth conversations about site usage need to occur, that would require dedicated time with an Implementation Consultant to be arranged through your Account Manager. In most cases the ideal scenario will be to move to D2L Standard CSV, followed by scheduling a future Health Check to begin evaluating how to continue evolving your site usage.
Project Milestones
Each transition project will involve a standard set of steps which are listed below. All transitions will involve full testing in a client test environment with real data prior to any changes in production. A full go-live day plan will be in place to ensure a smooth roll-out. Client sign-off is required for a go-live date to be locked in. Post go-live, D2L will follow-up to ensure normal daily operations have proceeded using the new user interfaces and processes.
Project Steps
- Initial Project Decisions Made
- Client completes questionnaire
- D2L evaluates current client environment setup
- D2L and Client to confirm D2L Standard CSV usage vs referral for an alternative option
- D2L and Client to discuss any identified gaps or questions about changes
- Client confirmation of development timelines and estimated go-live timeline established
- Development of CSV files
- D2L to disable Holding Tank in test environment
- D2L to configure Holding Tank in test environment, if additional Holding Tank files must be processed for testing and Holding Tank is not currently running in test
- Client to upload additional Holding Tank files, if data in the test environment is not up-to-date enough for testing
- Client development team converts XML output to CSV format
- Client to place initial test files on existing SFTP account in a folder named "IPSIS" (no automated processes will process these files)
- D2L verifies the test files and works with the client development team if there are any issues
- Client to provide a full set of CSV files, once file format is correct
- D2L configures IPSIS in the client test environment
- D2L will run the full files provided by the client into the client test environment, watching for issues and validating data
- Client will validate data in their test environment for accuracy and completeness
- Client to setup new SFTP user and password using IPSIS Administration page within Brightspace
- Client to trigger files to be sent to the test environment via the new IPSIS SFTP account, usually files are sent a few times for testing
- D2L and Client to validate data in the test environment following test uploads
- Go-Live Day
- D2L to disable Holding Tank in the production environment
- D2L to configure IPSIS in the production environment
- Client to provide CSV files with all transitioning data via existing SFTP account
- D2L to complete a final verification of files
- D2L to run full files, one at a time, into the production environment watching for any issues
- Client to verify data in the production environment for accuracy and completeness
- Client to setup new SFTP user and password using IPSIS Administration page in Brightspace
- Client to trigger regular files via SFTP
- D2L and Client to do final verification of data in the production environment prior to go-live sign-off
- D2L and Client to finalize Go-Live timing for the production environment
- D2L and Client to review Go-Live steps
- D2L to provide training to client on IPSIS Administration functionality and suggested processes
- D2L to verify with Client that new administration processes are running smoothly and any final questions before ending the project (normally over a few weeks after go-live)
Project Resource Commitment
You’ll need a Development resource(s), either from your information system vendor, a 3rd party, or your own organization depending on who owns the information system extracts that are processed into Brightspace. They’ll need to develop new information system extracts to conform with new formatting requirements (CSV instead of XML).
You’ll also need resources to perform testing of the new integration and troubleshoot output format issues with D2L, typically team members who use the information system and Brightspace integration regularly.
Lastly, tool training will be provided for your Admin resources who use information system functionality within Brightspace as there are user interface and functionality changes to learn about.
Project Time Commitment
The exact length of time from start to finish of this transition project can vary, mainly based on availability of resources on the client side. The level of effort for the code changes varies based on the complexity of the current Holding Tank setup as well. The project from start to finish could be completed in as little as a month or could take multiple months to complete. A very general estimate would be 8 hours of effort for development, 5 hours for client administration, and 8 hours for D2L to complete the project spread out over multiple weeks. A real estimate would need to be established in cooperation with the client development team based on an evaluation of the current setup and the needed changes.
Project Timing
The ideal transition would involve the go-live occurring between semesters when a clear cutoff point between Holding Tank and IPSIS can be used. That would mean no ongoing courses have data being sent from the information system and that there is a break between when enrollment updates for one semester stop and course creation for the next semester begins. This isn't always possible due to ongoing courses and timelines to allow instructors to get started creating course materials. We can workaround this carefully but it does require planning between D2L and the Client.
Some options that have been used are:
- D2L to verify with Client that new administration processes are running smoothly and any final questions before ending the project (normally over a few weeks after go-live)
- Delaying the next semester's data population slightly
- Stopping automated enrollment updates early and completing a limited number of updates manually within D2L
- Transferring ownership of data for an active semester to IPSIS
Having IPSIS take over updates to data that Holding Tank created requires very careful validation of the data files because the primary keys for all data must match exactly between the two integrations to prevent duplication of objects.
D2L recommends delaying any projects that will require new data to be sent through your integration until after the transition is complete. For instance, if you are planning to add Brightspace for Parents it is recommended that the transition to D2L Standard CSV occurs first followed by the addition of Brightspace for Parents at a later date. This recommendation is intended to reduce the number of workflows that need to be transitioned, reduce duplicating work on the client side, and mitigate timing complexity from overlapping projects. If a project that affects the integration must occur before the transition please inform the transition team so they can help manage the timeline issues.
Step 4:
Beginning File Development
Start small with file development. Create one file at a time and populate with one record ensuring that the file specifications are produced correctly. Once the base requirements are met expand out to populating with more data and validating the formatting meets your requirements.
Semesters and Departments should now be managed by the integration, where previously you had to create these manually. Including these values will be a change to your extract code but it will be beneficial for administration purposes as it removes some manual tasks.
The definition of a Department or Semester is based off of the Standard Department and Standard Semester settings within the Org Unit Type Editor. You may call your Semester by a different name such as Term but if it is defined as the Standard Semester you would send it as the Semester type. Other custom org unit types would be used as an other org unit type. The name of the type sent in the file will be mapped to the org unit type in Brightspace within the IPSIS Administration Configuration page.
Creation of course templates and course sections are now explicit. With some of the Holding Tank parsers, the creation of templates and sections occurred implicitly based on the naming convention of the course offering. This is no longer the case, because templates and sections are created via their own CSV files, giving you more control over these structures. For sites that previously used a parser that did not require these objects to be explicitly created this will require a change to your extract code. It does mean that your course offering code is no longer constrained to be a particular naming convention by the integration, you can use whatever naming convention works best for your site.
Already existing objects can be updated using D2L Standard CSV as long as they are sent through the files properly. The org unit code or orgdefinedid used for org units or users has to match exactly with the information that is already in Brightspace. If the data does not match exactly you could have duplicate objects created. For instance if BIOL-101-01 already exists in Brightspace and you send BIOL-101_01 through your CSV files you would end up with a new org unit created rather than the existing object updated. This won't unenroll or delete the existing course preventing users from completing course work, but it can cause confusion because the users will see two seemingly identical courses and it can cause enrollment updates to not flow into the existing courses blocking access for new users.
Changing the identifier for your org units can cause confusion for your users and should include added notifications to ensure stakeholders are prepared for the change. Changes to your user identifier can have a bigger impact because authentication methods rely on these details. If you are interested in changing your user identifier please contact the transition team so we can discuss the change with you and assist with evaluating the impact to any user authentication methods.
There are multiple verbs that can be used in the CSV files; UPDATE, CREATE, and DELETE. The default to use is UPDATE. If the object does not exist and UPDATE is specified, the object will be created. To remove an enrollment, DELETE must be used.
Currently file verification occurs in cooperation with D2L. Prior to running any data into your test or production environments, the transition team will manually review your files to look for any potential issues so they can be fixed before adding the data to your environment.
Some clients experienced issues with Holding Tank hanging or not running at their scheduled time due to updates or other interruptions. This issue will not occur with D2L Standard CSV. There is no scheduled task setup within Brightspace, instead your files are processed when you provide them. This means the responsibility for selecting the optimal time to run the files based on business processes and your Brightspace usage patterns would fall to you, with some assistance from the transition team.
A Quick Start Guide to help translate the fields from Holding Tank to D2L Standard CSV has been created. This includes information about switching from Holding Tank XML Parser 1, Holding Tank XML Parser 2 , and Holding Tank XML Parser 4.
Parser 2 is built upon implicit enrollment updates. It expects all users enrolled in a course to be included every time files are provided and compares those users to the users enrolled within Brightspace. Any users enrolled in Brightspace that are not in the files are unenrolled from the course. This type of enrollment model is not supported in D2L Standard CSV. Any clients using XML 2 will need to send unenrollment events explicitly. Please discuss with the transition team any challenges in providing this information.
Step 5:
Go Live day planning
D2L has developed a go-live day plan designed to simplify the day but also to allow for identification of any issues early in the process to avoid affecting your end users. There are certain areas to be aware of as you are thinking about this roll-out. Timing is a key concern to ensure courses and enrollments are in place when needed and not to disrupt enrollment updates to in progress courses. The amount of data to be sent for the initial go live is important. For D2L Standard CSV to use an org unit as the parent of another org unit, enroll a user or create a relationship with another user, or enroll into a particular org unit, it must know about these objects first. That means that the initial data load needs to include a larger set of data than you would normally send. At least the following is recommended:
- Semesters should include the next semester to be acted upon and potentially the next few semesters. This is to ensure courses can be setup as children of this semester. Your ongoing data loads should send new semesters on a rolling basis. Past semesters are not needed unless you are still creating courses for the semester.
- Departments should include all currently active departments that could have course children. Deleted or discontinued departments are not needed unless you are still creating courses for the department. Your ongoing data loads should create new departments if they are created in your information system.
- Custom org unit types in use would follow similar rules to Departments. For instance, if School org units will be managed through D2L Standard CSV, any schools that will have course children should be sent in the initial data load.
- Courses only need to be included when you want to manage enrollments for them. For the first data load, if enrollment still needs to be managed for a past semester any courses under that semester that require enrollment changes must be sent and must match exactly what is in Brightspace currently. For the next semester, the courses might be created in bulk on go live day or may be created at a later date. This will depend on your go live timing and timing for when you want to create the next semester for instructors to begin building their courses. For most clients the next semester will be created on go live day to ensure any potential complications are handled while the transition team is actively engaged with your team.
- Users should include all active users who could have enrollments or relationships to other users. Keep in mind that users who might not have enrollments this semester, might have them next semester such as students not enrolled for summer classes but enrolled for fall classes. Your ongoing data loads should always include the user before sending enrollment changes. Generally for new users this isn't a problem, for existing users it might not be a part of your integration process which is why including them upfront on the first data load is important. Users with relationships to other users such as parents or auditors must be included before creating the relationship so any such users should be sent with the initial data load and with ongoing data loads as needed.
- Enrollment records do not need historical data sent in the first data load. Only new enrollments for existing semesters or new semesters or changes to enrollments that already exist need to be included.
After the initial data load, either differential or full data loads can be used. Differentials are recommended to allow for more frequent data updates. If full data loads must be used they should only be sent once per day. Some client workflows may work best with a combination of differential and full data loads. The transition team can discuss best practices with your team to help with decisions about the best process for your environment. The timing and process for data loads is decided prior to a confirmed go live.
Internally, the transition team is keeping Customer Support, TAMs, CSMs, Account Managers, and any other relevant teams up to date on who is going live when. Internal tracking of these dates and changes is in place to ensure that after you go live if you call into Customer Support or discuss any of the future options with your TAM, Account Manager, or CSM they can see that you are no longer using Holding Tank and have transitioned to D2L Standard CSV.
There will be a formal closing of the transition project when the transition team validates with you that there are no outstanding issues or questions. D2L wants you to feel that you are enabled to handle this change so the transition team is available to answer questions along the way in furtherance of this goal. In addition, the Community group will remain active to allow for ongoing collaboration.
Step 6:
What options are available for future expansion once you are using D2L Standard CSV?
Moving to D2L Standard CSV opens up a number of possibilities for future expansion, some were in the past available with Holding Tank and now are simpler to implement and others are areas that are not available in Holding Tank. Some of these might involve a project with the D2L Implementation team to assist with an adoption strategy and setup. You should speak to your D2L Account Manager if you are interested in exploring any of the following products.
- Brightspace for Parents
- Auditor Relationships
- Manager Dashboard Attributes
- User Preferred Names
- Custom Org Unit Creation
- Custom Org Unit Enrollment
- Custom Login Logic based on the custom enrollment information
- Removal of some customizations based on functionality available natively within D2L Standard CSV (this will be evaluated by the transition team and communicated with you at transition time)
- Course Copy based on parent template is available using D2L Standard CSV, evaluation of your org structure to ensure you have the correct setup for this and the use case warrants it can be done to simplify your start of semester workflows
Step 7:
Keys for Success after the Integration change
D2L will be providing training to your designated integration administrators as a part of the transition project. Currently the training is a scheduled, live virtual training but a Learning Center course is in development to allow for asynchronous learning as you go (Coming Soon). Additional details about the Learning Center course will be posted here when available as well as announced in the Community group. There are also resources available to help you prepare and for reference as you continue with D2L Standard CSV. Error messages for D2L Standard CSV are intended to be clear and actionable but to assist with this effort Error Message Playbooks are being created to post in the Community group as well (Coming Soon). The Community group will be a great resource for assistance as your team prepares to use IPSIS moving forward.
Unlike Holding Tank, D2L Standard CSV is an active product that receives bug fixes and feature additions as needed. The normal monthly release notes will contain information about any such changes and reviewing the new and exciting changes should be a regular practice to check for improvements that will assist your site. Versioning of the CSV files means that when a new CSV version is released, your site will not need to use it until you are ready. This allows for you to decide when you need new features and plan the timeline for rolling out the changes in cooperation with your development team. Bug fixes and changes that might affect the IPSIS Administration page but do not change the structure of the CSV files will be applied using the normal release schedule and do not require changing CSV versions.
IPSIS Section Association will be a new tool to administrators as well. It allows for merging multiple sections under a single course offering rather than having multiple distinct course offerings and course sections. While this type of merging can be done at creation time from the CSV files, if you don't have the ability to send this information from the SIS or the need to merge courses arises after the courses have been created in Brightspace (but before they have been used), the Section Association Tool is the area to accomplish this task. As with Course Mappings, Crosslisting, or whatever other name you call course merging, merging needs to happen before the courses involved have been used. Only course sections that have been sent through IPSIS can be merged using the IPSIS Section Association Tool, manually created course sections cannot be included in the association. Course merging that occurs after the course is used does result in data loss. More information about the IPSIS Section Association Tool is available in the Brightspace Community.
Looking for additional information?
Frequently Asked Questions
Do the test environment and production environment share the same Holding Tank?
No, normally test and production are configured the same, however, they do not share the same database or SFTP drop location.
How can I test the new setup if my data in the test environment is not up-to-date?
In some cases the test environment Holding Tank may not be configured, running, or may not have received any data files recently. If this is the case and fresh data is needed for testing, the Holding Tank in the test environment will be configured so you can provide a fresh set of data files. Once those have processed the Holding Tank will be disabled to proceed with the transition.
With Holding Tank, I create Semesters and Departments manually within Brightspace, how do I create these objects when using D2L Standard CSV?
Your semester and department objects will be created through the CSV files when using D2L Standard CSV. This means you no longer need to manually create these objects before sending courses for the semesters, freeing up valuable administration time.
I didn't send Course Template or Course Section files with Holding Tank, are they required with D2L Standard CSV?
Holding Tank users did in fact have these objects created, but it was implicitly based on the course offering information provided. With D2L Standard CSV you now have more control over the naming convention and org structure setup for these objects based on what you send from your information system. Course Templates are required to create Course Offerings. Course Sections are required if the Section Association tool will be used in D2L Standard CSV version 2.0. Course Sections are required for D2L Standard CSV versions 1.0 and 1.1.
When are the D2L Standard CSV files processed?
Unlike Holding Tank, D2L Standard CSV does not have a scheduled run time on the D2L side. The files are picked up for processing within 10 minutes of when you provide them. We recommend using differential files if sending them more often and only sending full data files a limited number of times per day (normally once).
Do I still contact support if I need to trigger a special run of my integration?
No, because IPSIS will check for files every 10 minutes, if you need to run your files at a different time than you normally do, you can either drag and drop them in the IPSIS Administration page or send them to your IPSIS SFTP account.
Where do I put the new csv files?
A new SFTP location will be used for D2L Standard CSV. The SFTP location, username, and password are all visible within the IPSIS Administration - Configuration Tab.
Do I still need to request End Semester Batch or End User Batch?
No, those are Holding Tank specific tasks that are no longer required with D2L Standard CSV. If you stop sending data updates for a course or users the integration will not make any changes to the objects within Brightspace.
What if I don't see D2L Standard CSV in my Admin Tools menu?
D2L Standard CSV is a part of the IPSIS product family. To view the configuration or logs related to D2L Standard CSV you should use the IPSIS Administration page from your Admin Tools menu.
What if I don't see IPSIS Administration in my Admin Tools menu?
That could be one of two things: either your role has not been given access to IPSIS Administration or the IPSIS tool is not turned on in your environment. If you do not see the option to add IPSIS Administration permissions within Roles and Permissions please contact the SIS Transition team to enable IPSIS for you.
I lost my SFTP password, do I need to create a support request?
No, you can reset your SFTP password yourself directly in the IPSIS Administration - Configuration Tab. Remember to reset the password in any automated processes whenever you reset it via the IPSIS Administration page because the old password will no longer be valid.
What is an information system?
For the purposes of this guide, information system refers to an external to Brightspace system that houses information about courses, users, and enrollments. The information system would provide that data to Brightspace for the configuration of the organization structure and enrollments. Examples of information systems to integrate with Brightspace include Student Information Systems (SIS), Human Resources Information Systems (HRIS), or Active Directory. (AD)
What is crosslisting/course mappings/section assocation/course merging?
Crosslisting, Course Mapping, Section, Association, and Course Merging are all names for the same type of task using the various integration products within Brightspace. The purpose of these tools is to allow for what is distict courses from the SIS to be combined into one combined course offering within Brightspace. This results in one course offering with multiple course section children. The users who were enrolled in the various separate courses are all enrolled in the main course offering and remain enrolled in their respective course sections. The benefit of this setup is to allow Instructors to post their course materials in one area and manage their course from one location. Students will only interact with other students with their course section and Instructors can filter in tools like Grades to view one section at a time. Within IPSIS, the tool used is the Section Association Tool to merge courses and course sections that have been created by IPSIS. Note, course sections are required to use the Section Association Tool.
Is pipe "|" an illegal character?
The pipe character "|" is a reserved character so it cannot be used within an org unit code in any CSV file. This is due to its use as a delimiter in certain fields within the file but also due to its status as an illegal character with the org unit code field within Brightspace.
Is there any way to use illegal characters within the CSV files?
Some characters can be escaped within the CSV files, allowing for their use. This can only be done with certain characters in certain fields. Escaping the special characters requires the value to be enclosed with quotes. Within Org Unit Names, the characters , / & can be used. For both preferred and legal first and last names for users the characters ' & can be used.
Can I include non-csv files in my zip?
Non-CSV files within the zip folder will not cause the IPSIS processing to fail. As of the July 2020 release a warning that the files cannot be processed will be written to the IPSIS logs but it will not prevent proper processing of all CSV files. This warning is to avoid cases where the Non-CSV files were intended to be CSV files and admins were not alerted to the files not processing.
If I have existing departments and semesters, can they be used as the parents of new course offerings? Do I need to do anything prior to using them?
Existing objects can be used as parents within IPSIS, however, they must first be sent through IPSIS to determine the correct mapping. The D2L Standard CSV configuration option to map to existing org units must be enabled. Then the existing objects must be sent through the D2L Standard CSV files. This establishes the correct mapping within IPSIS to the objects. After these files are processed, new objects can use these objects as parents. The objects do not need to be provided to IPSIS again unless changes to the objects needs to occur.
If multiple zip files are added to the IPSIS SFTP site within the same period, in what order will they be processed?
Zip files will be processed in the order they are received on the IPSIS SFTP site. The files within the zip folder are processed in alphanumeric order. If the order of multiple zips matters, D2L's recommendation is to wait until the previous file has completed processing prior to placing another file on the IPSIS SFTP site.
Which characters are restricted as special characters?
There are certain restricted special characters within some fields. These characters cannot be used and will cause errors. Within org units, the special characters \ / : * ? " < > | ' , are restricted in the org unit code field. Within user data, the special characters \ / : * ? " < > | @ , ; are restricted in the legal and preferred first and last name fields. Not all of these characters were restricted by Holding Tank previously, this is because Holding Tank had not been updated with the latest rules as the Brightspace environments. These rules are consistent with user management and org unit management with Brightspace to prevent issues caused by these characters when using in areas like within file names or sending via integrations.
Related Links
D2L Standard CSV 2.0
IPSIS Administration
XML Parser 1 Quick Start Guide
XML Parser 2 Quick Start Guide
XML Parser 4 Quick Start Guide
Feedback
Let us know how we can serve you better by leaving your suggestions for this resource in the comments section of this page.
