CommunityDevOps ExchangePartners
10 minutes

DevOps Needs for Operations in China: Salesforce on Alibaba Cloud

Written by
David Brooks
Table of contents

In December 2023, Salesforce announced the general availability of Salesforce on Alibaba Cloud. This release culminated a year of work to provide users in China with a native Salesforce sales and service cloud implementation within their borders, in line with the new Cyberspace Authority of China (CAC) requirements.

How do this new service and Chinese requirements impact your Salesforce DevOps practice? This article explores several vital challenges and dives into the processes and updates teams need to address them properly.

Note: This article provides a simplified explanation of the current situation and doesn’t constitute legal advice. If you’re operating in China, please seek legal advice from counsel familiar with the specific laws and regulations that apply to your business. 

Understanding China's New Data Requirements

The gist of the new Cyberspace Authority of China (CAC) requirements is that important data and its subcategory, core data, generated and collected in China must also be stored in China, in line with China’s 2021 Personal Information Protection Law (PIPL).

As an operator in China, you need to demonstrate that your cross-border data transfer controls are in place to ensure that protected data doesn’t leave China.


The regulations don’t restrict data going into China per se. They are also somewhat vague about what constitutes restricted data. Consider this in terms of similar regulations in other countries and industries: Personally Identifying Information (PII) is a great example. Make sure to consult your legal counsel for the latest updates on what is restricted.

Types of Data in Salesforce DevOps

When working with Salesforce DevOps, you’re looking at three types of data:

  • Code
  • Metadata
  • Configuration Records

Code: Apex and Javascript

Apex Code and Javascript are commonly used for automation and integration with other systems. Typically, your company is the one who creates this code, so it’s your intellectual property. You should be careful when using open-source libraries to understand their license requirements and export restrictions.

Metadata: Custom Fields, Security Settings, and Workflows

Metadata is data that describes other data. It often includes timestamps, data creators, data formats, and its structure. In Salesforce, metadata includes configurations that are typically set by admins using point-and-click UI like custom fields, security settings, workflows, etc. 

Applications built on Salesforce combine code and metadata. Both are necessary to define most applications and customizations. They’re often collected into a package that teams can install on Production servers and sandboxes. 

Code and metadata are not part of the data restrictions in the CAC rules since they can’t relate to any individual.

Configuration Records: Rules, Discount Tables, and Approval Levels

Configuration records are different from metadata, but they essentially work like metadata. For applications on Salesforce like CPQ, it’s common to use custom objects to configure important rules like discount tables and approval levels. 

Administrators create and edit these records like they would accounts and contacts in Salesforce. Just like metadata, configuration records apply to the application as a whole and not to any individual customer.

The challenge with configuration records is that they use the same technology as all other data records in Salesforce. To the best of our knowledge, there are no restrictions on this type of configuration data. 

However, you should clearly document these objects to avoid confusion with other restricted data. Again, you should consult legal counsel on the best way to manage and document your DevOps data.

Strategies for Splitting Data for China Operations

Most companies with Salesforce operations in China have been supporting their users from production organizations outside of China. This means their China-related data and customizations are currently commingled with data and configurations from other regions of the world. 

To address the CAC requirements, you’ll now have to procure a Salesforce on AliCloud Production org and move all the China-specific data and metadata there. 

Depending on the extent of your customizations and data volume, this may seem daunting. It’s not a complex task, but it can become time-consuming. 

Steps for a Successful Data Migration

When carrying it out, plan for the following three phases:

  • Before Migration
  • Migration
  • Post Migration

The next sections will provide an overview of what happens in each. This is not a detailed list. Salesforce can provide a detailed Migration Guide when you’re ready.

Phase 1: Preparation Before Migration

Before moving anything, take your time to review all of the customizations in your org and sort all of the Metadata into three buckets:

  • China-specific
  • Common
  • Specific to other regions

Because of the differences in Go To Market (GTM) for various regions, it’s common for multinational companies to create custom schema and processes unique to each region. 

However, you’ll find that most of the schema and processes are common to all regions. These common items must be moved to China as well. Metadata specific to regions outside of China is not needed in China, so you can ignore it.

Label metadata

Salesforce provides a mechanism to annotate metadata; it works like meta-metadata. As you identify each component, you can tag it with one of these three categories. If your company expects to take advantage of Hyperforce and establish additional regional Production orgs, tag the “Other Region” metadata with specific country or region names to facilitate this move in the future.

Labeling your metadata will identify China specific custom fields, but you must also tag entire records. The easiest way to do this is to create a new custom field on each object to identify the region and set the field according to the record. For contacts and accounts, you can likely automate this using a script based on one of the country fields on the record. For others, you may need to tag the record based on a parent record. For example, opportunities, orders, and products that contribute to a China-based account.

The final consideration of moving your solution to China is that Salesforce on AliCloud doesn’t provide 100% of the features you’ll find in other Salesforce orgs. 

For example, CPQ is not yet supported. Marketing Cloud and Commerce Cloud aren’t supported either and will likely be replaced in China by other products. Work with your Salesforce support team to identify unsupported features and products and determine workarounds. 

There’s no need to move unsupported metadata to the AliCloud org, and you may need to update any relationships to this metadata for your workaround.

Phase 2: Executing the Migration

After all the prep work is complete, you’re ready to deploy all the common and China-specific components. All of the custom schema must be in place before any of the data records can be moved.

Be prepared for this process to fail a few times as you find small components and unsupported features that you missed in the preparation. In fact, expect many errors to result from a few key settings that aren’t obvious. One or two settings can generate hundreds of errors, but that can be fixed quickly. The remaining handful of errors will require diligence and patience.

Once the metadata is correct, you’ll deploy the data, and the China org will be ready to operate. 

But don’t rest on your laurels just yet! There are a few more things you need to take care of following the migration.

Phase 3: Post-Migration Clean-Up

Once you’ve migrated all of the China-specific data, you must remove it from your orgs outside of China. You should again consult with legal counsel to understand the specific requirements, including what to do with any backups you may have made along the way.

Once that data is cleaned up, you’ll no longer need the custom metadata that was tagged as China-specific. This includes full records as well as custom fields on common objects. Deleting this custom field metadata will also delete the China-specific data that was stored in it, ensuring that China-specific data is no longer where it shouldn’t be.

Post Migration Considerations

So you have moved all of your China specific Data to China and removed it from the Orgs outside of China. You’re done, right? Unfortunately, not yet. 

Unless your China Salesforce org remains static with no new customizations, you must ensure that your DevOps processes for each region are properly segregated. This is true not only for China but also for other regions.

This task isn’t as burdensome as it sounds. Your teams must ensure that region-specific customizations are managed separately from common core features. 

The best way is to tag your user stories with the region or with a term like “core.” All of your core features should be deployed to all regions, but region-specific changes should be deployed only to that region. It sounds obvious, but you must make sure the processes are in place to enforce this.

Maintaining Compliance with China's Data Regulations

From a data perspective, the easiest way to maintain compliance will be to ensure that new data flows one way into China and that nothing flows out. This may be possible for your business, but most enterprises must include China data in their company-wide reporting and analytics. 

As mentioned above, only a portion of your data is restricted, so you can still export some data for business operations. The key is to know which data restrictions apply. 

Several tools and services are available to help ensure compliance in this regard. You should investigate their capabilities and determine if they fit your company’s needs and budget.

Of course, let me say this one last time: consult with legal counsel to ensure that you comply with your industry's specific requirements.

Future Implications for Multi-Region Salesforce Orgs

This process may sound like a lot of work, and in some ways, it is, but if you are doing business in China, it will pay off in the long run. 

Note that the process described above is not limited to China. Other countries and regions around the world have their own compliance requirements. Business processes tend to be region and country-specific as well, so it’s likely that you’ll have to apply the same procedures to other countries or regions. 

In the past, companies tended to keep all of their users in the same large production organization, increasing complexity over time. While the initial setup of region-specific production orgs requires a bit of effort, maintaining multiple smaller orgs will require less effort in the long term. 

You will also find that multiple production orgs make it easier to support the requirements of the GTM motion for a given region. Trying to handle multiple variations in a single org often imposes limitations, whereas Salesforce has proven that it can handle any process in isolation.

Wrap up

Carrying out a data migration to address the new Cyberspace Authority of China (CAC) requirements doesn’t have to be challenging. As long as you keep in mind all the key steps across each migration phase, you’ll ensure that your Salesforce DevOps effort achieves compliance without impacting your productivity.

Remember that DevOps combines People, Process, and Tools. Make sure that your people are trained and that you have a solid process established for multi-region development. And use specialized, enterprise-capable tooling like Copado to manage all your DevOps requirements in one place.

Book a demo

About The Author


I am serial entrepreneur who has worked at 6 startups with 3 successful exits over the past 34 years in the valley. I joined just after their IPO in 2005 to build AppExchange and ride the rocket ship for the next 8 1/2 years. I ran a third of the teams during my tenure. I joined Jobscience to turn around the product team and within 2 years revived the product line to a successful acquisition by our chief competitor.I joined Copado in August of 2018. Amazing company with a great product and team. We are redefining DevOps for the Salesforce Platform.

Copado and Wipro Team Up to Transform Salesforce DevOps
DevOps Needs for Operations in China: Salesforce on Alibaba Cloud
What is Salesforce Deployment Automation? How to Use Salesforce Automation Tools
Maximizing Copado's Cooperation with Essential Salesforce Instruments
Future Trends in Salesforce DevOps: What Architects Need to Know
From Chaos to Clarity: Managing Salesforce Environment Merges and Consolidations
Enhancing Customer Service with CopadoGPT Technology
What is Efficient Low Code Deployment?
Copado Launches Test Copilot to Deliver AI-powered Rapid Test Creation
Cloud-Native Testing Automation: A Comprehensive Guide
A Guide to Effective Change Management in Salesforce for DevOps Teams
Building a Scalable Governance Framework for Sustainable Value
Copado Launches Copado Explorer to Simplify and Streamline Testing on Salesforce
Exploring Top Cloud Automation Testing Tools
Master Salesforce DevOps with Copado Robotic Testing
Exploratory Testing vs. Automated Testing: Finding the Right Balance
A Guide to Salesforce Source Control
A Guide to DevOps Branching Strategies
Family Time vs. Mobile App Release Days: Can Test Automation Help Us Have Both?
How to Resolve Salesforce Merge Conflicts: A Guide
Copado Expands Beta Access to CopadoGPT for All Customers, Revolutionizing SaaS DevOps with AI
Is Mobile Test Automation Unnecessarily Hard? A Guide to Simplify Mobile Test Automation
From Silos to Streamlined Development: Tarun’s Tale of DevOps Success
Simplified Scaling: 10 Ways to Grow Your Salesforce Development Practice
What is Salesforce Incident Management?
What Is Automated Salesforce Testing? Choosing the Right Automation Tool for Salesforce
Copado Appoints Seasoned Sales Executive Bob Grewal to Chief Revenue Officer
Business Benefits of DevOps: A Guide
Copado Brings Generative AI to Its DevOps Platform to Improve Software Development for Enterprise SaaS
Celebrating 10 Years of Copado: A Decade of DevOps Evolution and Growth
Copado Celebrates 10 Years of DevOps for Enterprise SaaS Solutions
5 Reasons Why Copado = Less Divorces for Developers
What is DevOps? Build a Successful DevOps Ecosystem with Copado’s Best Practices
Scaling App Development While Meeting Security Standards
5 Data Deploy Features You Don’t Want to Miss
Top 5 Reasons I Choose Copado for Salesforce Development
How to Elevate Customer Experiences with Automated Testing
Getting Started With Value Stream Maps
Copado and nCino Partner to Provide Proven DevOps Tools for Financial Institutions
Unlocking Success with Copado: Mission-Critical Tools for Developers
How Automated Testing Enables DevOps Efficiency
How to Keep Salesforce Sandboxes in Sync
How to Switch from Manual to Automated Testing with Robotic Testing
Best Practices to Prevent Merge Conflicts with Copado 1 Platform
Software Bugs: The Three Causes of Programming Errors
How Does Copado Solve Release Readiness Roadblocks?
Why I Choose Copado Robotic Testing for my Test Automation
How to schedule a Function and Job Template in DevOps: A Step-by-Step Guide
Delivering Quality nCino Experiences with Automated Deployments and Testing
Best Practices Matter for Accelerated Salesforce Release Management
Maximize Your Code Quality, Security and performance with Copado Salesforce Code Analyzer
Upgrade Your Test Automation Game: The Benefits of Switching from Selenium to a More Advanced Platform
Three Takeaways From Copa Community Day
Cloud Native Applications: 5 Characteristics to Look for in the Right Tools
Using Salesforce nCino Architecture for Best Testing Results
How To Develop A Salesforce Testing Strategy For Your Enterprise
What Is Multi Cloud: Key Use Cases and Benefits for Enterprise Settings
5 Steps to Building a Salesforce Center of Excellence for Government Agencies
Salesforce UI testing: Benefits to Staying on Top of Updates
Benefits of UI Test Automation and Why You Should Care
Types of Salesforce Testing and When To Use Them
Copado + DataColada: Enabling CI/CD for Developers Across APAC
What is Salesforce API Testing and It Why Should Be Automated
Machine Learning Models: Adapting Data Patterns With Copado For AI Test Automation
Automated Testing Benefits: The Case For As Little Manual Testing As Possible
Beyond Selenium: Low Code Testing To Maximize Speed and Quality
UI Testing Best Practices: From Implementation to Automation
How Agile Test Automation Helps You Develop Better and Faster
Salesforce Test Cases: Knowing When to Test
DevOps Quality Assurance: Major Pitfalls and Challenges
11 Characteristics of Advanced Persistent Threats (APTs) That Set Them Apart
7 Key Compliance Regulations Relating to Data Storage
7 Ways Digital Transformation Consulting Revolutionizes Your Business
6 Top Cloud Security Trends
API Management Best Practices
Applying a Zero Trust Infrastructure in Kubernetes
Building a Data Pipeline Architecture Based on Best Practices Brings the Biggest Rewards
CI/CD Methodology vs. CI/CD Mentality: How to Meet Your Workflow Goals
DevOps to DevSecOps: How to Build Security into the Development Lifecycle
DevSecOps vs Agile: It’s Not Either/Or
How to Create a Digital Transformation Roadmap to Success
Infrastructure As Code: Overcome the Barriers to Effective Network Automation
Leveraging Compliance Automation Tools to Mitigate Risk