The adaptability of the Salesforce platform is often a key selling feature for any business user. The ability to change my mind and have the system update accordingly with limited IT cycles is music to their ears. But this music masterpiece quickly turns into a somber tune if the development and administrator teams are not setup for flexible development. Many times organizations try the “one size fits all” approach to handling change requests leading to confusion and frustration.
Never fear there is an alternative! There are ways to allow for flexible development methods. The key is to first distinguish the differences between the types of requests. The table below lists the Six Types of Salesforce Requests:
| Request Type | Definition |
| Third Party Applications | Think of this as any application that is not directly sold by Salesforce. Most of the time this is going to be AppExchange products. |
| Custom Development | This is when we want to create something that doesn’t exist. Think Custom Objects, Visualforce pages, etc. |
| New Salesforce Module | The “I want to buy Service Cloud” request that comes in or any other product that is an off-the-shelf request from Salesforce. Often requires new licenses. |
| Mobile Application Development | The method used when the mobile application is the center of the development. This approach is often used when you are designing for a Force.com user. |
| Maintenance Release | All of the requests to “tweak” items that are already in production (e.g. field values, update approvals process, etc.). |
| Salesforce Seasonal Release | The Spring, Summer and Winter release that Salesforce sends to the user community. |
Now that you have the requests defined, let’s take a look at what the key process distinctions are between them.
Third Party Applications
Most items that you can download from the AppExchange are going to require minimal setup. They are largely “plug-and-play” applications that require limited customization. However, limited customization does not equate to skimping on the Quality Assurance Testing (QAT). Keep in mind that while you may not have to customize, many applications do interact with your standard objects. Doing thorough testing to ensure that the application is producing the desired results will increase your overall development hours scope, but will ensure that you get happy business users.
Custom Development
The key pivotal decision point in scoping Custom Development is can this be Declarative Administration? Anything that is Declarative Administration (i.e. point-and-click configuration) will be a lower maintenance, quicker to market product than the Apex route. So make sure to point out to your requesting user the benefits of going the Custom Object route versus building the next Atlantic City from scratch. Many times it will sway their vote in development, without sacrificing the business process outcome.
New Salesforce Module
When purchasing a net new module from Salesforce (e.g. licenses for Live Agent, Knowledge, Content, Communities, etc.) the biggest hurdle is your business process. Often time development cycles drag out due to process changes or items that weren’t fully vetted ahead of time. Set proper expectations upfront that this process requires that they define a detailed business process and that they have limited changes for the initial roll out. Sometimes reminding users that implementing the least complex v1 is better than building the Matrix.
Mobile Application Development
Keep it simple! When doing something from a mobile device it needs to be clean, simple, and intuitive. If you keep that principle in mind, you will find that several applications can be built using Custom Objects. The ability to turn around a focused application that solves a critical business need in days versus weeks will provide credibility to the development org.
Maintenance Release
Look at setting up monthly maintenance releases to bundle all of the small changes that your organization needs. This will set the expectation with the end users of your cadence and will reduce the amount of change to your end users. Providing monthly release notes and quick training reference guides to the field will keep your business happy and your adoption high.
Salesforce Seasonal Release
Taking the time to read the release notes and educate the business users prior to the release is a critical step. Allow your business users time to evaluate how a new feature could benefit them and how they would like to roll it out. This will allow for a planned feature roll out and minimize any disruption to your adoption.
Final Thoughts – Release Communication
No matter the request, remember that communication is key. Sending out development status reports to key requestors are a good way to let them know that their request is actively being worked. Status reports don’t have to be overly complex in nature. Think of a traffic light. You can list each project and put the status in relation to a traffic light to let them know how you are progressing. If any project is in trouble, coding it red will alert the business and help them focus on getting you what you need.
Looking forward to hearing how you implement the requests types! Happy developing!
About our guest blog post author:
Rachel Rogers says she doesn’t just think outside the box; she lost the box entirely 10 years ago when she started working with Salesforce. Rachel is a Certified Salesforce Administrator, Houston User Group Leader, Creator of the HUG Gives Back Program, Dreamforce Speaker, and three-year Salesforce MVP. Rachel enjoys thinking about ‘what ifs’ and turning them into tangible solutions. Her passion is helping organizations leverage technology and training to enhance their business processes. She is currently the Sr. IT Manager at BMC Software and is oversees their Global Salesforce Roadmap and Release Schedules for the business.