What is the Self-Service Sandbox?

A sandbox system is a test environment which is a copy of your productive Meisterplan system. It allows you to securely try out new features and configurations in a closed environment without affecting your current system or data. You can also use the sandbox system to train new users and expand the use of Meisterplan within your organization with no repercussions on your productive system.

Prerequisites

To see the the Self-Service Sandbox tile under Manage, your need to have the user right Manage Self-Service Sandbox.

To configure the user right, go to Manage > User Groups, and under Administrative Rights, check the box for Manage Self-Service Sandbox.

Managing the Sandbox

Creating a Sandbox

By creating a sandbox, your productive system is copied. This includes every user, their rights, current projects and custom views. For the few exceptions, see the following section on differences between your sandbox and your productive system.

The creation of a sandbox can take up to ten minutes. You can only have one sandbox at a time. While you are creating a sandbox, you can still work in your productive Meisterplan system.

To create a sandbox, click Manage in the left sidebar and select Self-Service Sandbox. Next, click Add Sandbox.

Accessing a Sandbox

Your username and password are the exact same for your sandbox and your productive system. If you update your password on the active system, your password will remain unchanged on the sandbox until you either update or delete your sandbox and create a new one.

You can access your sandbox by following the link found under Manage > Self-Service Sandbox. This is the simplest way to share your sandbox. The login to your sandbox can also be found under the same URL you normally use to login, followed by -sandbox (e.g., us.meisterplan.com/mysystem-sandbox).

Updating a Sandbox

Updating a sandbox overwrites the data in your current sandbox with the information from your productive Meisterplan. When updating a sandbox, the only information that will remain is the SAML configuration, or if a user has verified their email on the sandbox system. Otherwise, all sandbox data is deleted. There is no way to recover it.

If a user is in a sandbox while it is being updated, they will be kicked out of the sandbox.

To update a sandbox, go to Manage Sandbox > Update Sandbox > Update.

Deleting a Sandbox

Deleting a sandbox completely deletes all sandbox data. There is no way to recover it.

To delete a sandbox, click Delete Sandbox > Manage Sandbox > Delete.

Differences between the Sandbox and Your Productive System

View: The Self-Service Sandbox is clearly denoted by a red sign next to the word Sandbox the entire time you are in your sandbox. This way, you can be sure that you are working within your sandbox, and not on your productive system.

Email Verification and Notifications: By default, users will not receive email notifications from a sandbox. All emails in a sandbox are automatically unverified. If users verify their email address within a sandbox, they will then receive email notifications. You can then toggle off these notifications by going to My Profile > Notifications. These settings will be saved if the sandbox is updated.
Change Log: The last 10,000 entries of the Change Log are copied to a sandbox system.
Comments: The existing Comments from your productive system are not copied to a sandbox system, but you can add new comments within the sandbox.
Sandbox within a Sandbox: The only feature which does not exist with the sandbox functionality is a sandbox itself. Therefore you cannot create a sandbox within your sandbox.
API Tokens: API Tokens are system dependent, and thus must be newly generated if you want to use them in a sandbox system, either for the REST or Reporting API.
SAML SSO: For security reasons, SAML configurations will be reset (i.e., disabled) when creating a sandbox. However, SAML can be configured on the sandbox if required.

Articles in this section