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
Salesforce Sharing and Visibility on path to Technical Architect

My Sharing and Visibility Architect Path

Full disclosure: This is a quick draft from notes made during my prep journey and quickly edited after passing. Based on comments received, I may revise and elaborate further (hint, hint)

Overview of the Sharing and Visibility Architect certification

After completing the Administrator and Developer certifications, the App Builder certification seemed easy, and I had an expectation they would continue to get easier. I was right and wrong.
I struggled a bit with this certification, for a variety of reasons. First, the earlier certifications are very popular as the best of the entry-level exams. Popularity in this century leads to quantity, and there was lots of high-quality study material available for free and at a reasonable cost. I used to find the Salesforce sharing and visibility topics a bit confusing. They are highly flexible, and flexibility can lead to complexity. The thing about complexity is that when it is well-managed it has a simple core. Getting to that core is the challenge with understanding the subject areas of sharing and visibility and preparing for the certification exam.

Study Guides

For most of my earlier certifications I started with digging deep into the material and the using practice exams to help identify my weaknesses. There are not a lot of courses for sharing and visibility, and many that are out there are out of date. I think part of this has to do with the diminishing number of test takers for this one, coupled with the complexity of the material. Higher effort to address a smaller market reduces those interested in completing. I did find a decent subject matter course on Udemy, my usual go-to for learning anything quick at reasonable price (so long as I can wait for one of the frequent sales). I also found a good, exam-focused series on YouTube that I highly recommend for those like me who want multiple sources and frequently treat YouTube videos as pod casts, using audio-only.
Of course, I also did all of the related modules and trails on Trailhead. There were fewer of these for sharing and visibility compared to my previous certification, too. I also found them less effective in making the content stick in my head.

Practice Exams

Where I struggled was finding practice exams. Most of the ones on Udemy for sharing and visibility are garbage (sorry, Udemy…and I’m a stock-holder, too). One is not too bad, though I think I give it some leniency because of the comparison to what else is available. I finally got frustrated and posted on Trailhead (where I am guilty of answering more questions than I ask, a poor learning strategy). The community did not let me down and came back with a solid recommendation for focusonforce. Their format is a bit different, in that they have practice exams, and they also have section-focused exams. I missed the section-focused being separate from the practice exams until the last minute. I would have felt much more prepared had I found them earlier. They also have a nice feature of 20 random questions that are mixed in proportion to the exam topic mix, which was great for when you don’t have a lot of time and still want to practice.
Oh, yeah, another cool feature from focusonforce is the ability to see the answer after each question instead of at the end. I know there are some free site on other topics that do this, but this is the first time I have seen it with a high-volume and high-quality set of practice exams. It made it easier to make notes on my weaker areas. With better notes, I then used bionic text forming to make it easier to read them over and over again.
No matter what exam you are preparing for or where you get the practice exams, I recommend taking the practice exams using multiple paces; fast, slow, checking each, checking at the end.
One of the reasons I was so dissatisfied with the Udemy practice exams is that the questions are so long and complex, yet it is still 60 questions each. Well, turns out most of the questions really are long and complex. Still, the Udemy ones missed the actual style of the real questions. Understandable, given the level of complexity, but still disappointing.
Take the practice exams using multiple paces; fast, slow, checking each, checking at the end. When doing the real thing, follow standard practice of speed through and mark for review, etc.. The value of practice exams is more than learning the answers to likely questions. The highest value is in adopting the mindset and thought processes in the context of how exam questions are stated and rated, which is more complex and more constrictive than a typical design session where one can review the problem repeatedly over time and adjust

Tips to taking the exam

  • When doing the real thing, follow the standard practice of speeding through answering the easy questions and marking any with any level of doubt for review.
  • Review first pass unchecking those you are totally confident you are right or totally confident you have no clue.
  • Third pass, commit to an answer.
  • If time remains, go through everything again.
  • On the second pass, read the questions thoroughly. It is the small details in the exam that are easy to trip over.
  • Remember that it’s the best solution given the parameters.
    • If multiple options will solve it, which has an advantage over the others?
    • Which addresses all of the variables in the question?
  • When there are multiple answers that could be right, think about which answer is declarative vs programmatic and which is the most secure

Resource links

Below is a list of resources I used. I hope they help you in your own pursuit.

Trailhead Trailmixes

Udemy

The practice exam that was OK on Udemy is Salesforce Sharing and Visibility Practise Tests – 100% PASS (that is the title, not an endorsement by me).

Focus on Force

YouTube

My notes in Bionic Text Format

runAs() is only for test classes
runAs() does not enforce user and system permissions
runAs() does not enforce FLS

Tagging rules have only three options:
1. Restrict users to pre-defined tags
2. Allow any tag
3. Suggest tags

There is no View Content permission

The Salesforce CRM Content User is a Feature License enabled at the User Level (not Profile)

Granular locking is default

Granular locking processes multiple operations simultaneously

Parallel recalculation runs asynchronously and in parallel thus speeding up the process. Creating sharing rules or updating OWD must wait until the recalculation is complete

Initialize test data and variables before the startTest method in a test class

There is NO Account Team Access

Team Member Access is how to view access.

While the permission is Edit, the Apex method is isUpdateble()

While the FLS column is View, the API method is isAccessible()

If want to see group access, look in group maintenance table, not sharing setting for object.

User above a role in the hierarchy can edit opportunity teams of users in subordinate roles

File types cannot be restricted by the library

Opportunities have a Transfer Record permission

Experience Cloud uses Sharing Sets

Sharing rules cannot set base object access

PK chunking to split bulk api queries for large data sets

Rapid access usually means a custom list view

A library with more than 5k files cannot have a folder added

Sharing set in Experience Cloud allows access only to account and contact records.

Share groups are only for HVP users

Schema.Describe.SObject/Field result for permissions

Session based permission set group is more efficient than multiple session based permission sets

There is no Partner Community Plus

Sharing sets can be assigned to profiles

Criteria based sharing rules are only for field value criterion. If no field value criteria, use ownership based sharing rules

Max file size for UI upload is 2GB

EPIM = Enhanced Personal Information Management

Delegated external administrators can’t see custom fields on user detail records

Sharing Hierarchy button is a thing that shows the hierarchy

Share Groups are not available for Partner Community Users

If the default OWD access is changed for an object, it is no longer controlled by parent

There is no Permission Object

Sharing Rules share to groups and profiles, not individuals

Enhance Transaction Security Policy can be triggered by request time length

If only one custom record type is assigned to a user that is the default type for that user.

Territories can belong to public groups

Activities are child objects of any of the following parents: Account, Opportunity, Case, Campaign, Asset and custom objects with Allow Activities.

the ‘with sharing’ and ‘without sharing’ keywords can be declared at the class level, but not at the method level.

The Group Maintenance tables store Inherited and Implicit grants, i.e., the extrapolated grants, which makes sense as extrapolation is more compute-intense than a query.

Partner Community can use Sharing Rules

External OWD must be equal or more restrictive than the Internal OWD

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
SFDC Login Use Custom Domain

Trailhead Log In to Personal or Scratch Org SOLVED!

Having problems logging in to your dev, personal, or scratch org to verify the completion of a 500 point Trailhead lesson? Personal dev orgs are Production orgs and use login.salesforce.com and dev sandboxes are sandboxes and use test.salesforce.com and since I usually just use the CLI to log in to scratch orgs I can never remember which to use. And I don’t need to. There is enough to remember about Salesforce and technology in general, so if I can simplify something to a common approach, I always do. In this case, when authoring an org of an OAuth connection I always use the Use Custom Domain option and paste in the domain of the org I want to use.

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