Salesforce Diaries

Over the years, after encountering both successful and painful Salesforce deployments, I’ve seen one approach that has worked well in managing environments and ensuring a successful deployment for the customer. Here are some of my top tips for performing deployments. 1 Build Management Throughout the Project Implementing and maintaining a simple change log, which captures all config and code changes can really help in knowing exactly what has changed in the system. A simple excel file shared on tools such as Google Drive can do this job, with columns such as the following can be used to maintain the change log: Change Name Components Changed Component Type Reason Changed By Change Owner Deployed Date When looking back at the file to understand the reasons of change later, it is much easier to step back and unders

As architects we often find ourselves designing solutions which bring together multiple, sometime disparate systems. These systems support different business functions, and bringing the data from these together can provide a much richer and more holistic view of the business. When considering integrating systems, my experience has taught me the following design principles that one should take into account: 1) Timing Requirements Does data need to be synched in real-time between systems, or can it be performed in a batch operation. When and how quickly do the end business users need access to information and what impact does not having this have on the business. Answering these questions help us decide whether information should be synched in batches or in real-time. 2) Synchronous vs Asynchronous Operations From an integration point of view: Synchronous processing involves initiating and completing a transaction in a single operation. Asynchronous processing involves ini

Salesforce offers a few options to deploy config and code between sandboxes and into production. Most commonly used is the standard inbuilt changeset option, allowing a user to select the exact components they wish to deploy and use the Salesforce interface to manage and perform the deployment. There are times however when changesets can be a little ineffective, especially when needing to select and deploy a large set of components or the need to perform repeated deployments. In these circumstances it may be better to use the Ant Migration Tool to perform the deployment. Steps to using the Ant Migration Tool are listed below: Step 1 - Download the Force.com Migration tool . A direct link to the zip file can be found here . Step 2 - Save the zip file and extract it to a local folder on your hard disk. Step 3 - Navigate to the /samples directory within the zip file. Step 4 - Open the build.properties file and setup your username and password for your source

Having worked in the Salesforce ecosystem since 2009, i felt it was the right time for me to now share my experiences with the Salesforce community. I hope my thoughts and insights can help customers, developers, project managers and others in the Salesforce ecosystem to deliver successful projects and make the best out of what is a truly awesome platform. Over the years I have learnt many lessons in managing, developing and executing projects involving Salesforce and I hope my experiences will provide both interesting reading and some pointers which can be adopted for Salesforce implementations. I will endeavour to write when I have time. Please feel free to engage and provide comments on my posts or things you would like to see me talk about and I will endeavour to do so. I hope this blog can be the start of something cool and useful, and i look forward to mine and your contributions to it.

Some tips and lessons that I have gained from my project experience delivering cloud solutions in the Salesforce platform. 1 - Keep the end goal in mind Information, and more importantly insightful business information that can drive effective decision making is key for any business. I have often seen projects nearing their end, where the business asks - so what can I make of this data. The end business goals should be understood by the full and wider project team, to ensure the solution is being driven towards the end goal. To narrow down on one particular detail - Reporting must never be an after thought but should be defined early on in the project, and the implementation guided to ensure the business will have the data they need. 2 - More than just a use case I have seen many project disputes raised over the finer details of Use Cases when an agile approach has been adopted on a project. It is important that both the business and developers understand that the Use Case rep