Salesforce Sandbox Setup Considerations

-

When setting up a Salesforce sandbox environment, it is essential to consider specific factors to ensure adequate testing and development while maintaining data integrity and security.

Here are some key considerations:

Servers and IDs

Each sandbox and production org has a unique org ID. When a sandbox is created or refreshed, Salesforce creates an org, and the org ID changes each time. In places where the org ID is used, such as metadata and text values, Salesforce replaces the old sandbox org ID with a new one.

To find the org ID for the current org, you can go to Setup and search for "Company Information" in the Quick Find box. A hardcoded org ID should be updated with the current ID for the sandbox to ensure that scripts or processes, such as test scripts or Web-to-Lead, work properly.

Salesforce creates sandbox orgs on multiple instances, and when a sandbox is created or refreshed, it is assigned to a specific instance, which can cause sandboxes to appear on different URLs.

When data is copied to a sandbox, the object IDs for records are also copied. However, object IDs do not synchronize between the production org and sandbox, and the sandbox and production org act independently. Any objects created in the production org after the sandbox is created or refreshed will not be synchronized into the sandbox, and the same goes for any new objects created in the sandbox, which will not be synchronized back to the production org.

Users and Contacts

User information is included in a sandbox copy or refresh for all sandbox types.

Please note that all Salesforce usernames must be unique and reference a single org. Therefore, usernames are modified to ensure uniqueness as they are copied. The copy process follows these steps for each username.

Firstly, the sandbox name is appended to the username. This means the username user@acme.com for a sandbox named test will become user@acme.com.test.

If the resulting username is still not unique, a second modification is performed in which some characters and digits are prepended to the modified username. This second modification results in a username such as 00x7Vquser@acme.com.test.

You will log in to the corresponding sandbox when you log in with the modified username. Please note that the copy process doesn't copy Contact data to Developer or Developer Pro sandboxes. Therefore, Customer Portal users aren't copied.

However, the copy process does copy the Customer Portal licenses. You can create Customer Portal users in Developer or Developer Pro sandboxes. 

When you create or refresh a sandbox, user email addresses are modified so that production users don't receive automatically generated email messages from the sandbox. User email addresses are appended with .invalid, which ensures that the system ignores them. 

For example, a user email of awheeler@universalcontainers.com in production becomes awheeler@universalcontainers.com.invalid when migrated to a sandbox. If you want sandbox users to receive automatically generated emails as part of testing, you can correct the email addresses while logging in. 

Please note that return email addresses set in users' Email Settings in production aren't appended with .invalid in the sandbox. When you change a Salesforce user's email address in a sandbox, other ones in Salesforce aren't updated. Delete or invalidate non-user email addresses in sandboxes to avoid sending spam. Change contact email addresses to testers or automated scripts when testing outbound emails.

Each sandbox user’s account email must be verified before that user's account can send an email from Salesforce.

Email Deliverability

By default, new and refreshed sandboxes use the System email-only setting. Sandboxes created before Spring ’13 default to All email.

No access—Allows only password reset emails. It prevents all other outbound emails from being sent to and from users.

System email only—Allows automatically generated emails, such as new user and password reset emails.

All email—Allows all types of outbound email. Default for new orgs that aren’t sandboxes.

The System email-only setting is useful for controlling emails sent from sandboxes so that testing and development work doesn’t send test emails to your users.

For more information Please access Sandbox Setup Considerations


Comments

Post a Comment

Popular posts from this blog

Introduction to Salesforce Agent Script: Build Predictable AI Agents

-
Image
Please visit here for more details - https://ayaninsights.com/guestblogs/introduction-to-agent-script/ In my latest blog, I introduce Salesforce Agent Script and explain how it helps teams build AI agents that are more predictable, controlled, and aligned with business processes. Large language models are flexible, but relying only on natural-language instructions can sometimes produce inconsistent results. Agent Script addresses this challenge by combining the conversational capabilities of an LLM with structured business logic. The blog explains how developers can use conditions, variables, actions, topics, and transitions to control how an Agentforce agent behaves. Agent Script supports familiar logic such as if/else conditions, value comparisons, sequential actions, and checks for missing data. I also cover its core structure, including system settings, configuration, global variables, languages, connections, and topic blocks. The start_agent topic acts as the entry point for each...
Read more

Anti-Patterns in Salesforce Agentforce: What to Avoid When Building AI Agents

-
Image
Salesforce Agentforce is powerful because it allows teams to build AI agents that can understand user intent, retrieve grounded information, execute actions, and support business workflows across Salesforce. But like any powerful platform, the quality of the implementation matters. A good Agentforce implementation does not start with “How many things can the agent do?" It starts with “What problem should the agent solve reliably?” That is where anti-patterns come in. Anti-patterns are common implementation habits that look useful at first but eventually create confusion, poor user experience, inconsistent answers, or hard-to-maintain agents. Below are some of the most common Agentforce anti-patterns and how to avoid them. 1. Trying to Build One Agent That Does Everything One of the biggest mistakes is designing a single agent to handle every business process, every department, and every possible customer question. At first, this feels efficient. One agent, many use cases. Bu...
Read more

MCP vs. Traditional APIs: Choosing the Right Integration Approach

-
Image
Enterprise integration has traditionally been built around APIs. Applications send structured requests, services process them, and predictable responses are returned. This model has supported everything from payment processing and customer portals to mobile applications and large-scale system integrations. The rise of AI agents introduces a different integration challenge. An AI agent does not always follow a fixed sequence designed in advance. It may need to determine which system to use, discover the operations available to it, gather relevant context, and select the appropriate action based on a user’s request. This is where the Model Context Protocol, or MCP, becomes relevant. MCP and traditional APIs are related, but they solve different problems. APIs expose system capabilities. MCP provides a standardized way for AI applications to discover and use those capabilities as tools and contextual resources. Understanding this distinction is important when designing enterprise AI solut...
Read more