Ready-to-launch Checklist
When you have completed all the tasks for your site development, what remains is the actual launching of your site and making it available to your applicants.
Essentially, you'll want to firm up the official launch date of your site both with your staff and your network administrators. Then, you will want to do a final inspection of the following areas on your site to make sure they are all ready to go. You will have already done most of this during your development process, but it is a good idea to run through these items again as a final check.
General Items
- Public site pages/program brochures
You should inspect all the public site pages (including the program brochure pages) to make sure there is no placeholder content or missing information. You should make sure that all the programs that need to be available to your site visitors are marked as 'active' programs.
Ensure that your staff information is listed correctly.
Ensure that your staff information is listed correctly.
- App Cycles ( Process > App Cycles)
Ensure that the proper app cycles are activated / deactivated. Active app cycles will immediately be open for applications.
Check the process map (Questionnaires, Materials, Learning Content, Assessments tabs in each application cycle) and make sure that the proper process elements are active. If any process element appears with a green arrow, this means that an outdated version of this process element is deployed to that app cycle. Click the green arrow to update.
Use Application Preview ( Process > Application Preview) to do a spot check and make sure that the correct process elements are appearing for various scenarios, dates, and acceptance statuses.
Review program dates and itineraries to ensure they are populated to the extent possible.
Review program dates and itineraries to ensure they are populated to the extent possible.
- Login routines and permissions
You will want to verify that logins are working for your staff, test applicants, and test recommenders. If you have set up reviewers, you will want to confirm with them that they are able to login and access the site.
Additionally, you'll want to review staff permissions. This may include assigning admin users to permission groups and tweaking permissions as necessary on a group or individual basis.
Additionally, you'll want to review staff permissions. This may include assigning admin users to permission groups and tweaking permissions as necessary on a group or individual basis.
User Testing
- Test site from applicant's perspective
Create test accounts or have real students test the system and simulate the process from the moment of searching for a program through the pre-decision and post-decision phase (and beyond, if you wish). (FYI: Test applications can be scrubbed, but profiles cannot) Be sure to touch on the following items:
- Recommendations (have students request them and have admins complete and submit them)
- Questionnaires & file uploads
- Applicant Parameters/Applicant profile
-Test site from admin's perspective
When a test application is submitted, go through the review process and the process of admitting the applicant. Try the other administrative tools, as well:
- Email the student
- Write a comment in the application or profile
- Attach a document to the application
- Apply and remove an application tag
- Change the application status
Technical and Functional Testing
-SIS/HR lookup tests (Maintenance > SIS/HR Tests)
If your site is integrated with a SIS/HR data system, you should use the testing utilities to verify that the data connections are able to find and pull information for both the potential applicants and the staff/faculty names and email addresses.
- Email delivery
Test the email system to ensure that emails generated by both the site as automated notifications (when items get marked as received) as well as direct emails sent by staff members (using the 'email' tab in the application administration interface) are being properly received by the users.
- Scheduled tasks
Check the Maintenance > Task Scheduler utility to make sure there are no 'missing' tasks listed. If you are a hosted/SaaS account, you can request that Terra Dotta do this for you via the case system.
- SSL Certificate
Verify that when logged into the site, the URL has 'https' and not 'http' prefixing the URL. If the site doesn't display 'https' after you login to the site, you will need to contact the server administrator regarding the installation of a Secure Socket Layer certificate for your website to ensure that all data transferred after login is secure.
Internal Readiness
-Outline internal process for managing applicationsThere are a number of administrative tools at your disposal, including application tags, internal questionnaires, status aliases, query watches, saved queries and reports. Focus on how your office will manage the following administrative tasks:
- Reviewing completed applications
- Contacting new applicants (this could be automated through a query watch)
- Following up on incomplete applications
- Adding/editing application itineraries
- Enrolling applicants in insurance/flight or arrival information/visa paperwork, etc.
-Documentation on settings, features, changes
If you haven't been doing so throughout the implementation process, consider developing notes for your office that document how you are using different items in the software. Defining and documenting your use of these features and settings as you go will help minimize confusion as your staff learns the system and as you encounter office turnover. Although you may not be using some of these features yet, they may be of interest to you once you go live:
- Advising
- Limiting applications
- Saving programs to profiles
- Signature documents / Identity verification (enabled vs. disabled)
- Journals
- CERs
- Site Registration
- Application tags
- Announcements
- Letter head
- Budget sheets
- Email reminders
- Decision letters
It's also important to document any changes you've made to the text interface. This will be essential to have when upgrading to a new version of the software. Consider using the Document Center ( Website Admin > Document Center) to create your internal documentation.
-Remove test applications
Once you've determined and documented your processes, you should be ready to delete any test applications you may have created along the way. To do this, go to Maintenance > Scrub Applications, noting again that you are only able to scrub applications and not profiles.
Launch steps for SaaS/hosted accounts:
1. Notify your network administrators of the launch date to schedule any needed URL changes with them:
a. In some cases your site will be using a URL that is already in use by an existing website, and the go-live process will include making a CNAME change in your DNS settings. You will need to coordinate with your Network Administrators to make this change on the correct schedule.
b. If the site's URL is an entirely new one, coordinate a redirect of any existing office website links to the new URL at the specified launch time. Decide how long to maintain that redirection and what form it will take. (This is at the discretion of network administrators.)
2. Notify your office staff of the launch date/time. Verify all content development work is complete. Many parts of the site can be hidden from view while under construction, if necessary.
3. Change links on other outside web pages that point to your old website (if necessary). This can be done in stages, where any known, immediately apparent links may be modified first and others changed over time. Be sure to time these changes with the launch, not in advance.
4. (Optional) Make public announcements (in publications, posters, web portals) about the changeover to the new (Terra Dotta software) site, publicizing its features.
5. Launch:
a. Network administrators implement redirects (site level or DNS).
b. Applicants and staff enjoy your new website!
FAQ:
Q: Will changes to the URL be instantaneous for everyone?
A: If your site launch involves DNS changes, there could be a short period of time (between one hour and one day) during which some users will report that they are still being sent to the old site. This is due to the DNS change having to propagate to all the DNS servers. In addition to this, it is possible that some of your site visitors will have the old site cached in their browser, and still be routed to the old site until they click to 'reload' the page. To address both these circumstances, you can put a message on your old site to announce that there is a new site and ask site visitors to clear all caches and/or reload the page if they are having difficulty accessing it.
Q: How do we know if people are accessing the site after launch?
A: The most obvious way is by the visitors generating information requests and program applications. However, you can also track login attempts through Maintenance > Login Attempts.
Q: What are the most common issues that are reported after launching a site?
A: There are two things that are very commonly reported after launching a site:
1.) Users reporting that they cannot login
The following knowledge base articles can be used to help you troubleshoot this:
2.) Recommenders reporting that they didn't receive an email requesting the recommendation. If this is occurring, contact Terra Dotta Support