In my previous post about being successful in the first 90 days with Salesforce I touched on some key items that any Admin would face. As a follow up to that post I’d like to talk about defining your AppExchange Strategy. What’s an AppExchange Strategy?
It’s easy with small instances or instances that are being championed at the grassroots level of an organization- for an Admin to simply ‘get the apps as fast as they can to solve the problem’. Heck, that’s what I did. If I had a department come to me and wonder if “Salesforce could do that” I would immediately go to the AppExchange and throw a few in a sandbox. And there is nothing wrong with that. But you can easily paint yourself in to corner with that strategy, which is why creating an AppExchange Strategy is key early on.
Let’s build an AppExchange Strategy
1. An AppExchange Strategy starts off by identifying the major departments within an organization that either do use Salesforce or could in the future. So in my case had I done this I would have identified that there were two departments that needed to track conferences in my organization.
2. Identify the AppExchange Apps that the organization could benefit from, or apps that have been requested. So for a new instance of Salesforce looking at functionality that could be needed- like getting emails when delegated tasks are completed. Or having a project management application for a project management department. This step is really all about identifying what is needed and what is wanted for a period of time- a fiscal year, a quarter etc.
3. No surprise here- go to the AppExhange and find relevant apps to download into a Sandbox. Remember to not only look at the app that you need but make sure it doesn’t interfere with any other apps that you already have installed. Most don’t, but it’s always good to check. It’s also important to look for duplicate functionality at this step.
4. Evaluate your choices. You want to look at the apps from an Organizational perspective. So one the criteria will obviously be cost- is it per license, site wide, free, discounted, etc. Next, look at the app in terms of functionality- does it have all you want? In my opinion it should have a lot more than what you want. I say this because you can always hide fields, objects, or permissions to features you don’t need. But if an app is lacking then it will be up to you to rebuild the functionality.
5. Execute and document. Remember before you roll out a new app get your users ready. To do that you will want to message out the change that is coming to the relevant users and when it will be coming. If you are replacing an existing application- like an Access database with a project management app- be sure to have a plan to move the data before you give access to the users.
Why does this matter?
It’s easy as a Salesforce Admin to get excited to deliver new functionality to a user, but we need to keep the organization and our sanity in mind. Hastily installing apps can lead to duplicate functionality, frustrated users, and a frustrated Admin. It can be tough for users to get the right reports- as in my case- when they see two “Conferences” objects to report from. Really it all comes down to keeping our Salesforce instances from becoming bloated with too many department specific apps and delivering apps that have the most value for the entire organization.
If you are rolling out Salesforce and need help with an AppExchange strategy, Training, or Salesforce customization Red Argyle offers a suite of services that will help you delivered tailored Goodness to the Salesforce platform. Contact us today, we would be happy to set up a discovery session and ensure you Salesforce implementation is a successful one.
