When your Lark Base supports a real workflow — a sales pipeline, an inventory tracker, or a project dashboard — making changes to it can feel risky. One wrong tweak to a formula or automation could disrupt how your entire team works.
That is exactly why Lark Base offers the Sandbox feature. It gives you an isolated testing environment that mirrors your live production base, so you can safely test and validate any configuration changes before they go live. Once you have verified everything works, you simply apply the changes to production with a single click.
This guide walks you through exactly how to use the sandbox in Lark Base — from enabling it to applying validated changes — so SMEs and startups can iterate confidently without breaking what already works.
What Is the Sandbox in Lark Base?
The sandbox is a safe, isolated environment that mirrors your production base.
You can think of it as a working copy of the base that contains the same configurations, where you can experiment freely without affecting the live data your team relies on.
Inside the sandbox, you can test:
- Changes to fields and views
- Edits to automations and workflows
- Configuration changes across tables
Once your changes are verified, applying them to production takes one click.
- Platform requirement: The sandbox feature is only available on the Lark desktop app or web version. It is not available on the Lark mobile app.
- Permission requirement: Only users with manage permissions for the base can use the sandbox feature.
Step 1: Enable and Access the Sandbox
Before you start, make sure that Edit history and Time Machine for your base are turned on. These features allow you to roll back to the pre-update version if any errors occur when applying changes to production.
Once that’s confirmed, follow these steps:
1.1 Open the base, click the ⋯ (more) icon in the upper-right corner, and select Sandbox.
1.2 Choose what to copy to the sandbox. You have two options:
- Configurations only — Copies your structure, fields, formulas, and automations without any data
- Configurations and specified records — Copies the structure plus up to the first 1,000 rows of data per table
1.3 Click Create. After the sandbox is created, you will see a “Sandbox created” message. Click Go to Sandbox in the message to enter the sandbox environment.
Tip: Always glance at the green Sandbox banner before making any change. It is easy to forget which environment you are in once you start working — and the banner is your safety net.
Step 2: Test Inside the Sandbox
Once you are inside the sandbox, click the ⋯ icon in the upper-right corner of the base, then select Sandbox > Go to Sandbox to open the sandbox. From here, you can freely test:
- Tables — Add, edit, or delete fields or views in the table. Every configuration change will be recorded in the sandbox.
- Automations and workflows — Add, edit, or delete automations or workflows. Every change is recorded for later review.
Important note about test messages: When you test sending Lark messages in automations or workflows from the sandbox, the message will be sent to the actual automation or workflow configurator — not the recipient or group. When you test sending emails, the email will be sent to the recipient(s). Automation and workflow runs triggered in the sandbox will count toward the total run count.
This means you should be careful with email-based automations during testing, as test emails reach real recipients.
Tip: For email-based automations, set up a test email address (or use your own) in your sandbox before testing, so test runs do not accidentally email your actual customers.
Step 3: View Changes
To track everything you have done in the sandbox, click View Changes at the top of the sandbox to see a complete change set.
Inside the change set, you can:
- Filter changes by module, user, or time
- Hover over the ⋯ icon to the right of any change and click View for more details
- Spot dependencies between changes — when there are dependencies, hover over the View in the Linked items column to see the details
What Are Dependencies?
Some changes rely on others to function correctly. Examples:
- If you add a new field to a table and then group records by that field in a view, the changes in the view depend on the new field.
- If you add a new field to a table and then reference a value from that field in a workflow, the changes to the workflow depend on the new field.
Changes with dependencies must be applied together. This is critical to avoid breaking your base during the apply step.
Click Refresh Changes to refresh the list. For example, if another user updates the sandbox while you are viewing changes, you will need to refresh to see the latest changes.
Tip: Use the filter feature to focus on specific modules or your own changes — especially if multiple admins are testing in the same sandbox.
Step 4: Apply Changes to Production
After completing all configurations and testing in the sandbox, you can apply the changes to your production base.
4.1 Click View Changes at the top of the sandbox, then click Apply in the lower-right corner. The system will validate all changes before applying them, checking for conflicts with production.
- If validation passes, you’ll see a message: “Validation completed. Ready to apply changes.”
- If validation fails, the failed changes will be listed. You will need to fix the errors and validate again. (Refer to Lark’s documentation on common validation errors and solutions if you encounter any.)
4.2 Once validation passes, click Apply in the lower-right corner again. All changes in the sandbox will be applied to production.
Important: Applying changes will directly affect the production base. If the changes fail to be applied, the base will automatically roll back to the pre-update version. All updates made to the production base while changes are being applied will also be rolled back. Apply your changes during off-peak hours when few or no users are using the production base, and verify the results after completion.
4.3 After applying the changes, click View Changes at the top of the sandbox and select Applied Changes to see the changes that have been applied. You can filter by module, user, or time.
Tip: Notify your team in the company chat before applying major changes — especially if it changes how they interact with the base. A short message saves a flood of “is something broken?” questions afterwards.
Step 5: Refresh the Sandbox
If significant differences develop between your sandbox and the live production base — for example, if production has been updated by other users since you started — you can sync the configuration and data from production to the sandbox.
In the base, click the ⋯ icon in the upper-right corner > Sandbox > Refresh.
Select what to copy to the sandbox and click Refresh.
Important: After refreshing, existing changes and data in the sandbox will be overwritten. Make sure you have applied or saved any sandbox changes you need before refreshing.
Step 6: Delete the Sandbox
Once you no longer need the sandbox, you can delete it.
- Click View Changes at the top of the sandbox
- Click Delete Sandbox in the lower-left corner
- Confirm the deletion
Important: All changes and data in the sandbox will be permanently deleted and cannot be recovered. If you need to use the sandbox again later, you can create a new one anytime.
Real-World Examples for SMEs and Startups
Here are practical scenarios where the sandbox is invaluable:
Restructuring a CRM
You want to split your “Customers” table into “Leads” and “Customers.” A change like this affects views, automations, and reports. Test the entire restructure inside the sandbox first to make sure nothing breaks.
Adding a new automation
You want to auto-send a welcome email when a new sign-up is added. Build and test the automation in the sandbox to confirm it triggers correctly. (Just remember: test emails will reach real recipients, so use a controlled test email first.)
Updating a complex formula
A formula that calculates commissions needs adjusting. Test the new logic inside the sandbox using copied records to confirm the numbers come out correctly.
Onboarding a new admin
Use a sandbox to train a new team admin on Base configuration without giving them access to production data or risking accidental edits.
Seasonal or quarterly changes
Preparing for a year-end campaign, financial year reset, or quarterly review? Build the new structure in the sandbox in advance, then apply on the day you are ready to launch.
Pro Tips for Using the Sandbox Effectively
- Always enable Edit history and Time Machine first so you have a fallback if something goes wrong after applying.
- Plan changes before opening the sandbox. A focused sandbox session is faster and produces cleaner change sets.
- Apply changes during off-peak hours. This minimises the impact on your team and reduces the chance of conflicting updates during the apply window.
- Always check dependencies. Changes with dependencies must be applied together — skipping one will break the others.
- Use the View Changes filter regularly. It is the easiest way to keep track of who changed what, especially in shared sandboxes.
- Communicate with your team. A short heads-up before applying major changes saves confusion and builds trust.
Frequently Asked Questions (FAQ)
1. What is the sandbox in Lark Base?
The sandbox is an isolated testing environment that mirrors your production base. It lets you safely test and validate configuration changes — including fields, views, automations, and workflows — without affecting your live data. Once verified, you can apply the changes to production with one click.
2. How do I create a sandbox in Lark Base?
Open your base, click the ⋯ icon in the upper-right corner, and select Sandbox. Choose whether to copy configurations only or configurations with up to 1,000 rows of records per table. Then click Create.
3. Which modules of Base can be tested in the sandbox?
You can test changes to tables (fields and views) and automations or workflows inside the sandbox. Every configuration change is recorded in the sandbox change set for review.
4. Who can use the sandbox feature?
Only users with manage permissions for the base can create and use the sandbox.
5. Will test emails sent from the sandbox reach real recipients?
Yes. When you test sending emails from automations in the sandbox, the email will be sent to the actual recipient(s). For Lark messages, however, test messages are sent only to the automation configurator — not to the recipient or group.
6. What happens if I apply changes and they fail?
If applying changes fails, the base will automatically roll back to the pre-update version. Any updates made to production during the apply attempt will also be rolled back. This is why applying during off-peak hours is recommended.
7. Is the sandbox available on the Lark mobile app?
No. The sandbox feature is only available on the Lark desktop app or web version.
Build Better Bases with Confidence
The sandbox feature is what separates careful, professional Lark Base builders from anxious ones.
With it, you can experiment, refine, and improve your bases without ever putting your live data at risk.
For SMEs and startups whose operations rely on Lark Base every day, this is more than a convenience — it is essential infrastructure for building robust, scalable workflows.
Make it a habit: any non-trivial change goes through the sandbox first. Your team — and your future self — will thank you.
Ready to Power Your Business with Lark?
Lark Base is just one part of an all-in-one platform that brings messaging, meetings, documents, approvals, and automations together for your entire team.
As the Platinum Partner for Lark in Malaysia, Exabytes offers tailored Lark plans, hands-on onboarding, and dedicated local support to help you build, test, and scale your bases with confidence.
