Advance Sandbox

A Sandbox is a secluded space within the Quixy platform which is called the development stage where users can unleash their creativity without the fear of disrupting existing workflows or applications. It serves as a virtual playground, enabling citizen developers to build, modify, and test applications or features without any impact on the live environment.

In the advance sandbox, we have four stages i.e., Dev (development), QA (Quality Testing), UAT (User Acceptance Testing) and Production (Live). All users, i.e., Organization Admin, Workspace Admin, and End-Users will have access to the live environments.

• Development (Dev): Your creative haven! Develop and automate solutions with confidence. 
• Quality Assurance (QA): Test your creations with dummy data, ensuring they stand up to scrutiny. 
• User Acceptance Testing (UAT): Real users, real data. Let the real users (End-users) test your solutions in an environment that mimics the live stage. 
• Live: The grand stage! Roll out your solutions for actual usage, real transactions, and live interactions.

While the organization admin will have access to all the four stages and can easily switch between the stages as required. The workspace admin will have access to the Dev stage and Live stage by default; access to QA and UAT stages depends on whether the workspace admin has permissions to access QA or UAT for testing purposes. If the workspace admin do not have permission to test artifacts or solutions in QA or UAT, either, they can ask for permissions or test the artifacts in the Dev stage itself. Either way, workspace admins can always test their creations.

End-users (non-citizen developers) will have access to Live stage by default to make real-time transactions and interactions. However, if they are given with the permission to access QA or UAT for testing, the end-users can become testers to test the created or modified artifacts or solutions.

How does Advanced Sandbox works?

The below image represents the working model of the Advanced sandbox. Please zoom in to the below image for clarity.

• Any user login into the platform will land on the live environment as shown in the GIF Below.
• The Organization Admin or Workspace Admin must switch to the Dev environment to start developing the solution that requires creating artifacts.

• Now, in the Dev stage, creating artifacts is same as old times.
• Go to Admin Menu, create workspaces, roles, users, applications, data tables, data sources, reports, and establish app-data table relations, etc. Configuring the account Preferences, and other aspects in different stages is explained later in the article.
• Once the artifact creation part is complete, respective citizen developer can test the artifacts or solution in the Dev environment itself to understand their functioning credibility before deploying it to the QA stage for actual testing. 

• In Sandbox, since all the artifacts doesn't move to the Production (Live) stage instantly after creating them, they get parked in a space called Branches till the solution/artifact is deployed to the next stage, i.e., QA or UAT for testing or Live for real-time usage.
• Branches hold all the newly created artifacts and modifications made to any existing artifacts till published to the next stage. In other words, we can say that branches will hold the artifacts and can be called artifacts summary page.
• Advanced Sandbox gets a default General branch where all the newly created or modified artifacts gets parked.
• You can navigate to the General branch from any respective artifact's list page such as Apps, Data tables, Data sources, DS-Reports, DS-References, DS-Views, App Events, Lookups, Dashboards, Custom Menu, Preferences, Workspaces, Users, etc to deploy the created or modified artifacts.
• For example, navigate to the Manage Apps page or Data table list page; in the top right corner to the left of the Profile Picture, you will find the option to navigate to the General branch.

• In Advance Sandbox, citizen developers (Organization Admin or Workspace Admin) can create their own branches in addition to the General Branch to park their artifact creations or modifications. Learn more about branches...  

• Once the artifacts are moved to QA stage, the citizen developer who created the artifacts or solution can test it all by himself/herself or even ask peer developers to test the artifacts or solution to understand their functioning credibility before deploying the artifacts or solution to the UAT stage.

• Now in UAT stage, either citizen developer or an end-user with access to UAT stage can test the artifacts or solutions.

• Once the artifacts are tested and refined in QA and UAT, the artifacts or solution can be deployed to Live stage for real-time usage. 

• In Live stage, end-users can use the artifacts or solutions to perform real-time transactions or interactions. 

Managing Artifact Dependencies for Deployment

At Quixy, we collaborate and link diverse types of artifacts to create a functional solution. These artifacts are interconnected and depend on one another to achieve specific functionalities.

As the sandbox necessitates the deployment of artifacts to the next stage after their creation or modification, it's crucial to deploy related artifacts either simultaneously or ensure that the parent artifact is deployed first, followed by the dependent (child) artifact.

In the event of a discrepancy during artifact deployment—attempting to deploy a dependent (child) artifact to the next stage before deploying the parent artifact—the platform will present an error dialogue box, indicating a dependency issue. This error notification not only alerts about the problem but also furnishes information on the artifact dependency within the dialogue box. This ensures awareness and prompts users to proceed with deploying or publishing the dependent artifact before deploying or publishing the actual artifact.

The following examples illustrate how the artifact dependency mechanism operates:

1. When attempting to deploy an App, the system will verify the availability of the workspace in the next stage. If the workspace is not available, the system will generate an error message prompting the deployment of the workspace.
2. In the case of deploying an App (with Look ups), the system will examine the availability of look-ups in the next stage. If the look-ups are not present, the system will issue an error message, necessitating the deployment of look-ups.
3. For the deployment of an App event (Data function), the system will validate the availability of both the App and the data table in the next stage. If either is unavailable, the system will prompt an error, urging the deployment of both the App and the data table.
4. When deploying a Report, the system will check for the availability of the data source in the next stage. Should the data source be absent, the system will generate an error message, indicating the need to deploy the data source.
5. In the deployment of a List Screen (with App and Report used in Data action), the system will verify the availability of both the App and the Report in the next stage. If either is not available, the system will display an error message, signaling the necessity to deploy both the App and the Report.

Managing Account Preferences in Sandbox

When adjusting account preferences, three specific preferences necessitate either configuring the environment or deploying to the live environment.

1. Notifications

When configuring notification preferences, you are required to specify the environment for which you intend to enable or disable notifications.

2. Payments Gateway

Configured payments gateway requires deploying/publishing from the General branch.

3. Themes

Configured organization Themes requires deploying/publishing from the General branch.

Data Administration in Sandbox

Sandbox has made managing data a lot better. Now, we've got a more private and secure way to handle the data with help of Data Admin. The new Data Admin role has changed things for the better. Learn more about Data Admin role here...