DevOps Needs for Operations in China: Salesforce on Alibaba Cloud

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.

‍