https://www.associatesinneurology.com/associates-in-neurology-sleep-lab-in-valparaiso-receives-program-accreditation/. VALPARAISO, IN – September 17, 2012 – Associates in Neurology Sleep Lab in Valparaiso recently received program accreditation from the American Academy of Sleep Medicine (AASM). “The American Academy of Sleep Medicine congratulates Associates in Neurology Sleep Lab on fulfilling the high standards required for receiving accreditation as a sleep disorders center,” said Dr. Sam Fleishman, AASM president.
One of the major issues using Salesforce crm for enterprise users is the lack of a roll back when doing releases to production org using Salesforce. This always turns out to be a high risk if there is any major issue involving current release which can make the salesforce org unusable for a period of time. So here are somethings you can do to to create a roll back plan in salesforce.
1. Identify and categorize the components for the release.
List the components of your salesforce release and categorize them as follows
Code – Apex classes, visual force pages, triggers
Config – Custom objects, fields, workflows, page layouts etc which ever is done by clicks
Manual – Any changes you have to do manual like record types, role changes, stages etc . These are components which are not supported by the meta data api and have to be done manually on each org.
2. Use source control and tags for the code components for roll back
Using source control tools like subversion, Github etc for code components and have them updated daily by your developers. For any release, developers can use the inbuilt tag mechanisms to tag the release and only move those components for that release to production. Ant builds deployments will really help out in this easily. If you are using changesets, atleast have the developers commit to source control and use tags for release. In the case of a production issue, developers can easily checkout the previous release code components from source control and deploy them to production which can be a quick rollback plan.
3. Commit Configuration changes to Source control tool.
Since salesforce stores all the configuration data in xml format, all the configuration changes can easily be stored in the source control tool and tagged for production release. If there is a problem in production, you can easily checkout the previous release configuration components and move them to production for a quick rollback plan. If you do not know how to use source control tool, tools like snap shot can easily help in this regard.
4. Document and store Manual changes in source control tool
For those changes which have to be done manually, create a document with screen shots on all the manual changes and have them stored in a common directory or source control tool. During a production crisis, you can easily review the current document and undo all the current manual changes and look at the previous release document and apply the previous release changes which would bring back your salesforce instance to the original state.
5. Identify data impact and have a rollback script for data
There might be some data modified because of the new release like new leads, contacts or opportunities modified or data imports done to support new changes. Create a rollback apex class which can delete the new data or update the modified data to the old state would help to restore the data impact changes.
So using the above 5 steps, a roll back plan can be created in salesforce and implemented during production issues. Please feel free to email me at firstname.lastname@example.org on any questions and I can share with you a template which you can use for your rollbacks.