Managing Salesforce Applications - Six Points

Like any other software solution, Salesforce.com based solutions are also subject to Application Management (AM) services. Once deployed, AM services are enabled to support the application users and to improve user experience continuously. But for Salesforce.com, being 100% public cloud and SaaS based service model, the pertaining AM services differ from traditional application support offerings.

Salesforce based applications/solutions are deployed as part of the larger enterprise ecosystem and in most of the cases, the application management model for Salesforce apps are defined as part of the enterprise wide support model. This means that the 'difference' in services are to be enabled within a generic model applicable to the enterprise. This is one of the key challenge while putting together a consistent and sustainable AM service model for Salesforce ecosystem.


Salesforce Success Plan
Every Salesforce client has subscription to Salesforce Success Plan - either Standard or Premier, based on the subscription type. Salesforce Success Plan refers to the product related support, developer support, admin assist, guidance, expert advice, accelerators, training as provided by Salesforce for its customers. This essentially means that any AM service model must complement services offered by Salesforce Success Plan. 

Few key questions to answer in this context include:

• Which success plan is activated for the given enterprise?
• Does the enterprise need an AM service model on top of the subscribed success plan (Possible, even if it's bit ambitious)?
• Which stakeholders have access to the Salesforce support/ helpdesk (make sure that they are trained & aware of services provided through Salesforce support)?
• Is there a consistent process defined to assess and identify when to leverage Salesforce support (should be part of the AM service model)?
• Does the success plan have any impact on the process flows like incident management, problem management, change management etc.?

Focus is beyond 'Keeping the Lights On'

Keeping the lights on is not a concern - thanks to Salesforce.com reliable & scalable architecture and cloud based infrastructure. In Salesforce world, there is no server management, server monitoring, load balancing & scaling, performance monitoring, patch deployment activities. Salesforce manages all the relevant infrastructures and responsible for related services like capacity management, backup management, business continuation & disaster recovery, compliance to security standards etc. Salesforce also makes three releases/updates per year and all related overheads are taken care of by Salesforce. While defining the Salesforce AM model, it's important to understand these out of scope services for Salesforce ecosystem.


Routine activities exist, but with different flavor
Some of the routine activities from traditional application support model are still applicable, but with different perspective and bit more automation. For example, many enterprises perform manual/automated data and metadata backup activity. This backup activity is in addition to backup performed by Salesforce. This is useful as restoration from Salesforce backup may involve additional fees.

Similarly some of the monitoring activities are still applicable. For example, periodic analysis of login history, event log files are highly recommended. Events include login, logout, API, ApexExecution, LightningPageView, LightningPerformance and so on. This analysis helps to detect abnormal access events, monitor intentional/unintentional data loss, increase adoption, and optimize application performance. If needed, Salesforce Shield services (additional fees) enables more features and flexibility in this regard.

While server management, capacity management etc. are not applicable anymore, license usage monitoring and optimization is key to make the best of Salesforce.com subscriptions. Different organization/environment specific limits are needed to be monitored (email notifications are available) to ensure optimized & continuous business experience. Let's take benefit of Cloud Computing.

Software upgrade, patch deployment are replaced with three releases a year by Salesforce. Salesforce owns all relevant overheads and these updates are superbly stable - all your custom codes and configurations are supported. But some due diligence are recommended in this context - e.g. reviewing release readiness for the given ecosystem, release preview, post release sanity testing etc.

Service requests are applicable for Salesforce AM model too. In fact, there are scenarios where service requests cover lions-share of the AM scope as compared to incidents. Salesforce service requests primarily refer to the administrative activities which are not resulted from any production incident. Example of such activities include: adhoc data import for business group, adhoc/periodic communication of reports/dashboards to business user/group, addressing reporting needs and so on.


Revisit Service Levels and Processes with Salesforce context
With Salesforce.com solutions, the standard service definitions and service level agreements may need to be adjusted. This will depend on several factors including the application architecture, degree of best practices adoption and customization quotient in implementation landscape. Point-and-click implementation (configurations) capability means that a lot can be achieved without any code change. This implies that Level 2 and Level 3 service definitions for Salesforce applications can be re-calibrated and service level agreements (resolution times) for Salesforce components can be re-defined.

Most of the ITIL processes are relevant in Salesforce world. Its recommended that these relevant processes are revisited to validate consistency in context of Salesforce specific differentiators. Strategy function processes, Security management, Demand management, Service catalogue management, Transition function processes, Operation function processes like service desk, incident management, event management, request fulfillment, problem management, access management etc. processes are recommended to be consistent and tailored to Salesforce applications.


New focus areas, plan for the same
While Salesforce AM model eliminates many traditional application management concepts and support activities, this also introduces few new ones. Its recommended to take these into consideration while rolling out the AM model. Focus areas or services include:

• Salesforce introduces new & revamped features and innovations thrice a year. How to take this opportunity to refresh applicable business processes with latest technical advancement through Salesforce platform?
• How to ensure the ever-going evolution in Salesforce ecosystem is consistent and compliant to the respective enterprise standards?
• With ever increasing enterprise capabilities and growing number of business users on Salesforce platform (mostly in single production org), how to ensure environment sanity and compliance to security requirements?
• Measures/activities are to be undertaken in context of Salesforce releases - release readiness, release preview, change management etc.
• Salesforce AM model does not only support specific application(s), but also enables support & management of the entire Salesforce ecosystem. This means set of additional activities like org. level configuration tasks, sandbox management, license management, access management, data visibility between different applications and so on.
• The given AM model should periodically review optimization opportunities and best practice adoption (e.g. optimizer tool, audit exercise) to improve the overall experience with Salesforce.

Diverse skill set and Team organization

Last but not the least. Team organization is one of the most critical aspect in delivering AM services effectively. Having right mix of expertise with a lean team to support already deployed solutions as well as capabilities required to realized future business architecture is the objective.

Salesforce ecosystem landscape is quite vast; this includes platform offerings (like Sales cloud, Service cloud), acquired offerings which are and to be integrated with the unified platform (like Marketing cloud, Commerce cloud), industry specific offerings (like Health cloud), and partner ecosystem offerings through AppExchange (like Vlocity, Veeva). The first consideration in defining AM team structure is which components are deployed in a given solution or enterprise. For example, same consultant/ team can realistically support solution built around Sales cloud, Service cloud and App cloud. But Marketing cloud, Commerce cloud, Analytics cloud will need specialist in respective components.

Next consideration is around type of implementation - Point-and-click solution, Apex customization solution, Lightning customization solution, Hybrid (configuration+customization, most common) solution. While many (not all) Salesforce consultants have expertise in both configuration and customization areas, dedicated Administrator(s) and Lightning specialists can be considered based on services in scope.


Final Word
Its easy (and common) to generalize Salesforce application management services. Many try to realize Salesforce.com AM services with traditional application support model without factoring in the differences. But its important (for both clients/enterprises and service providers) to put together Salesforce AM model which functions on top of the enterprise level support model, achieves enterprise level KPI and SLA, and addresses Salesforce.com specific problem areas with right solutions as well.