This article is also available in:
Sandbox
The sandbox feature will allow you to test any process (the active version as well as different versions of a process) in a simple way and without worrying about who is assigned to the tasks. In addition, this feature was designed not to generate data in the trays or reports that may affect your real data.

The idea is that once a process has been successfully tested using sandbox feature, all that remains is to publish it. Once this is done, the process has correctly entered into the production phase.

How does it work?
To be able to configure the sandbox you only need to complete two simple steps:
1-Go to the "Settings" tab of any of your processes.
2-Once there, you will see a section called "Versions & Sandbox". Enable the sandbox and save the process.

Once this is done, a new tray will be enabled in the left menu and you will be ready to use it.



Points to be aware of:
The Sandbox and process versions work well together, but it is not mandatory to use both features. That is, you can have Sandbox and no Versions or also Versions and no Sandbox. If you have both functionalities enabled you will be able to test versions that are not the the active one, as well as test the active one.

It is not necessary to deploy the process to test it in the sandbox. Just choosing a process to launch, the Sandbox tray will catch the last changes saved in the selected version/process.

Who will be able to see the Sandbox tray?
Users who have Editing permission for a process (i.e. Administrators + those who have explicit permission) will see a new tray just below Finished, called Sandbox. From here they will do everything related to testing processes in Sandbox mode (create new instances, check sandbox, open, complete, etc.).



From the sandbox tray you can check the instances already initiated or launch a test process (master or non-active version). As soon as you press "Accept", the last saved changes of that version will be published to be used by the instance to be initialized. A consequence of this is that existing test instances will be migrated to that version when they are reopened.



Instances that start in the sandbox will always fall into the Sandbox tray of the person testing. Inside the instance, a green sign indicates who will be assigned in real life. In addition, to the right of the instance identifier will appear a red label that tells the user that this is a test instance and not a real one.



Task assignment emails, as well as Message Sending emails (defined in the workflow) are only sent to whoever is testing the instance. In the content of the mail (in the case of a Message Sending mail) it is specified who will be the real recipient of the mail when the process goes into production.

The test instances already finished will be seen in the same view as the active instances, only that they will have a label that will identify them as finished. The same will happen with those tasks paused by timer; they will appear in the inbox with a label.



From the Sandbox tray you can delete test instances by pressing the trash icon. This cancels the instance completely.



You cannot use it in the Sandbox:
Complete tasks by mail.
Send notification mail when there are less than 24 hours left for a task to meet its due date.
The Attachments tab.
Attachment fields will allow you to upload files, but only the name and not the content will be shown.
The Comments tab.
Interaction with external participants.
Print process instances.
Check the history of the process instance.
Reassign tasks.
Highlight instances.
Search for instances.
Configure tasks to start with a timer.

It does work in the sandbox:
Everything that is not defined in the previous point.
Assignment by Web Service, called Web Service, Service tasks.
Scripts.
Documentation.

Be aware that all Service tasks to send/update databases or launch/update process instances will be executed.
Was this article helpful?
Cancel
Thank you!