Architectural options when working with webforms

Website forms, or webforms, or just forms, are awesome. They allow you to easily collect information from people who may or may not exist in Salesforce.

They often come with a built-in native Salesforce connector, allowing you to submit data to one or multiple objects (often the Contact, Account, and Opportunity).… Read the rest

Are you going to Dreamforce 2023?

These days, it feels like every social channel is talking about Dreamforce next week. It’s although you cannot escape the consistent messaging from every direction.

It’s also clear the main topic this year is AI.

  • AI + Data
  • AI + Trust
  • AI + {anything}
  • AI + {everything}

I’m sure the event will be spectacular this year.… Read the rest

A trait that separates experienced Salesforce consultants from juniors

What exactly separates the experienced Salesforce consultant from the junior?

From my perspective there are four main factors:

  1. Technical knowledge, of which Salesforce is the largest component.
  2. Industry knowledge, to know the common challenges facing your target industry.
  3. Interpersonal skills, like communication, trust building, and negotiation.
Read the rest

How to start and stand out as a new Salesforce consultant

One of the advantages of starting a career in Salesforce is its low barrier of entry.

I’ve heard of several success stories in which someone with no prior Salesforce experience teaches themselves using free resources, gets the admin certification, and then lands a $80,000/year job, all within 6 months.… Read the rest

Surfing the Salesforce wave

I often advocate for being a Salesforce specialist instead of a generalist. There are numerous benefits to selecting a specific focus and then diving deep to become a specialist in that group.

When looking from a higher perspective, however, we are all already specialists: While we continue work with Salesforce, we are platform specialists.… Read the rest

Technical deliverables in the discovery phase – part 3 of 3

Let’s finish with part 3 of 3 of the “usual suspects” for the technical deliverables in Salesforce discovery projects.

3. Environment Release Strategy

Purpose:

  • Understand the various sandboxes and their uses
  • Describe how functionality will be migrated from one sandbox to another and eventually to production

Usage:

  • Some sandboxes are specifically built for development while others are for proof of concepts (POCs) or testing
  • Align everyone on how to move functionality from one instance to another, i.e.
Read the rest

Technical deliverables in the discovery phase – part 2 of 3

Let’s continue with part 2 of 3 of the “usual suspects” for the technical deliverables in Salesforce discovery projects.

3. User Flows

Purpose:

  • Understand the different actors and their interconnectivity and dependency
  • Visualize the steps and easy-of-use required from each actor
  • Help make decisions about the scope during the implementation stage

Usage:

  • Serve as guidelines for the broader context of user experience (UX)
  • Are a critical input for contextualizing the user stories
  • Establish a baseline understanding of the “completeness” criteria for features within the application

Required:

  • Swimlanes to divide logic per actor
  • Transitions between the various actor
  • Major steps taken by each user and by the system
  • Decision points along the way

Example:

 

4.Read the rest

Technical deliverables in the discovery phase – part 1 of 3

When conducting a Salesforce discovery project, there are a number of technical deliverables. Here are the usual suspects:

1. Current and Future System Landscape

Purpose:

  • A visual diagram representing the current state and target future state of Salesforce in context with other connected systems

Usage:

  • Helps understand the breadth of technical work required
  • Helps understand the key data passed in integrations
  • Are a primary source for data modelling and recommendations for 3rd party apps

Required:

  • Connections between Salesforce and external systems
  • Name and purpose of each system
  • Key data elements passed between systems

Example:

2.Read the rest

Overpricing yourself to avoid work

Here’s a cheeky hack to avoid certain projects: Overprice yourself.

I’ve only done this a few times myself, as it sometimes feels a little dirty. Necessary, but nevertheless dirty.

For example, let’s say a potential client has unreasonable expectations of what Salesforce can actually do.… Read the rest

Tracking data changes over time

There are a couple methods to report on changes to Salesforce data.

The most common is field history. To summarize, once enabled, you can report on when field changes occur, the old value and the new values.

To enable this feature, navigate to the desired object in Object Manager and click “Set History Tracking” from the Field & Relationship menu.… Read the rest

What does conversion rate mean to you?

A client of mine told me they want to have a Salesforce dashboard component that displays a conversion rate. I asked for clarification, and how this metric would be used. As you know, asking why is an important step before you begin the design phase.… Read the rest

Optimizing your Salesforce data model with junction objects

Recently I did a Salesforce audit for a client. They had a number of issues with their instance, and wanted a review from an independent expert.

The main person responsible was an Accidental Admin, and wasn’t given sufficient time to design a modular and scalable data model.… Read the rest

3 levels of using hardcoded values in flows

Every once in a while, you’ll need to use static variables in a Salesforce automation. These variables may be different in sandboxes and in production. But once they are set in a sandbox, they don’t change often.

To illustrate the option, imagine a simple example where we want to assign accounts to a specific user.… Read the rest

You really don’t want to rename standard objects

There’s a temptation that just because you can rename standard objects, you should. Common examples are

  • Contact –> Person
  • Account –> Company
  • Opportunity –> Project

Here are several reasons why this is a bad idea.

1. Inconsistency
It’s generally bad design practice to have the label and API name be different.… Read the rest

The larger impact of merging records

Salesforce offers a few options to merge records, whether they be accounts or contacts.

The merging process is straightforward for the user; you choose which record becomes the master, and merge individual fields into the master. All related objects of the merged records are reparented, and then merged records are deleted.… Read the rest

Naming your project champion

My coaching students often ask me what is usually the biggest concern about a Salesforce project. You know, the one that often keeps me up at night, worrying.

The answer usually surprises them, because it has nothing to do with technology.… Read the rest

How much data should you migrate?

Let’s imagine, as part of a new Salesforce implementation, you need to migrate data from a legacy system. The legacy system contains people and companies and sales opportunities. So, how much data should you migrate?

Most organizations will want all the accounts and contacts, regardless of when the last contact or activity was.… Read the rest

At least three rounds of data migration

Let’s imagine, as part of a new Salesforce implementation, you need to migrate data from a legacy system. Let’s also assume the data can be exported into a .csv file. So, how many rounds of data migration should you do?

Since the title gives away the answer, let’s discuss the rationale.… Read the rest

Should you only update the source of truth?

Let’s imagine a scenario in which Salesforce needs to integrate with a system of record for account information.

This system, which we’ll call AccountSOT, is the “source of truth” for some account-related fields. This includes the account name, addresses, phone numbers, and FAXs (don’t laugh, some companies still use them).… Read the rest

Why you shouldn’t use tags in Salesforce

Initially, tagging records seems like a good idea. And, in theory, it is. In practice however, not so much.

In Salesforce, tags are called topics. You can add the topic component to any lightning page, and then configure some basic settings such as the title, placeholder text, and number of topics shown.… Read the rest