Step up during these hard times

I hope you and your family members are doing well.

During these times of uncertainty and with lot of time in hand, it is important we channelize our time in the right direction so that it helps us to build a vibrant carrier ahead. This is a great opportunity for all of us to sit back, assess and improve our skill sets.

On this regard, here are the top 5 recommendations from my side for the people who are part of Salesforce ecosystem to constantly enhance your knowledge.

1. Salesforce Newsletters & Blogs: Please follow the below links regularly. Apart from frequent updates on Salesforce products and technologies, there is lot of information on how companies are solving the customer problems innovatively during this tough times. These blogs also has great details on how to manage our customer and ourselves better during this pandemic.
• https://www.salesforce.com/form/other/blog-newsletter/?d=701300000021JgNAAU
• https://www.salesforce.com/blog/

2. Learn client side scripting and JavaScript ES 6 concepts: Lightning is all about JavaScript. A developer with a great JavaScript knowledge can become a champion lightning developer.
• https://trailhead.salesforce.com/users/preddy66/trailmixes/client-side-programming-using-java-script – Trailmix created to help learn advanced JS
• https://www.w3schools.com/js/js_es6.asp – ES 6 concepts

3. AURA Lightning/LWC: There is a huge gap of resources with a very good AURA/LWC skill sets in the market. This is a right time for us to catch up on and improve these skills.
a. https://trailhead.salesforce.com/users/preddy66/trailmixes/aura-lightning-components – AURA
b. https://trailhead.salesforce.com/users/preddy66/trailmixes/lightning-web-components – LWC

4. Certifications: This is also a great time to add few more certifications under your belt to endorse your authority on the specific areas of Salesforce.
• https://www.cio.com/article/3188348/7-salesforce-certifications-that-will-advance-your-career.html – This link provides a guide to certifications
• https://trailhead.salesforce.com/credentials/administratoroverview – all the certifications offered by Salesforce are available in this link

5. NextGen Technologies: Salesforce is catching up on the next gen technologies big time and it is important for us to keep up to date on these developments. Salesforce has inducted Block chain, Einstein, Salesforce DX, IoT, Evergreen, LWC open source etc.. into their platform. These technologies would be used extensively in the coming days and would redefine the way we solve our customer problems in the future.
• https://trailhead.salesforce.com/users/strailhead/trailmixes/dreamforce-19-developer-keynote-trailmix
• https://trailhead.salesforce.com/en/content/learn/modules/iot_basics
• https://trailhead.salesforce.com/en/content/learn/projects/quick-start-salesforce-dx

Happy learning & be safe!!

— Prashanth —

 

Salesforce: Classic to Lightning Experience Migration

It has been four releases since Lightning experience was first launched by Salesforce. We could see gaps being closed release after release. Lightning experience is maturing & becoming more meaningful. Coming Winter ’18 (Oct 2017), Lightning experience is expected to be on par with Classic & many new modern day CRM features would be available exclusively in lightning alone.

With all these developments, Migrating from Salesforce Classic to Lightning experience trend has already began. In the next year or two, we could see more & more customers opting for Lightning migration.

Based on my experience working on classic to lightning migration projects, I have put together a checklist which could be used during initial assessment & solution design. I would like to share the checklist items in this article,

Custom/Visualforce Components:

• Analyse the UI components used in the Visual force pages & check for the availability of equivalent component in Lightning Design System (LDS) referring this link
• Check for the usage of the third party Java script (JS) frameworks and decide if those frameworks are supported in Lightning. Lightning doesn’t support all JS frameworks and the list of supported JS frameworks can be found in this link
• Custom pages can also be developed using UI development apps such as SKUID, Grid Buddy, etc.. check the availability & impact of using these kind of tools in Lightning. For Instance Grid Buddy is not yet compatible with lightning. In such scenarios we may have to look for equivalent lightning ready apps or develop custom lightning solution using LDS
• Salesforce classic’s Custom Java Script Buttons functionality is not supported by Lightning. Refer to this link to find the alternatives in Lightning Experience
• Custom components developed using lightning & are added to Record detail page will only appear in Desktop Experience but doesn’t appear in SF1 app. For the customers with similar requirement & the need for custom component to work in both Desktop & SF1 app, we need to plan an additional effort of 5 to 20 % (based on complexity) to make the component work in SF1 app using Lightning Actions.
• If some of the existing visual force functionality can’t be migrated to Lightning, we can take an approach of making Classic pages look like Lightning. This option should be exercised only for the must have features which can’t be migrated to Lightning due to the current limitation of LDS

Standard Extensions:

• Check if the customer is using Salesforce Classic Mobile app which will retire on Dec 1st 2017. Review the app, based on the business requirements & customizations decide if the app can be converted to/created as SF1 or Custom Mobile app (Mobile SDK) solution
• Check for the Communities, type (partner or customer), customizations and the business requirements. These are to be recreated using Salesforce Lightning Bolt community framework
• Open CTI functionality, is supported in both Classic & Lightning experience but there are some functional differences which are listed in this link.

Admin/Config:

• At present, all the Standard objects available in Classic are not present in Lightning. List & Review the list of Standard Objects which are currently used by the customer, ensure the availability of these objects in Lightning & plan the next steps accordingly
• Lightning Record Home pages at present are quite simple & only shows couple of List views. If the customers org. Record Home Page has multiple views (Config./Customization’s) these views won’t be switched to lightning automatically. We may have to consider developing custom Record Home Page app in this scenario
• Calendar Sharing and Ownership is not supported in Lightning yet. This is a major limitation for the customers in need of this frequently used feature
• If the customer is using any apps, see if these apps in the app exchange are available in lightning ready mode. If not do the following & decide,
  1. Check the time frame by which the existing app will be made lightning ready
  2. Check for similar solutions in app exchange which performs the same functionality
  3. Considering developing a custom Lightning solution to meet the similar requirements

Generic:

• Refer to roadmap to see if missing functionalities are coming in the upcoming release. Design solution considering road map & appraise customers accordingly. The current road map can be found here
• Be familiar with the Limitations & known issues in Lightning. The current list is available in this link

Classic to Lightning Migration activity can range from simple to quite complex. Based on the modules implemented in the project, we may have to cover multiple functional areas. In this blog, I have only covered the functional areas which were part of my projects. Though this checklist is not exhaustive it serves as a good reference to understand the approach & the key areas to be focused during Migration assessment & solution design phases.

Do share your feedback & migration experiences 🙂

.. Prashanth N ..

Salesforce: Mobile Apps Development Approaches

After a gap of over 6 months, i’m back to blogging 🙂 and this time on Salesforce Mobile apps development approaches.

These days it is difficult to find a person without holding a mobile phone in their hand. People of every stripe create and consume data on an ever-increasing variety of connected devices.

Considering the rapid growth story of the mobile devices, businesses are investing on mobile app development to promote, advertise, sell, service, deal with client/partner, etc. from the mobile apps. This trend is evident in CRM space as well. Going mobile has become a key business requirement in most Salesforce implementations nowadays.

The Mobile apps can broadly be classified into two categories,

• Consumer apps: developed for Customers
• Business apps: developed for business users (Employees/Partners -> Sales, Marketing, Service & Operational users)

To meet the challenge of running businesses on mobile devices, Salesforce provides the Salesforce Platform (App Cloud Mobile).

As part of this article, I intend to cover the following two approaches/options provided by Salesforce for building & deploying mobile apps and considerations to be applied to choose the right approach.

1) The Salesforce1 App:

• This is the fastest way to deliver mobile app for employees
• Already built and made available in Apple App Store & Google Play Store by Salesforce
• Offers simple point-and-click tools for administrators and the Lightning web development platform for advanced developers to customize & extend the Salesforce1 app

2) Salesforce Mobile SDK:

• Gives developers the tools to build the customized user experiences
• Native & Hybrid custom mobile apps can be developed with this option
• These apps can target employees, customers, or partners
• Custom Apps can be built using Device Native or web technologies (HTML 5, JavaScript frameworks like React Native, Cordova, Ionic and Polymer)
• Provides same grade of reliability and security found in Salesforce1

Comparison & Considerations:

Comparison Parameter	Salesforce 1	Mobile SDK – Native	Mobile SDK – Hybrid
Development effort/cost	Medium	Very High	High
Maintenance/changes	Easy	Very Complex	Complex
Branding	Very Minimal	Customizable	Customizable
User Friendliness	Less Intuitive	Intuitive	Intuitive
Navigation	Fixed	Customizable	Customizable
Offline	Available	To be Custom built	To be Custom built
Access to app using Web browser	Not available	Not available	Available
Platforms Support	iOS, Android & Windows	iOS & Android	iOS & Android
App/Play Store Subscription	Not Required	Paid Subscription	Paid Subscription

 

Conclusion:

With Salesforce1 approach, mobile solution can be deployed faster on all the three popular mobile platforms with minimal effort. But downside with this approach is limited support for app customization to meet Corporate branding needs (such as UI themes, Navigation, User Friendliness & also users end up downloading Salesforce app not the company app from the Play Stores, App Store & Windows Market place)

Mobile SDK – Native approach, Native apps typically have better performance with rendering and animations & also “feels right”. Look and feel is consistent with most of the other native apps on the device and end user can pick up the app navigation & use the app faster. The major disadvantage with this option is, a separate code base has to be created & maintained for each platform. Also, native apps can’t be made available on browser.

Mobile SDK – Hybrid approach, hybrid apps are platform agnostic & this is one of the main appeals of a hybrid app: you build it once and then you release it across multiple platforms. We have a complete flexibility to design the app meeting corporate branding needs. Moreover, we just have to maintain a single code base. And these apps can also be made accessible on browser for the users who don’t have access to Smartphones.

I hope these inputs helps you to better understand various Mobile app development approaches, the merits & demerits and the parameters to be considered to choose the right approach

.. Prashanth N ..

Salesforce: Apex Callout Vs Outbound Messaging

As we know, Salesforce provides the following features to implement Outbound Integration(s),

• Apex Callout
• Outbound Messaging (OM)

While designing a solution, it is very important that we fully understand the capabilities of these features to make a right design choice. As part of this blog article, I intend to share the capabilities along with considerations to be applied to choose the right Outbound Integration feature.

1. Apex Callout, enable Apex to invoke external web services. This allows you to connect to 3rd party web services such as Google, Amazon, Facebook, and any other external web service.

Capabilities:

• Callout requires familiarity with Apex coding
• Transaction failure & retry logic should be explicitly coded
• Supports both SOAP & REST API Invocation
• Sync & Async requests handling is supported
• We can send multiple records (including related) in a single transaction
• Apart from Basic & Certificate-Based, other authentication (s) can also be implemented using “Named Credentials”
• Sync Callouts should be considered only in the following scenarios. Otherwise consider using Async callouts.
  • When the Target System guarantees the faster response time (SLA of ~ 3 to 5 seconds)
  • Transfer minimal data
• Callouts are generally launched from Triggers and Custom Buttons/Links
• SOAP & REST API Callouts can be implemented using WSDLtoAPEX and HTTP Objects

Consider using Callouts in the following scenario(s),

• Target system Web Services (SOAP/REST) can be directly consumed within Salesforce
• Sending Multiple/Multiple Related records
• Specific authentication method (say Basic) is required

2. Outbound Messaging (OM), allows you to specify that changes to fields within Salesforce can cause messages with field values to be sent to designated external servers.

 Capabilities:

• OM can be implemented using Point & Click tools without having to write any code in Salesforce
• Can be invoked from Workflow Rules, Approval Processes and Entitlement Processes
• Retry logic to reprocess failed records comes Out of the box. If the endpoint is unavailable, messages will stay in the queue (Salesforce) until sent successfully, or until they are 24 hours old. After 24 hours, messages are dropped from the queue. If a message cannot be delivered, the interval between retries increases exponentially, up to a maximum of two hours between retries
• Sends configured fields in the form of XML SOAP message to the specified end-point
• The destination end point should be setup in a specific way for it to accept the contents of the SOAP message being sent. We won’t be able to use existing web services of the Target system.
• The request & response format is predefined by Salesforce. Our solution should align to this format
• Only certification based authentication is supported
• We can only send single parent record fields in the SOAP message. Additional web service transaction should be issued back to Salesforce (from custom solution) using the session id sent in the SOAP message to get additional (related) records
• Max of 100 notifications will be sent in a single outbound message
• Only Async transactions are supported

Consider using OM in the following scenario(s),

• Leverage point & click tools, avoid coding
• If we are integrating with Target system using the intermediate (custom) service for any reasons, we could consider using OM feature

Hope this article helps to make a right choice while designing a solution for outbound integration. If you have any specific comment on the capabilities and considerations, please do share.

..Prashanth N..

Salesforce Integration & Customization Capabilities Overiew

Integrating Salesforce with external systems (Ex. ERP); building custom web extension apps/batch programs to meet the specific business requirement is quite common when we work on large scale Salesforce projects.

Before we attempt to develop such solutions, having a good understanding of various integration (+custom extension & batch) scenarios we generally come across and the provisions provided by Salesforce to implement each of these scenarios helps us to pick the most efficient, scalable & reliable implementation approach.

The objective of this blog article is to list all possible integration (+custom extension & batch) scenarios and to introduce/brief various provisions provided by Salesforce to implement each of these scenario.

General Integration (+custom extension & batch) scenarios,

1. Outbound Integration
2. Inbound Integration
3. Automated Batches
4. Bulk Data Management/Migration (Export/Import)
5. Custom Web Extensions (Web – Mashup, Links, Applets, Tabs,..)
6. Custom Mobile Solutions

Now let us go through the provisions provided by Salesforce in order to implement each of the above scenarios,

• Outbound Integration: can be implemented in Salesforce using the below features,
  • Apex Callouts
  • Outbound Messaging

• Inbound Integration: The following options are available to implement Inbound Integration,
  • SOAP Web Services API
  • REST Web Services API
  • Apex Web Services

These options can also be used in combination with Outbound Integration approaches for some specific solutions.

• Automated Batches: We can write the automated batches using APEX & run these batches as per the required frequency using APEX Scheduler. Triggers & Process Builder can also be considered for automation based on the requirement.

• Bulk Data Management: The following are the available options for Bulk Data Management. Based on the data volume, right option should be decided.
  • Import wizard
  • Data Loader
  • Batch Apex
  • Bulk API

• Custom Web Extensions (Web – Mashup, Links, Applets, Tabs,..):
  • To develop a custom web page/app Salesforce provides Visualforce, Lightning Design System, AURA, APEX development framework
  • To render the custom web pages developed outside salesforce within Salesforce, Canvas & Connected Apps features can be leveraged

• Custom Mobile Solutions: Salesforce provide Mobile SDK to build custom Mobile Solutions. The Salesforce Mobile SDK supports three development approaches for building mobile apps: native, HTML5, and hybrid.

Factors to be considered to pick the right approach among the available options will be covered in the subsequent blogs.

Prashanth N

How Salesforce Lightning Design System is special

Developing a custom mashup (web page) screens in medium to large scale CRM implementation is quite common either to meet unique custom business requirements or to render the data from external systems (being within CRM) to facilitate a comprehensive/single view to the CRM users.

If a CRM system doesn’t provide a framework to develop these custom UI extensions, generally we choose to use J2EE/.Net/PHP technology stack to develop these custom extensions (mashup).

Of late most CRM apps work in desktop, tablets & smart phone devices in wide variety of browsers & mobile apps. One key expectation when we develop custom extensions is to make them work in all browsers/devices on which CRM works. Also, make them look similar to standard CRM pages.

Meeting this key expectation using a custom technology stack is going to be time consuming & quite challenging (if not impossible) though we have many client side frameworks that are platform/device neutral. Many times we need UI design experts to design complex mashup screens.

If we pick the wrong technology stack or if the mash ups are not designed following the best of the design practices, the CRM usability &  performance will be affected.

To overcome all of these pain points; many a times we wish if CRM could extend a framework (used to build the CRM application itself) and can the framework be made available in the programming language which a developer is familiar with?

The very thought of using a CRMs native framework for custom extensions development is quite exciting as it makes the life of the developer easy.

Salesforce does exactly that with Lightning Design System (LDS), the framework used for the development of Lightning experience & Salesforce 1 (SF1) Mobile app.

This framework provides 80% of UI components used in  Lightning & SF1 Mobile. And the developer can choose to use any of the UI components they would need in their Mashup screens/ Lightning apps development. The sample codes & detailed documentation will only help to accelerate the learning & development process.

The following are some of distinct benefits of using LDS in custom mashup screens/Lightning apps development,

• LDS looks similar to HTML code making it easy to adopt
• App development becomes easier
• Make your app look like salesforce Lightning experience & SF1 Mobile
• Build apps faster
• Facilitate reusability
• LDS is Optimize for best practices and make bad practices harder to implement
• Accessible by design : Supporting WCAG 2.0 and Section 508 standards
• Developers can design any complex mash up screens on their own without having to depend on the expert UI designer

Are you excited & want to start with LDS learning, here are the quick links,

https://lightningdesignsystem.com/

https://trailhead.salesforce.com/en/module/lightning_design_system

Good luck & happy learning LDS!!

Prashanth N