Rebranding in large organizations using systems like Salesforce is a much more complex process than it might seem at first glance. It’s not just a change of company name, logo, or interface color scheme, but a broad operation encompassing the technology, business, and communications layers.
In practice, this means analyzing almost every element of the organization’s operations – from code, through integrations, to how it communicates with end users.
The first and most important step is a thorough analysis of all instances where the old company name, domain, visual identity, and associated values appear. In the Salesforce ecosystem, this includes not only system configuration but also:
- metadata,
- Apex classes,
- Lightning components,
- static resources,
- email templates,
- Experience Cloud,
- and all external integrations.
Special scripts or tools are often created to aid in finding dependencies – identifying name usage in records, code, endpoints, and configurations such as Named Credentials, Connected Apps, Auth Providers, Trusted URLs, and CORS settings. Without such analysis, it’s easy to miss elements that will no longer function after a change.
Technological changes and system limitations
One of the biggest challenges during rebranding is that not all elements can be easily changed. In Salesforce, some names – especially those used in APIs or deeply embedded in the system architecture – can be difficult or even impossible to modify without risking disruption to existing processes. This applies, for example, to the names of objects, fields, or integration endpoints used by other systems.
Furthermore, changing a domain (e.g., My Domain) must be coordinated with other systems. A single domain change is impossible – all integrations, external systems, ETL processes, and login mechanisms (e.g., Single Sign-On, including integrations with Entra ID) must be adapted in parallel. Otherwise, communication between systems can be disrupted.
Another common problem is that legacy systems are not fully scalable or do not accept new values (e.g., changes to database names). In such cases, it is necessary to create batches or jobs that update data incrementally or send appropriate messages to external systems to force synchronization.
The importance of the implementation window and testing
Rebranding in systems like Salesforce should be performed within the appropriate implementation window – usually outside of user business hours. This is because changes can temporarily impact system availability, user logins, or the operation of automated processes.
Testing plays a crucial role here. Before production deployment, it’s necessary to prepare a regression environment in which functional, integration, and validation tests will be performed. Testers, business analysts, and end users are often involved to verify the correct operation of
processes. Additionally, after deployment, nightly validations are performed – ensuring that all jobs, batches, and integrations are functioning correctly.
Manual implementation steps should also not be overlooked. In Salesforce, their precise description is absolutely crucial – deployment checklists often include dozens of items, from system configuration changes to updating passwords and logins for ETL processes to manually processing requests or restarting integrations.
User communication and changes
Rebranding involves not only changes to the system but also extensive communication with users. This includes, among other things, informing them about username changes, new login domains, and the need to reactivate accounts (e.g., via activation links sent every few hours). In large organizations, informing teams using integrations is also crucial – this often requires issuing tickets to other systems, which must adjust their configurations.
Visual elements – colors, fonts, and logos – also change, both in the system itself and in Experience Cloud, email templates, and customer communications. This is crucial because rebranding must be consistent both internally and externally.
Impact on business and organizational processes
In some cases, rebranding involves larger organizational changes, such as a company split. This may require decoupling a portion of the Salesforce instance and creating a new environment for the separated business. Such a scenario requires rapid development, data migration, and ensuring business process continuity.
Changes can also impact existing automated processes, integrations, and reporting. Even a minor name change can cause errors in business logic if it was used in conditions, validations, or code.
Post-implementation process and system stabilization
After the rebranding is implemented, the equally important stabilization phase begins. Production errors, user reports, and integration performance are monitored. During this time, IT teams often operate on high alert, quickly responding to emerging issues.
Additional tests and fixes are also created, and any irregularities are logged as bugs or incidents. Updating system documentation and operating procedures is also crucial.
Sii x Salesforce
As a Salesforce partner, we use our expertise and AI-based applications to improve sales, customer service, and productivity in your company.
Salesforce offeringSummary
Rebranding in large organizations using Salesforce is a multifaceted process that spans both technology and business. It requires precise planning, extensive interdependency analysis, and close collaboration across multiple teams. It’s not just a visual change, but a transformation of the entire ecosystem – from code and integration, through business processes, to the end-user experience.
Ultimately, the success of a rebrand depends not only on the correct implementation of changes but also on their stability and user acceptance. In environments as complex as Salesforce, even the smallest detail can matter – therefore, every step of the process must be executed with the utmost precision.
Leave a comment