On rare occasions, you may need to update your Slate subdomain. This happens most often upon initial set-up where you are using a temporary subdomain (e.g., slatetemp.uni.edu -> apply.uni.edu) or when you begin incorporating additional populations into Slate and need a more generic subdomain (e.g., apply.uni.edu -> engage.uni.edu). Several different parties are involved in this change, and it's essential to coordinate with them to ensure seamless operations. Below are the specific groups and their responsibilities:
- IT Staff/Network Administrators - Set-up DNS entries and update Single Sign-on settings.
- Web/Marketing - Update various links throughout the institution websites.
- Third-party Payment Providers - Update URLs for postbacks and checkout.
- Technolutions - Update SSL certificates and other domain settings.
Changeover Steps
- Determine a new subdomain name.
- Have your IT group create a new DNS entry for the new subdomain. It should point to the CNAME of cluster.technolutions.net. You can use an external tool such as https://www.digwebinterface.com/ to confirm this DNS entry is in place.
- Notify the following three groups of the new subdomain and the planned changes:
- IT/Network Administrators to update the Single Sign-on settings, specifically new hostnames for metadata, login, logout, validate, and other URLs. In addition, you will use the new subdomain for the entity ID.
- Third-party Payment Providers, if not using Slate Payments, to notify them of new hostnames for postback, checkout, and other URLs.
- Web/Marketing to update links on your institutional sites to use the new subdomain.
- Submit a request to the Domain and SSO Configuration category with the following information:
-
- The new subdomain
- The intended launch date for the new subdomain
- Technolutions respond to confirm the details and begin the changeover process.
-
- Once the new domain is up, you can reach out to the groups from step three and let them know to make the appropriate updates. NOTE: The existing subdomain will remain active until the SSL certificate expires (typically about a month after the change). This is designed to ensure that existing links will not immediately expire and give your various campus colleagues time to make the abovementioned changes.