Remember that after each implementation, before UAT, and then before the Go Live date, clear the org of records used for testing. All the John/Jane Doe, Fester the Tester, and Test12345 must be deleted.
The lifecycle of an org is somewhat similar to the human life cycle. Everything begins with birth. And it ends – well, I probably don’t need to add how it ends. It is worth remembering that to work with Salesforce is to enter this cycle of org and follow its flow:
- Org creation: We already covered this topic at the beginning of this chapter. We create a production org (such an org can be created by Salesforce for a client, or a client can request such an org via the website).
- Modification and development: Changes of this kind are typically made in sandbox-type orgs. There, modifications and improvements are introduced as business needs evolve. These changes do not affect the production environment thanks to a separate sandbox.
- Testing: At this stage, another actor comes into play, and that is QA. This individual conducts tests of all implemented solutions, based on previously created user stories (functionality descriptions).
- Change deployment: Once the changes are approved by QA, it’s time to move them to the production environment. With tools such as Change Sets or third-party solutions, these changes don’t have to be moved manually (that is, reconfiguration in the production environment) but are transferred automatically and seamlessly.
- Org deletion: It’s time to say goodbye (tears might well up). It’s not a common scenario since sandboxes are used for a longer time for solution development. However, sometimes a given sandbox is no longer needed and can be deleted. But it’s crucial to be cautious in such actions because it’s an irreversible process.
To the preceding points, we can add those that will surely raise the level of org management and its quality. After each implementation, documentation is crucial. It’s important to include all changes made to it. This makes it easier to understand which changes were made and why. Another advantage of creating documentation is to pass on the knowledge to another person – imagine you get a new job, and a week before you leave, another administrator arrives; handing over documentation and a brief introduction will be much easier than lengthy meetings.
After introducing changes, besides proper communication, users need to be taught how to use the new functionalities. Training ensures users are aware of the solutions introduced in the last deployment. This training assures the user that it’s a new feature, not a system error or bug.
But remember – there will always be someone who comes to you with questions, and the famous “turn it off and on again” might not work here. So, calmly introduce the new functionality for the 148th time to the user who didn’t get it during the training.
Post-deployment feedback: Once everyone knows how to use the new solution, send them a survey and let them comment on the new functionality. Sometimes, the unique approach of users can outline a different concept of this functionality that we might not have thought of.
I sincerely hope that “org” will not remind you of Shrek but of Salesforce. As you can see, the concept of this architecture is essential to us, those associated with this cloud solution. With knowledge about the lifecycle of an org, you can plan your implementations in the correct sequence. Throughout your career, you will frequently encounter concepts of org, sandboxes, or perhaps multi-tenant structures, but thanks to what you’ve read, you now know what it’s all about. But have you ever heard about PODs? No – we’re not talking about a P.O.D. band here, but something closely related to Salesforce. The next section will explain what we define as a POD.