Slate offers the ability to perform self-service provisioning of a useful test environment.
Test environments can be provisioned through the Launch Test Environment link in the Database. To request a refresh of a test environment, select the Request Refresh button on the Launch Test Environment page.
Tip! If your institution has purchased additional test environments, you will see these environments listed here as well. When provisioning or refreshing, make sure you're selecting the right environment before proceeding. If you would like to learn more about additional test environments, please send an email to email@example.com.
Terms and Conditions
The following terms and conditions apply to test environments:
- A maximum of one test environment, one Time Warp environment, and one Clean Slate environment may be provisioned per database. Additional test environment slots are available for an added cost. To inquire further, please send an email to firstname.lastname@example.org.
- A recent backup copy of the production database is used to create the test environment with a new, standalone database on the test server. All configuration and text data are copied from the production database. However, the test environment only inherits links to documents (PDFs) and digital media in the production database, rather than receiving full copies. Therefore, do not make changes to digital portfolios or video essays/interviews for real students while in the test environment, as this may have unintended consequences.
- The test environment exists temporarily, and it remains active only if it has been actively used within the past 30 days. Once it has expired, the test environment is no longer accessible and will need to be provisioned again.
- At the time the test environment is provisioned, it is an exact replica of the production environment with respect to any configuration settings.
- When requesting a change through the Service Desk, indicate the intent for that change to be made in either the production environment or the test environment. Without this indication, Technolutions support staff will assume that the change is to be made in the production environment.
- Test environments are intended for client use only. While Technolutions support staff may occasionally make changes to this environment, we cannot accommodate a scenario where our efforts must be duplicated by making changes to two separate databases. Support for test environments is limited since these environments are intended for client experimentation only.
- Databases for test environments are not backed up. Data deleted from the test environment cannot be restored.
- There are no uptime or service guarantees associated with the test environments. While Technolutions support staff strives to keep these environments online, we do not provide the level of redundancy included with the production environments.
- Once a test environment has been terminated, it cannot be restored. You will be able to provision a new test environment at that point.
- Emails and text messages are generated within the test environment, but they are not sent. Messages may be viewed through the timeline on a given record.
Differences in Behavior Between Test and Production Environments
Some tools run differently, or do not run, in test environments. To complete processes as efficiently as possible, Slate prioritizes computational resources across all databases for production environments. Thus, the following features exhibit limited or no functionality in test environments:
- Incoming imports (as with the CommonApp) will import only to production and not test environments.
- Material uploads for automated imports (Common App, Coalition, EAB/Royall, UCA, Gateway to Prep) are not processed in Test.
- Scheduled exports do not run in Test.
- Source Formats do not automatically import in Test, and files placed under the Test SFTP are not automatically processed. Run the "Force Process Pickup" tool in Database to pick up and associate files with the source format, then run the "Force Process Import" tool.
- Validation of Allowed Networks for user IDs is run against the production instance. Even in a test environment, the production environment ID must include all IPs that you may be using to connect.
- Rules generally do not run as quickly in test environments, and overnight processing rules are completely deprecated in Test.
- Origin source and group overnight calculations do not run in test environments.
- Cleanup scripts, like address scrubbing, do not run overnight in Test. Addresses can be scrubbed in a database (both Production and Test) on-demand using the "Scrub Address Records" tool in the Database. Duplicate Reference IDs and test scores are also not automatically cleaned, as well as auto-generated test score checklist items if the "Add to Checklist" setting on the test score is flipped from Yes to No.
- The Slate Template Library and Configurable Joins Library are not automatically refreshed in Test.
- Retention Policies do not automatically run in Test.
- Mailings and texts will, in places like the timeline, appear to have been sent in test environments, but they will not actually send. Additionally, you cannot set up Deliver accounts via the Deliver Configuration page in Test. For example: Inbox text phone numbers are not available to Test.
Use the production environment when testing scheduled mailings or testing the look and feel of a given mailing in different email clients. Test environments may present inconsistent behavior in the sending of ongoing mailings.
- Time-based event and form communications (such as an hours before event communication) may not send at the expected time in Test.
- Slate.org application sharing does not occur in Test.
- Service Desk Requests cannot be submitted through non-Production environments.
User Accounts and Permissions
Generally, a user will log into a test environment through production. As such, the user will need an account in production to access a test environment. After the initial authentication, all user accounts and permissions are controlled through the test environment. This allows you to test new and updated permissions on a user-by-user basis before implementing them in production. This also means that if your user was created in production after the last test environment refresh, you'll either need to manually create the account in test or refresh the test environment before the user has access. In all cases, a Security Administrator is required to configure the accounts.
Tips for working in Test
Since your test environment is an exact copy of your Production environment, remember that any Production links present in items like mailings, portals, or record dashboards won't automatically redirect to the link in Test. For example, if you've hyperlinked a form on a dashboard and that link is to a form in Production, the link in Test will lead you back to the form in Production. We recommend checking URLs as you navigate through public-facing Slate pages to ensure you are in the expected environment.