You can provision a test environment to try out new features, gain hands-on experience with your database, and troubleshoot in a controlled setting before making the leap to your production environment.

What’s in a test environment

The test environment is an exact copy of your production environment at the time it was provisioned.

You can request a refresh of your test environment to grab the latest version of your production environment.

When you’re in a test environment, this banner appears at the top of every page:

Accessing your test environment

In a production environment, you can access your test environment in Database → Test & Other Environments.

If you have a test environment available, you can select Launch Environment to open it.

If you don’t have a test environment available, you can provision one.

Provisioning or refreshing a test environment

To provision (make new) or refresh (bring up to speed with production) a test environment:

1. Select Provision, or refresh the test environment by selecting the arrow, then Request Refresh.

2. Add a Memo if desired. The memo appears to users when they request a refresh of the environment. Use it to provide the user with details of the environment’s intended use.
   

3. Select Provision/Refresh. A confirmation pop-up appears.

4. Enter the required text into the confirmation pop-up and select OK.

📝 Note: Provisioning or refreshing a test environment may take up to three hours.

To access your test environment:

• Select the Endpoint URL, or

• Select Launch Test Environment

Differences between test and production environments

Slate prioritizes computational resources of production environments over test environments across all databases. Thus, the following features exhibit limited or no functionality in test environments:

Importing and exporting data

• 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. Force Process Pickup will not pull data from a web service in a Slate Test Environment.

• 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 and automation

• 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.

Communications

• 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.

  ⭐ Best Practice

  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.

• Support Desk Tickets cannot be submitted through non-Production environments.

Links

Links in items like mailings, portals, or record dashboards won't automatically redirect to the link in the test environment. For example, in a test environment, the URL in an internal form on a dashboard to another form leads to the version of that form in production, not to the version in test.

Check URLs when using public-facing Slate pages to ensure you are in the expected environment.

User accounts and permissions in test environments

Generally, users enter a test environment through their production environment. The user needs to have an account in production to access a test environment.

After an initial authentication, all user accounts and permissions are controlled through the test environment. This lets you test new and updated permissions on a user-by-user basis before implementing them in production.

This also means, 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 user with the Security Administrator role is required to configure the accounts.

📖  Further reading: User accounts, Security administrator

Learning Lab test environments

See Learning Lab Courses for more information about Learning Lab test environments.

Requesting additional test environments

To learn more about additional test environments, reach out to your lifecycle team:

• 🪪 Admissions: [email protected]

• 🎓 Student Success: [email protected]

• 🤝 Advancement: [email protected]