Salesforce Native vs App vs Connector

 

Fair warning: This is more about not having written anything in a while than the value of the topic…and the subject matter is more about drawing your own conclusions than relying on what is easily available, so…

App is one of the most over-used and ill-defined terms in the IT lexicon. This is greatly due to it being used by people outside the IT domain. The domain itself has had some whoppers, like the DHMTL that was a must-have at the turn of the century even though the only honest definitions of the term were that it had no real definition. Microservices runs a close second simply because there is an invisible grey line between SOA and Microservices that is a mile wide and an inch short. But I digress, as is often the case.

What I’m really thinking about today is apps in the world of Salesforce.com. Specifically, apps that run inside the Salesforce CRM platform. I started thinking about this because I was looking into CPQ vendors over the weekend to refresh myself on the market to support a project proposal to select the best option for a particular business. It’s a large space, so it always helps to find someone else’s list to start with and someone had given me a list from a major analyst group as that starting point.

Other than analysts, no one likes long lists with lots of details, so I first wanted to narrow it by those that integrated with Salesforce. It didn’t take me long to remember that Salesforce is the gold standard for CRM and there were only two that didn’t. I didn’t go through the whole list to get to that count because I’ve done these kind of evaluations before and figured out after the first half dozen that this was not how I was going to narrow the list. The two were just what was noticed while skinning this cat another way.

The first trimming of the list was by industry focus. The potential client is a tech service, sort of SaaSy, and “High-tech products” was one of the categories, which was much closer to what they did than “Financial services” (though they have customers in that domain) or “Industrial products” (which the analyst seemed to think usually included high-tech, though not sure why).

To spare you the tedium of the several hours of wading through 1000’s of lines of marketing prose that could have been delivered in a table (ahem, yes, I know, kettle, black, etc.), from just the perspective of Salesforce CRM integration, I found it useful to divide them into three basic styles:

Native: An application that is built entirely in Salesforce
App: An app that runs inside Salesforce that depends on data and/or functionality managed outside of Salesforce.
Connector: An application that runs independently of Salesforce and has a way to share data with Salesforce.

The terms for these distinctions change often over time and between sources. These definitions are for clarification of the table below and are purposely simplified as deeper distinctions are less relevant about integration than other aspects.

In this particular exercise, the ask was to provide some pros and cons to these different styles. My style being one of adapting general terms to technical solutions, I responded with a non-exhaustive list of Benefits and Concerns:

Integration Styles Native App Connector
Benefits
  • Easily accessible in the sales process context.
  • Seamless integration with other native apps.
  • Has gone through Salesforce security review.
  • No data latency.
  • Easily accessible in the sales process context.
  • Access is managed within Salesforce.
  • Has gone through Salesforce security review (only if installed through App Exchange).
  • Control over storage impacts.
  • Broader range of vendors to choose from.
Concerns
  • May require additional Salesforce licensing.
  • May have impacts on storage limitations.
  • Frequently limited functionality.
  • Support may require coordinating the vendor and Salesforce.
  • High potential for latency.
  • Difficult to trouble-shoot.
  • Users must use multiple applications.

Of course, the next question is usually “which is best”, and I must respond with the architect/consultant/writer-needing-higher-word-count with “it depends”. And it depends on lots of things, such as who will be maintaining the solution; how are capex and opex prioritized and managed; how do different stake holders actually need to interact with the solution; and is it clearly understood that this only one aspect of a vendor selection process and all known aspects must be documented and weighted before giving a recommendation?

The real reminder for me when I finished this brief analysis was that context is everything when doing any type evaluation. The list that I started with included products that were questionable as to whether they really belonged in the report and many of the products were listed as serving domains that there was no mention of on the vendor’s site and no compelling reason why the unmentioned-domain would want to use it. If I had direct access to the author(s) I may learn something by asking, but the important thing is that I used their input only as a starting point and applied my own analysis because when the recommendations are provided to a client, those author’s name will not be on the agenda and they will not be there to answer the questions that hadn’t yet been thought of.

Facebooktwitterredditlinkedinmail
© Scott S. Nelson
IT puzzle pieces in the cloud

Enterprise Salesforce Team Recipe

This is a stream-of-consciousness consideration of SaaS vs Custom vs Budget for organizations that use Salesforce CRM products

The best practice in Salesforce when providing a feature to users is to first look at the standard components, then in App Exchange and if neither of those have what you need, build it yourself (or have a partner build it with you). This is repeated over and over again in articles, videos, and training content developed about how to get the highest ROI using Salesforce. So why is the question asked so often, and why do some many organizations follow the least beneficial path in response?

One reason that seems drive a lot of decisions is that because each business has its unique factors that it requires a unique solution.

Another common reason often cited for custom development on top of Salesforce is that their needs are “not supported out-of-the-box”. This is sometimes elaborated with “we tried to use it out-of-the-box, but it didn’t work”.

The reality is that these organization, at some level, chose a Software-as-a-Service solution as the best value to fulfill CRM and related needs. This is an architecture to go with buy-before-build where most of the needs have already been paid for. In a well-managed enterprise architecture, any custom development once the buy-before-build principle has been realized with the selection of a SaaS solution requires an exception case.

The reasons often present for the exception case of building custom within Salesforce (when a case is presented) seem perfectly valid. If the product doesn’t provide the functionality required, custom is the way to go. What requires more consideration is how this conclusion was reached.

Sometimes it is made by stakeholders with no SFDC administration experience doing a search on the-search-engine-everyone-uses and coming up empty. It is a seldom acknowledged understanding that searching is a skill and that, like driving, it is not uncommon for people be more confident in their abilities than the evidence warrants. The next level of problem with this criterion is that being skillful in searching in one area of interest will not always translate to searching other topics. One factor that may not be (though should be) common knowledge is that the results of the same search can vary greatly when run from different user accounts. The search engine “learns” the types of results the user usually responds to and will provide the results prioritized based on previous searches.

The same issues with search can carry over to stake holders who do perform administrative tasks in Salesforce on a regular basis. Further, the predictive prioritization provided by the search engine will include what the majority have followed, whether it is the most correct or most accurate response to the query.

A scenario that is as likely as the subject matter neophyte searching for answers is when the search is performed by someone who is skilled in custom development. Here the same factors come to play both in how the questions are asked, i.e., “how to develop [solution x]”, how the search results will be ordered (based on most frequent selection of past results focused on custom solutions) and the fact that many developers build custom solutions because they prefer not to use administrative functions.

Salesforce has been refining their capabilities since 1999 and have been very successful at it. That success is not because they missed their customer needs most of the time. There are many organizations that are paying a huge premium in maintaining their custom solutions because insufficient due diligence was performed before customizing.

This isn’t to say that customization isn’t sometimes well warranted. There are many unique needs for solutions on the Salesforce platform, and it is why the Salesforce platform is as flexible as it is.

A well-architected and managed Salesforce org will have a mix of admins to developers that is at least even, if not heavy on the admin side. Depending on the size of the org, either the role of architect can be an external consultant, or the full-time architect will work with external development teams for the occasional custom requirement.

One misunderstood Salesforce certification is the Platform App Builder certification. It is listed in both the Administrator and Developer career path definitions, and it favors entirely meta-data-based solutions. This is how the out-of-the-box capabilities provided by Salesforce can be “customized” without having to maintain custom code. It also allows for developer to create custom components that can fill in any minor feature gaps that can be managed by administrators after development.

Many organizations are struggling with staffing competent and experienced Salesforce developers when there are many skilled administrators out there than can help an organization make better use of their original decision to buy rather than build.

Facebooktwitterredditlinkedinmail
© Scott S. Nelson
Photo by Ruben Mishchuk from Unsplash

When Change Sets Fail in Salesforce

With the growing popularity of DX and the GA release of DevOps Center, I’ve seen fewer questions about Change Sets the last couple of years. I expect that organizations that have used change sets successfully for a long time are less motivated to change their processes and those that had issues have had sufficient time to move to the newer options.

What I have seen in the past around legacy processes that work well for small teams is that they are often passed to newer members experientially and at some point someone joins that is not mentored into to how things have been done and struggle on their own. Here are a few tips for those that run into this gap with change sets.

Practice makes it home by dinner time

Even the simplest change can result in big problems if something critical is missed. Always test the change set by pushing from one sandbox to another that has been refreshed since the last production update. If there is a possibility of changes being done directly in production, this means to create or refresh the test target sandbox immediately before the deployment test.

Go small or stay home

Incremental changes are best. I prefer to do a deployment anytime there is a completed task that has tested in development. The push could just be to a fresh sandbox with the final production release being a series of pushes. Another approach is to use dark deployments, pushing out tested work products incrementally even though not all pieces are ready for users. The dark deployments may require some custom metadata types or permissions to keep them from being used before they are ready, something it is really useful for large projects to avoid big-bang pushes.

The incremental pushes to sandboxes should result in a series for change sets. As they progress, dependencies may be discovered and indicate a need to revise the change sets so that dependencies are pushed first. Again, the dark deployments are useful here.

The mighty DX

Among many good reasons for switching to DX, verbose error messages for deployments helps speed up debugging. Using Workbench, it is possible to turn change sets into packages for use in DX, which is handy if you are just starting to migrate to DX. Again, test deployments against fresh sandboxes are critical to avoiding critical situations.

The only constant…

Is change, not change sets. Eventually change sets will probably go away, so if you are reading this post you are either bored and avoiding more productive tasks or you are struggling with a change set today.  Now is a good time to start looking into alternatives.

Facebooktwitterredditlinkedinmail
© Scott S. Nelson
We can't display this page because your browser blocks cross-domain cookies, but you can view this page in Salesforce Classic. Click here to open this page in Salesforce Classic.

Salesforce Lightning Admin browser blocks cross-domain cookies use Classic

I see lots of other folks running into this and thought I would post the fix along with my thoughts. (TL;DR).

The error message is “We can’t display this page because your browser blocks cross-domain cookies, but you can view this page in Salesforce Classic. Click here to open this page in Salesforce Classic.” It can happen in several screens and is a result of some of the base domain changes that Salesforce has been making coupled with the security changes browsers have been making. For chromium-based browsers (Edge, Chrome, Brave, etc.) the fix is to add your domain to the cookie exception list.

With screens, the process go as follows:

Go to Settings > Privacy and security
Go to Settings > Privacy and security
Select Cookies and other site data
Select Cookies and other site data
Under Sites that can always use cookies click the Add button
Under Sites that can always use cookies click the Add button
Paste your SFDC domain path in the Site dialog and Check Including third-party cookies on this site
Paste your SFDC domain path in the Site dialog and Check Including third-party cookies on this site

Click the Add button and

Refresh your Salesforce screen [F5]
Refresh your Salesforce screen [F5]
Tada!

Note: You could use a wildcard in place of the sub-domain for all salesforce domains, but I don’t recommend that as it would leave you vulnerable to some miscreants that use their orgs for nefarious purposes.

To summarize:

  1. Go to Settings > Privacy and security
  2. Select Cookies and other site data
  3. Under Sites that can always use cookies click the Add button
  4. Paste your sub-domain and domain path in the Site dialog
  5. Check Including third-party cookies on this site
  6. Click Add button
  7. Refresh your Salesforce screen [F5]
Facebooktwitterredditlinkedinmail
© Scott S. Nelson
In what city were you born?

SOLVED! Salesforce “In what city were you born?” not set.

TL;DR – The default answer to security question “In what city were you born?” is San Francisco

Here’s the scenario: You signed up for a new free Salesforce Developer account. After filling the form properly you get the screen that they have sent a verification email and, lo and behold, it is immediately in your inbox. You click the link and get…a DNS error. Well, that is annoying, but understandable given the volume of traffic Salesforce deals with. It will propagate eventually, so you decide to come back later.

Later, you come back and the DNS now resolves to your shiny new org, but now the new user token has expired and instead of the prompt to change your password you just get the regular old login screen asking for a username that is in the email and a password that has never been created. This is a Charlie Brown and Lucy place-kicking moment.

Well, this has happened to me a few times, and in the past I just created a new account and eventually would get a notification that the previous org was being decommissioned for non-use. But today I didn’t feel like filling the form out again, so I tried something unique (for me)…when prompted for city on the password reset screen I first tried blank, since that is what it would be if it was never set. That resulted in a note that I was wrong (not the ISO-270001 recommendation, BTW). So I thought “what would have I set as a default response?” And then I thought “the city where headquarters is”. And I was right.

Cheers!

Facebooktwitterredditlinkedinmail
© Scott S. Nelson