Salesforce And Software Development Life Cycle
As my first job started back in 2016, that was the first I officially got in touch with “Salesforce”. Ever since then, I am in love with SFDC(Salesforce). Working within the Salesforce environment has taught me a lot too. I use to think that the skills you gained from Salesforce is obsolete, however, I no longer think so. This is the first series where I am going to focus on one of the perspective I learned from SFDC, and how I am using this concept in some other areas as well.
The whole software development life cycle is essential. Last weekend, I participated in the GiveCamp in Pittsburgh, we went through the whole lifecycle of the development over the weekend. “Give Camp is an opportunity for you to use your technical and creative skills to help local non-profit organizations reach their full potential.”(https://pghgivecamp.org/) Sounds really appealing right? I learned a lot through this event, the perspective of helping the others is so satisfying as well.
SDLC short for Software Development Life Cycle, which Salesforce Trailhead has a trail related to this, here is the link. I personally think this is a really important concept. The trailhead model mainly talked about what is safe to deploy to production, what you need to watch out for, and how to build a change set in Salesforce. The whole SDLC is so much more.
SDLC including the following steps:
Planning and defining are the stages when we gather requirements from the users. During our GiveCamp, our users listed out their potential needs and based on what they were telling us, our team gave out some suggestions on what they can do possibly. This is the planning and defining part. Based on the requirements we got, we built user stories on what we got, sometimes the stories can be built on top of each other then combining to be one solution. With a good defined requirements, we can start designing and building. Our team was split into two, half of the team was doing the service cloud side, half of the team was building a solution from FormAssembly to Salesforce, mainly used FormAssembly, Flow, and Process Builder. We tested our solution against couple test cases we have. Then deployed through GearSet. There are so many tools exist for Salesforce that I am not aware of. This is the full cycle of development. This cycle can be applied in every development process as well, even for a big project. A big project is a form of multiple problems combined together. In our case over the weekend, it was a small development cycle but the same process would apply to a bigger project.
For projects, the planning, defining, and designing steps are more critical and it will take longer to complete. We have to have a clear picture about what requirements are and what the user wants. Some of the time, user think they know what they want but what they were telling us is not the best solution. In that case, we will need to analyze their requirements by write the requirements out as user stories and break things up. Only by breaking a big problem into pieces, we can tell what the problem is and provide the best solution we can. The major development cycle is as showed above, there are different ways to achieve it. The following terms may be really familiar to you, Waterfall, Agile, Spiral, etc. Those are different methodologies that you can use to finish your software development life cycle.
During the GiveCamp, Tom guided me through on how to create a flow with process builder. Based on what he taught me, I did a flow on my own last week! Initially I was writing an apex class for that use case, however, apparently with flow, we don’t need to do that any more. The use case I got was, the users want to send out emails when a task is overdue for one day, or the task is overdue for 3 days. There is nothing to trigger this action to happen, so a trigger wouldn’t be a right way to go. Initially my solution was to write an apex controller, and schedule that to run on weekdays, if all conditions are met, then it will send an email to task owner. However, with that solution, if in the future the group I am working for wants to change anything, they will have a hard time, as there are no SFDC Developers on this team. After my exposure to the flow, I am trying to solve this problem with a flow. First, I wrote out the requirements in a fashion of a process flow with boxes and arrows, so that visually, I can tell what the process is and also making sure that I am not missing anything. I used a formula field to calculate the days from task due date, so that the complicated logic on only count weekdays, can be dealt separately from the flow. It is also easier to debug in the future. Then I followed my documentation to create a flow. The major bottleneck I had was on the email part. In the beginning, it was not sending out any emails or it was using the wrong Email template, thanks to the debug function they provide in the flow, it showed me where is the problem and how to solve it. Apparently, when you are using the loop in a flow, you need to loop it back to where it all started in order for a loop to run just as if it is a loop, that’s something really different from coding. The reason why the flow was not picking up the correct Email template is because you have to save and activate the flow every time if you want to run it, and I didn’t activate the flow before I do a test run. In the end, I solved the problems and the flow is running as it suppose to! We are in user testing right now.
Key Takeaway: Getting the story straight is the key to solve a problem, you need to know what problem you are trying to solve here. After you figured out what problem you have on hand, break it down into pieces and solve small problem first, I learned this from the divide-and-conquer algorithms, when you start solving small pieces, the big picture will slowly come together, and eventually you will get your problem resolved. Documentation is the most important thing ever! Doesn’t matter where you are working, what you are doing, always remember to have a solid, good documentation; a good documentation not only is helping the team you are working with, but also it is helping yourself as well.
Last Words: Life is full of the problems, we are solving problems everyday. Same techniques can be applied in life as well.