Blue Being Cool


Index of Posts

Leave a comment

Posted by on October 21, 2015 in Miscellaneous


Interfaces, Extensions, Abstractions, & Virtual Classes

Interfaces, Extensions, Abstractions, & Virtual Classes

I’m working on a project that has landed me on a foreign planet in a galaxy far far away where I need to learn about Interfaces, Extensions, Abstract, and Virtual classes. I figured that since I tend to understand something a lot more clearly when I have to write about it in a way that someone else may also understand I might as well generate a blog post!



An interface is a point where two things (systems, subjects, organizations, etc.) meet and interact, like the touch pad on your microwave, the snooze button on your alarm clock, or the computer screen in your intergalactic spaceship.

In Apex a class interacts with the outside world through its methods: the methods form the class’s interface.

As it turn out, you can also define what methods must exist in the class (the class’s interface) with a separate piece of code called an Interface.

So you can think of an Interface as sort of a template for a class. You could also think of it as a Contract where the class that implements the Interface agrees to do something with each of the methods it defines (according to Wikipedia, an Interface is “an abstract type that is used to specify a behavior that classes must implement“).

Here are some points about Interfaces:


  • An Interface is like a class
    • For example, when you want to write an Interface using MavensMate you tell it that you want to write a New Apex Class
  • Interfaces do not have an access modifier (private, public, protected, or global)
    • By definition Interfaces are always global
  • Another class Implements an Interface
    • Example: public class TriggerDispatcher implements ITriggerDispatcher
    • Multiple Interfaces can be implemented by a single class
  • Methods defined in the Interface are do not have a code body in the Interface
    • Only the method signatures are present followed by a semicolon
    • Method bodies are empty so they’re simply not even written (no curly braces)
      • Example: public String createString(Integer int);   << see, no {} code body, just a semi-colon
  • The class that implements the Interface must provide bodies for each of its methods (although the bodies can be empty)
  • Classes implementing Interfaces can have additional methods from the ones defined in the Interface
  • Multiple Interfaces can be implemented by a single class
  • Many programmers name their Interface classes with an “I” at the beginning
    • Example: ITriggerHandler
  • Interfaces cannot have member variables
  • Interfaces do not have access modifiers like public, private, etc
  • When an Interface extends another interface, the parent interface and methods do not need to be defined as virtual (read on for more on Extending and Virtual)

What are Interfaces Good For?

Interfaces separate the declaration of methods from the implementation of them. This is known as a “level of abstraction” and allows you to have different actions that can occur for the same method.

Here’s an example from the project that is making me learn this stuff: setting up a Trigger Framework.


No matter what object has initiated the trigger, or what type of action initiated the trigger (insert, update, delete, undelete), there will always be a method that each trigger handler will use to initiate its actions. Since it is expected that there will be multiple trigger handlers needed, having them implement an Interface ensures that each will have the same method(s).  In this example the methods of the interface are named “mainEntry,” “inProgressEntry,” and “updateObjects:”


Even though each class that implements the Interface will have a mainEntry method, that method for classes that handle the Account object will have different actions than the one for classes that handle the Asset object. And isn’t it nice when they all have the same method signature? It’s so neat and tidy and makes for such nice, consistent code. 😛

Now classes that implement this Interface must provide bodies for all methods in it. Here is an example where they all have exceptionally skinny bodies:



Interface Data Types

When you define an Interface you are also defining a data type. This means that you can use the Interface name anywhere you would use a data type, like when declaring a variable:


When you do this you must be sure that any object that you assign to that variable is an instance of a class that has implemented the Interface. In other words, your variable is an Interface type, and all classes that implement the Interface are also Interface types.



An Extension is when one class Extends another class, adding additional or different functionality from what existed in the first class. The extending class inherits all the methods and properties of the first class and then has the ability to add more stuff, too. It’s just like a hair extension which adds to the hair on your head!

The actual terminology is “parent class” for the original class, and “subclass” for the class that extends the parent. Sort of boring. I like “super class” for the new-and-improved version… and maybe “underdog class” for the original. 😀

Classes that extend other classes may also inherit another power: the ability to override methods from the original class. What this means is that the super class may not have to put up with the functionality that came with the methods it inherited, and, instead, can have it’s very own unique functionality for them.

There is a term for this–Polymorphism–which means that classes that extend other classes (subclasses) can have their own unique behaviors yet share some of the same behaviors as the class they extended (the parent class).

In order for this to happen the parent class must be a Virtual class and the methods that can be overridden must be Virtual methods or the parent class must be an Abstract class and the methods that can be overridden must be Virtual methods or Abstract methods. More on this below.

Some Key Points About Extensions

  • A class can extend only one other class
    • (As opposed to Interfaces where a class can implement several Interfaces)
  • The syntax looks like this:
    • Parent Class Definition: public class ParentClass {}
    • Subclass Definition: public class SubClass extends ParentClass {}
  • Interfaces can extend other interfaces
  • In order for a parent class to be extended it must be declared as Virtual or Abstract (more on this below)
  • Subclasses can override virtual methods within virtual classes (polymorphism)
  • Subclasses must override abstract methods within abstract classes if they are going to use them
    • Subclasses can override virtual methods within abstract classes if they want to, but they don’t have to

Virtual Keyword for Classes and Methods


Virtual is a keyword that is used to modify the definition of a class or method (the technical term is “definition modifier”).

What it means when it’s used in a class definition is that the class can be extended and any virtual methods within the class can be overridden. (Overridden means that you have written your own code that replaces the code in the original method.)

What it means when it’s used in a method signature is that the method can be overridden (as long as that method resides in a class that can be extended).

To override a virtual method all you need to do is re-write the signature of the method and include the keyword “override” right after the access modifier like this:

public override void methodName() {}


Some Key Points on the Virtual Definition Modifier:

  • Classes declared to be Virtual can be extended and will allow overrides of their methods that can be overridden
  • Methods within a Virtual class that also have the Virtual definition modifier may be overridden
    • Methods not marked Virtual cannot be overridden
  • Virtual methods must have a code body, but the code body can be empty
    • (As opposed to Interface and Abstract methods which cannot have a code body in the Interface of class where they’re originally defined)
    • Example: public virtual void methodName() {}  << see, a {} code body
  • Interfaces are, be definition, already considered to be virtual so including that keyword in the Interface declaration is redundant (and, in fact, the Developer Console will not allow you to include it)

 Abstract Keyword for Classes and Methods


Abstract is a keyword that is also used to modify the definition of a class or method.

When used in a class definition what it means is that the class is sort of just floating around in space and cannot be used as-is. It’s “abstract” as in “not concrete.” Since it cannot be used on its own it cannot be instantiated (it isn’t concrete so it can’t really exist).


It also means that the class may contain Abstract methods.

An abstract method looks almost exactly like a method in a Interface in that it has its signature but no body. The only difference is the signature will also have the “abstract” definition modifier:

  • Abstract method signature: abstract void mainEntry();
    • (Abstract method signatures may also have access modifiers like “private” or “public”)
  • Interface method signature: void mainEntry();

There is a key difference between an Abstract class method and an Interface method, however, and it is that classes extending an abstract class have the option to provide bodies for abstract methods from the parent class, whereas classes implementing an Interface must provide a body for every method in the parent Interface.

Some Key Points on the Abstract Definition Modifier:

  • Abstract classes must be extended in order to use them, they cannot stand on their own (be instantiated)
  • Abstract classes can have methods which are Abstract, Virtual, or just regular ol’ methods that contains code
    • As opposed to Virtual classes that can have Virtual or regular ol’ methods, but cannot have Abstract methods
  • Abstract classes can have member variables
    • Interfaces cannot
  • Abstract methods cannot have a code body in the class where they are originally defined
    • (As opposed to virtual methods that must have a code body)
    • Instead the signature is terminated with a semicolon like a regular line of code
    • Example: public abstract void methodName();  << see, no {} code body, just a semi-colon
  • Abstract methods cannot be static

So How Do Interfaces, Abstract Classes, and Virtual Classes Compare?

Generally you’ll see comparisons between Interfaces and Abstract Classes because both must be put into play by another class in order to be used, whereas Virtual Classes are more like just regular ol’ classes that can be instantiated and used as-is. In order to get them straightened out in my mind, however, I’ve included Virtual Classes along with the other two so I can more readily see their similarities and differences.

  • Instantiation:
    • Neither Interfaces or Abstract Classes can stand on their own
      • Interfaces must be implemented
      • Abstract classes must be extended
    • Virtual classes can stand on their own (be instantiated)
      • They can also be extended if the need arises
  • Methods:
    • All methods in an Interface are methods without bodies (just the method signature) and their body must be defined in the class that implements the Interface
    • All methods in Virtual classes will have bodies which can be well-defined or empty
      • Virtual within a Virtual class can be overridden
      • Regular ol’ methods within a Virtual class cannot be overridden (they’re just inherited by the subclass)
      • Virtual classes cannot have Abstract methods
    • Abstract classes can have Abstract, Virtual, or just regular ol’ methods
      • Abstract methods do not have a body
      • Abstract methods must be overridden if they are going to be used
        • If you’re not going to use an abstract method you do not need to create a body for that method in the subclass
      • Virtual methods can be overridden if you want to do so
      • Regular ol’ methods within an abstract class cannot be overridden (they’re just inherited by the subclass)
  • Member Variables:
    • Interfaces cannot have member variables (they have only methods)
    • Abstract and Virtual classes can have member variables
  • Extending and Implementing:
    • Interfaces can extend other Interfaces
      • Interfaces cannot implement Interfaces
      • Interfaces cannot extend Abstract or Virtual classes
    • Abstract and Virtual classes can implement Interfaces
    • Virtual classes can extend Abstract classes and other Virtual classes
    • Abstract classes can extend other Abstract classes
      • Abstract classes cannot extend Virtual classes

How To Know Which To Use


Here’s where some experience with Apex or Java coding most surely helps a ton. Fortunately I found a couple explanations, which I’ll paraphrase here, that really helped me understand how I might choose between an Abstract class and an Interface.

When thinking about the possible super classes that you may spin off of your underdog class, would you group those classes together based on a “thing” (a noun) or an “action” (a verb)?

For example, if your super classes were types of star ships (Enterprise, Gryphon, Drake, Apollo), then they would be “things.” If they will have similar actions (warp speed, cloaking, disk separation), then they would be “actions.”

  • For classes that are more “things,” use an Abstract class as the parent class
  • For classes that are more like “actions,” use an Interface

Another way to look at which to use is by where you want your implementation.

  • With an Interface you can share your methods with any class that implements your Interface
  • With an Abstract Class your methods are stored in one central place where all subclasses can access them, which avoids code duplication

Yet another way to compare the two:

  • When you can fully describe the class in terms of “what it does” without needing to specify any of “how it does it,” then you should use an Interface
  • If you need to include some implementation details, then you will need to represent your concept in an Abstract Class

And here’s a caveat:

  • If you add a new method to an Interface then you mush track down all the implementations of the interface and include the new method
  • If you add a new Abstract or Virtual method to an Abstract Class you can provide a default code body and then only classes that need to override the default actions need to be updated

    Features                                      Interfaces                                Abstract Class

    Multiple inheritance A class may implement several interfaces A class may extend only one abstract class
    Default implementation An interface cannot provide any code, just the method signatures. An abstract class can provide complete, default code and/or just the details that have to be overridden.
    Access Modfiers An interface cannot have access modifiers for the subs, functions, properties etc everything is assumed as public An abstract class can contain access modifiers for the subs, functions, properties
    Core VS Peripheral Interfaces are used to define the peripheral abilities of a class. In other words both Human and Vehicle can inherit from a IMovable interface An abstract class defines the core identity of a class and there it is used for objects of the same type
    Homogeneity If various classes only share method signatures then it is better to use Interfaces If various classes are of the same kind and use common behavior or status then it is better to use an abstract class
    Speed Interfaces require more time to find the actual method in the corresponding classes Fast


Chaining It All Together

So now that I’ve figured out a thing or two while researching this blog I feel a whole lot more comfortable reading the Trigger Framework code I’m trying to understand. It’s a nice piece of work by Hari Krishnan (you can find it here) and is the framework that I’ve decided to use to build out the triggers needed in an org I’m working/learning in.

In Mr. Krishnan’s framework he has identified a couple Interfaces that define the methods that need to be present in the trigger code. While I found this concept fairly straightforward, what had me thrown was that he also uses virtual and abstract classes to implement those Interfaces.

But there is a wonderful reasoning for this: by implementing the Interfaces with abstract and virtual methods they become optional for the end classes (the classes that extend the abstract and virtual classes) where the actual grunt-work code resides.

For instance, he has defined several methods in his Interface ITriggerDispatcher. He then implements that Interface with a virtual class, and in that class he added a new, fully defined method. Finally the object-specific end classes extend the virtual class. In this end class only the methods from the virtual class that are needed are overridden. The other methods are ready to be used if the time arises that they are needed, but until such time they do not need to reside in the final class. Furthermore, when new functionality is needed, only the end classes need to be created or updated without having to change anything within the framework.

Pretty cool.


Leave a comment

Posted by on June 28, 2017 in Apex


Tags: , , ,

Customizing Auto-Number Fields

Customizing Auto-Number Fields

Auto-number fields are fields where Salesforce saves an incremented number for you. It’s commonly known that you can specify a prefix in the field and the number of digits you want displayed, but did you know that Salesforce allows you to include date elements?

The General Format of the Auto-Number Field

I think it’s generally known that an auto-number field has a prefix section and a number section which produces a value something like this:

Job – 00001

In this example “Job – ” is the prefix and “00001” is the number.

I say “generally known” because when you create a custom object and select that you want the Name field to be an auto-number field, Salesforce gives you a suggestion with a prefix for how to format the value saved in that field.

What is slightly less obvious is that you can also specify a suffix which is any string of characters you choose to come after the auto-number portion of the value.

You tell Salesforce how you want the final field value to look by entering a “Display Format” (available with Auto-Number fields only).

The Display Format

The Display Format is like a word with a prefix and suffix where the word is the incremented number that Salesforce generates:

Prefix Auto-Number Suffix

The total length of an Auto Number field is 30 characters, 20 of which can be the prefix and/or suffix text, and 10 of which can be the number. That means is that you can play with adding up to 20 characters to the beginning and end of the auto-number.

It also means that there is a maximum number that can be generated–a number up to 10 digits or 9,999,999,999.

Specifying the Number Portion of the Format

The number portion of the field value is fairly straight forward:

  • It is designated by enclosing zeros between curly braces with the number of zeros indicating the number of characters the field should always display
  • The zeros indicate the minimum number of digit characters that are saved in the final field value
    • So a designation of {000} would add three or more digit characters to the final field value
  • As records are generated this portion of the final field value can expand to a maximum of 10 characters to hold larger numbers
  • The number portion of the Display Format is required with a minimum of one place-holder zero specified: {0}


  • {0} – This is the minimum required number placeholder and will always display a number without any leading zeros
    • 1, 27, 392, 893827391
  • {0000} – This format would display numbers from 1 to 99 with leading zeros, and numbers greater than 99 without leading zeros:
    • 0003, 0041, 0178, 2693, 1928837492

One limitation is that the number cannot be displayed with any comma separation. For smaller numbers this isn’t a very big deal, but larger numbers will be just a run-on string of digits that look something like this:


Specifying the Prefix and Suffix Portions of the Format

The prefix and suffix are any characters you choose. The sky’s the limit!

So anything you enter before the number format is part of the prefix, and anything you enter after the number format is part of the suffix.

Prefix – {0000} – Suffix

Adding Dates in the Prefix or Suffix

Salesforce has a provision for allowing you to add date values to the prefix and suffix portions of the auto-number. To do this you enclose day, month, or year specifiers between curly braces in one or more of these formats:

  • {DD} – show the two-digit day
  • {MM} – show the two-digit month
  • {YY} – show the two-digit year
  • {YYYY} – show the four-digit year


  • {YYYY}-{MM}-{DD} {0000} – Creates: 2014-06-12 0008
  • TPS {0000} {MM}:{YY} – Creates: TPS 0213 06:14

Incidentally, the day, month, and year specifiers must be in capital letters (D, M, Y) and you must use two characters for the day and month (example, {D} and {M} will not work), and either two or four characters for the year..

Maximum Number

With auto-numbers you can specify what number you want Salesforce to begin with as long a your starting number is less than 1,000,000,000 or a maximum of 999,999,999.


Leave a comment

Posted by on June 13, 2017 in Fields



Regex in Salesforce

Regex in Salesforce

(Pardon the dust. 🙂 This post is still a work in progress!)

Regex is a confusing language to me. But even though I find it confusing, I recognize it’s power to verify input. Here are my (ongoing) notes on Regex.

What is Regex?

Regex is a sequence of characters that defines a string pattern. Huh? Let’s break that down:

  • Regex is short for “regular expression”
  • A “regular expression” is a sequence of characters
  • That sequence of characters may look more like hieroglyphics than anything else
    • regex
  • Those hieroglyphics define a string pattern
  • A string pattern is a string of characters, such as a username or an email address

So Regex is hieroglyphics that define a string. 😀

Regex Names, Engines, and Flavors

Other Namesflavors

Regex is also known as Regexp.

Engines & Flavors

Regex is processed by software called an Engine. And to complicate things, there are lots of different engines, each with its own unique way of interpreting the regular expression. The syntax and behavior of a particular engine is called a regular expression flavor. What this means is that if you’re using Regex in Java you’ll be using one flavor, and if you’re using Regex in Python you’ll be using another flavor.

What Flavor Does Salesforce Use?

Salesforce uses the Java flavor (see Java.Util.Regex Class Pattern).

Where Is Regex Used In Salesforce

Salesforce has a REGEX function that is available in field validation formulas, Visual Flow, and Apex. The REGEX function is not available in formula fields or in Visualforce. Boo.

The Salesforce Regex Function

The Salesforce Regex Function looks like this:

REGEX(the_string_to_check, the_regular_expression)

Using REGEX In Validation Rules

Validation rules look for errors. If an error is found (the validation rules evaluates to True), an error message is displayed and the user must correct their input before the record can be saved.

This means that when you’re writing REGEX that matches what you want in the field you’ll need to negate the final result like this:

NOT( REGEX(Zip__c, “[0-9]{5}(-[0-9]{4})?”)

Getting To The Nitty-Gritty Of Understanding Regex

nitty grittyOkay, so how do you start to understand Regex gobbly-gook? You take it just one little bite at a time!

So here we go!

gobbledygookHow characters are represented in Regex

Other than special characters, what you see is what the Regex formula is looking for. In this example the formula is looking for the letter “u” and only the letter “u”. If anything else is present the formula will evaluate to false:

REGEX(String, “u”)

A set of characters, or Character Class, is a group of characters between brackets. Character classes allow for several different characters to be present at a given location in the string. In this example the formula is looking for a single character, the letter “a”, the letter “f”, or the digit “2”:

REGEX(String, “[af2]”)

To include all the characters between two given characters you can use a dash. In this example the formula is looking for a single character between “t” and “x” or between “R” and “Y”:

REGEX(String, “[t-xR-Y]”)


To exclude characters you put a carat (^) at the beginning of the character class. In this example the formula is looking for a single character other than “g”, “e”, or “n”:

REGEX(String, “[^gen]”)

Note: the carat is a special character that has dual meaning. When it is used within a character class it means negation. When it it used outside of a character class it signifies the beginning of the string (see further down in the post for this).



Characters can be grouped together by including them between parentheses. In this example the string “bouncy ” is grouped and the entire function matches the string “red bouncy ball”:

REGEX(String, “red (bouncy )ball”)


Wildcard Characters and Repeating Pattern Quantifiers


When you need to match any character or a given token zero or more times you can use wildcard characters and repeating patterns:

  • . (period) – Match any character except a line terminator
  • ? (question mark) – Match the preceding token 0 or 1 times
  • * (asterisk) – Match the preceding token 0 or more times
  • + (plus sign) – Match the preceding token 1 or more times
  • {n} – Match the preceding token n times
  • {n,} – Match the preceding token n or more times
    • Note: {0,} is equivalent to * and {1,} is equivalent to +
  • {n,m} – Match the preceding token at least n times and no more than m times
    • Note: {0,1} is equivalent to ?


  • REGEX(String, “pe.k”) will match “peak”, “peek”, “pe2k”, etc.
  • REGEX(String, “goat(ee)?”) will match “goat” and “goatee”
  • REGEX(String, “red (bouncy )?ball”) will match “red ball” and “red bouncy ball”
  • REGEX(String, “tiger9*”) will match “tiger”, “tiger9”, “tiger99”, “tiger999”, etc.
  • REGEX(String, “(lily)+”) will match “lily”, “lilylily”, “lilylilylily”, etc.
  • REGEX(String, “(boo){2}”) will match “booboo”
  • REGEX(String, “7{2}”) will match “77”, “777”, “7777”, etc.
  • REGEX(String, “xo{3,4}”) will match “xoxoxo” and “xoxoxoxo”

“Greedy,” “Lazy,” and “Possessive” Quantifiers

When an engine parses a string with quantifiers (things that multiply characters) there are ways to help the engine be more efficient. This is where “greedy,” “lazy,” and “possessive” quantifiers come. While it’s mostly not necessary to know the difference, it is helpful when reading someone else’s Regex to know what these things mean.  See this site for an excellent explanation of quantifiers.

Greedy Quantifiers

The special characters ?, *, +, {n}, {n,}, and {n,m} are called “greedy quantifiers” because they match as many characters as possible.

Lazy Quantifiers

Quantifiers combined with the question mark create what are called “Lazy Quantifiers.”

  • ?? – once or not at all
  • *? – zero or more times
  • +? – one or more times
  • {n}? – exactly n times
  • {n,}? – at least n times
  • {n,m}? – at least n times and up to m times

At first blush at appears that there isn’t any difference. The difference lies in how the engine parses the string to look for a match. With greedy quantifiers the engine will try to match as many instances of the quantified token as possible. With lazy quantifiers the engine will try to match as few as needed.

Possessive Quantifiers

Quantifiers combined with the plus sign create what are called “Possessive Quantifiers.”

  • ?+ = once or not at all
  • *+ – zero or more times
  • ++ – one or more times
  • {n}+ – exactly n times
  • {n,}+ – at least n times
  • {n,m}+ – at least n times and up to m times

These quantifiers are helpful when you want a match must fail quickly if it doesn’t follow a particular pattern. Using possessive quantifiers can increase the efficiency of your Regex function.

Special Characters and Metacharacters


Special characters are characters that have a special meaning to the regex engine. Metacharacters are special characters used within a character class.

Special Characters

These are the special characters in Regex:

  • \ (backslash) – is combined with another character to mean something else
  • ^ (carat) – 1) denotes the beginning of a line or 2) negates a character class
  • $ (dollar sign) – denotes the end of a line
  • . (dot or period) – represents any single character except a line terminator
  • | (pipe or vertical bar) – is used as an “OR” operator
  • ? (question mark) – multiplies a token 0 or 1 time
  • * (asterisk) – multiplies a token 0 or more times
  • + (plus sign) – multiplies a token 1 or more times
  • – (dash or hyphen) – used for indicating a sequence (range) of characters
  • () (parentheses) – enclose character groups
  • [ (open bracket) – enclose character classes
  • { (open curly brace) – used when multiplying a token a specified number of times


Any of the special characters except these, the metacharacters, can be used within a character class (a group of characters within brackets) without escaping them. Metacharacters have special meaning within a character class depending on where they are used. If used in their special places, they have special meaning and you would need to escape them in order to test for the actual character. If used in their not-so-special places, they do not need to be escaped.

These are the metacharacters in Regex:

  • ] (closing bracket)
    • it’s special place is anywhere after the first position in the character class or after the negating carat
    • Example: “[]xyz]” tests for a closing bracket and the letters “x”, “y”, and “z”
      • This can also be written “[xyz\]]”
    • Example: “[^]867]” tests for anything that is not a closing bracket or the digits “8”, “6”, or “7”
    • Example: “[tip\]] tests for a closing bracket and the letters “t”, “i”, and “p”
      • This can also be written “[[tip]”
  • \ (backslash)
    • the backslash must always be escaped within the character class if it’s a character you’re testing for
    • Example: “[+-$*\\]” tests for +, -, $, *, and \
  • ^ (carat)
    • it’s special place is right after the opening bracket. Placed anywhere else it is just a character
    • Example: “[^pex]” – Here the carat means “not”. This would test for anything except the characters “p”, “e”, and “x”
    • Example: “[This^Too]” – Here the carat is nothing more than a character
  • – (dash or hyphen)
    • The hyphen has three special places:
      • right after the opening bracket
      • right before the closing bracket
      • right after the negating carat
    • used anywhere else it is just a character

Escape Character

The escape character is the backslash (\) character. This means to represent any special character in a string you would need to put the backslash in front of it like this:

  • \\\\ – the backslash character
  • \^ – the carat character
  • \$ – the dollar sign character
  • \. – the period character

Backslash – Character Combinations

Certain characters combined with a backslash represent certain non-alphanumeric characters:

  • \\t – tab character
  • \\n – new line (linefeed) character (this is a line terminator character)
  • \\r – carriage return character (this is a line terminator character)
  • \\f – form feed character
  • \\a – alert (bell) character
  • \\e – escape character
  • \\cx – the control character corresponding to “x” (ctrl-B would be “\\cB”)

Predefined Character Classes

The following are predefined character classes you can use:

  • . (period) – matches any character except a line terminator
  • \\d – matches any digit (shorthand for “[0-9]”)
  • \\D – matches any non-digit (shorthand for “[^0-9]”)
  • \\s – a white space character (space, tab, new line, form feed, carriage return, and \\x0B)
  • \\w – a “word character” (shorthand for “[a-zA-z_0-9]”)
  • \\W a non-word character (shorthand for “[^a-zA-z_0-9]” or “[^\w]”)



Boundaries are things like the beginning or end of a line or a word. These are the boundary characters you can use:

  • ^ – the beginning of a line
  • $ – the end of a line
  • \\b – a word boundary
  • \\B – a non-word boundary
  • \\A – the beginning of input
  • \\G – the end of the previous match
  • \\Z – the end of the input except for a final terminator
  • \\z – the end of the input

Some Sample Regex Formulas

  • California Drivers License
    • REGEX(Drivers_License__c, “([A-Z]\\d{7})?”)
    • Example matches:
      • C7768934
      • nothing (the ? means 0 or 1 item)
    • Checks for a capital letter followed by 7 digits
  • Credit card number
    • REGEX(Credit_Card__c, “(((\\d{4}-){3}\\d{4})|\\d{16})?”)
    • Example matches:
      • 1234-1234-1234-1234
      • 1234123412341234
      • nothing (a blank field)
  • Email address
    • email regex
  • Number between 100 and 99999
    • \\b[1-9][0-9]{2,4}\\b
  • US Phone Number
    • REGEX(Phone, “((\\([2-9]\\d{2}\\) ?[2-9]\\d{2}-\\d{4})|(([2-9][0-9]{2}-){2}\\d{4})|(([2-9][0-9]{2}\.){2}\\d{4})|([2-9]\\d{2}){2}\\d{4})?”)
    • Example matches:
      • (223)456-7890
      • (223) 456-7890
      • 223-456-7890
      • 223.456.7890
      • 2234567890
      • nothing
    • Interesting note: the area code and “exchange” code (the first three digits after the are code) cannot start with 0 or 1 (these numbers are reserved for special purposes). All the other digits can be any number from 0 to 9.
  • Social Security Number
    • REGEX(SSN__c, “((\\d{3}-\\d{2}-\\d{4})|\\d{9})?”)
    • Example matches:
      • 123-45-6789
      • 123456789
      • nothing
  • US Zip Code
    • REGEX(BillingPostalCode, “\\d{5}(-\\d{4})?”)
    • Example matches:
      • 95610
      • 84328-4484

Some Regex Resources


  • – This site is a good place to learn more about Regex. Their tutorial jumps around a little bit, but for the most part is laid out fairly linearly.
  • Java.Util.Regex Class Pattern – This is the Regex pattern that Salesforce uses with the one exception that the backslash character must be escaped with a backslash since it’s a special character in Salesforce. This means that instead of writing \d to indicate a digit from 0 to 9 you would need to write \\d (the first backslash tells Salesforce to use the second one for just what it is, a backslash character and not a special character).
  • – This site is great for testing your Regex. You enter the expression in the top space and in the Test String space you place some strings. The window to the right of these spaces will tell you how the expression worked.
  • – This is another site for testing your Regex.
  • – Browse for useful expressions and test your own expressions.
  • Regex Quantifiers – This site is an excellent tutorial on quantifiers and much, much more
1 Comment

Posted by on June 8, 2017 in Formulas, Visual Flow


Tags: ,

Visual Flow to Return Letters Only

Visual Flow to Return Letters Only

Have you ever wanted to extract just the letters out of a string? Here is a super quick Flow that you can use to do that. And with just a little tweaking you can adapt it to return additional characters to your liking!

Return Letters Only Flow

Letters Only Flow



  • count is initialized to zero



  • CurrChar = MID({!InputString}, count, 1)
  • IsLetter = REGEX({!CurrChar}, “[a-zA-Z]”)
  • LenInputStr = LEN({!InputString})

Flow Logic

  1. Check the character count against the length of the input string. If it is less than the length, proceed to next element
  2. Increment the character count variable
  3. Check the character in the input string in the count position with a REGEX formula to see if it’s a letter
    1. IsLetter
  4. If it’s a letter, add it to the output string

That’s it! Super simple, but could be really handy.

Other Possibilities

Regex is super cool. I know almost nothing about it, but am learning, and am putting together a little write-up to explain its basics, so stay tuned. In the meantime, here are some other possibilities:

  • Check for digits and letters:
    • REGEX(String, “[a-zA-Z0-9]”)
  • Check digits only:
    • REGEX(String, “[0-9]”)
    • This can also be written: REGEX(String, “\\d”)
  • Check for letters, period, space, hashtag, dash, comma, slash:
    • REGEX(String, “[a-zA-Z. #\\-,/]”)


1 Comment

Posted by on June 7, 2017 in Flow Tips & Tricks, Visual Flow


Tags: ,

Line Feeds in Visual Flow

Line Feeds in Visual Flow

Line feeds, or carriage returns, often seem to be a tricky thing to get into a text field. Here are a couple ways to get them in:

Line Feeds In Text Fields That Support HTML

Using <br/> Text Template

To add line feeds between strings that will be saved to a text field that supports HTML you can add the characters “<br/>” wherever you want there to be a line feed.

This works for text fields that support HTML only. Long Text fields, such as Description fields, do not support HTML, so this trick will not work. Instead you will see <br/> between strings in the field.

To get those characters into the text do the following:

  • Create a Text Template that has a value of “<br/>”Line Break Chars
  • Add the template between strings
  • Add Line Break Between Strings

Using ~ ~ Text Template

Here is another way to create a line break in a text field, and this method will work for Long Text fields, such as Description fields:

  • Create a Text Template where you enter a character, like a period or the squiggly characters, hit Enter to go to the next line, and enter the character again:
  • Line Break Chars
  • Use the template in a formula to combine strings:
  • Combine strings with break

You can also get creative with this one and insert a separator between strings:

  • Line Break Chars

Using ~ ~ Custom Label

The same trick as above can be done with a Custom Label (Setup > Create > Custom Labels). This has the added advantage that you only need to setup a Custom Label once and you can then access it in all your flows.

  • Create a Custom Label in the same way you would create a Text Template:
  • Line Break Chars
  • Now in your flow access the Custom Label using the $Label global variable:
  • Line Break Chars.JPG


Leave a comment

Posted by on May 31, 2017 in Flow Tips & Tricks, Visual Flow



Global Variables in Visual Flow

Global Variables in Visual Flow

In the Spring ’16 release, Salesforce opened up access to several fields on some of the system objects with the use of Global Variables.

Global Variables are special variables that give you direct access to system objects that are in context. For instance, the $User Global Variable gives you access to the User who is currently running your Flow. (Here is a little about Global Variables in a prior post.)

Global Variables have a special nomenclature–they are always preceded with a dollar ($) sign:

  • $Api
  • $Label
  • $Organization
  • $Permission
  • $Profile
  • $Setup
  • $System
  • $User
  • $UserRole

Essentially a Global Variable is “merged” with a “merge field” to give you access to the value that is stored in that field. The exception is with the $Permission Global Variable, where the result you get is True, the permission is present for the current User, or False, the permission is absent.

How to Use Global Variables in Visual Flow

A few Global Variables are generally available everywhere in Visual Flow, but a few are available in one place only: Formulas

So if you don’t see the one you need, no worries, just create a formula which you can then use in the rest of your flow like you would a constant or variable:

formula for global variable

A Few Examples of Ways to Use Global Variables

  • Greet the user by their name:
    • $User.FirstName
  • Determine if the user has a Custom Permission:
    • $Permission.custom_permission_name
    • With this Global Variable the return result will be either true (the Custom Permission exists for the user) or false (they do not have the permission)
  • Determine what Profile the user is assigned to:
    • $Profile.Name
  • Get the value of a Custom Label:
    • $Label.the_name_of_a_label_you_have_created
    • (You can use a Custom Label to create a line feed in a text element.)
  • The Name, State, Phone, Address, etc. of the org:
    • $Organization.Name

Bottom line is using Global Variables gives you instant access to a bunch of information without having to do a query, which is always a good thing.


Leave a comment

Posted by on May 31, 2017 in Flow Tips & Tricks, Visual Flow



ADM201 – Definitions and Miscellaneous Notes Part 2 of 2

ADM201 – Definitions and Miscellaneous Notes Part 2 of 2

Implicit Sharing

Implicit Sharing Overview

  • Implicit Sharing means that the sharing rules of one object is determined by the sharing rules of another
  • This occurs between the Account object and child records to the Account
    • Opportunities, Cases, and Contacts
  • Implicit Sharing also occurs for a various groups of Portal users

Sharing between Accounts and Child Records

  • Access to Parent Account
    • If you have access to an Account’s child record, you have implicit Read Only access to that Account
  • Access to Child Records
    • If you have access to the Account, you have access to the child records
    • The Account owner’s Role determines the level of access to child records

Sharing Behavior for Portal Users

  • Account and Case Access
    • An Account’s Portal User has Read Only access to the Parent Account and all of the Account’s Contacts
  • Management Access to Data Owned by Service Cloud Portal Users
    • Service Cloud Portal Users do not have Roles so Portal Account Users cannot access their data via the Role Hierarchy
    • To grant access to data you would add the Account owner and the Portal User both to a Portal Share Group
      • All users in the Group will have access to the Account data
    • Case Access
      • If a Portal User is a Contact on a Case, the user has Read Only access to the Case

Group Membership Operations and Sharing Recalculation

  • Simple operations such as changing a user’s Role, moving a Role to another branch in the Hierarchy, or changing a Portal Account’s owner can trigger recalculation of Sharing Rules
    • Salesforce must check access to user’s data for people who are above the user’s new or old Role in the Hierarchy, and either add or remove shares to any affected records
  • Link information on designing record access for enterprise scale


  • Lemmatization is reducing different inflected forms of a word to a single form
  • For example, run would be the Lemmatization for running, run, and ran
  • Lemmatization is supported when searching in the following objects:
    • Case (including comments), Chatter Feed, Chatter Group, File, Idea (including comments), Knowledge Article, Question, Solution


  • Queues are groups of users that share a workload, such as handling incoming cases
  • Records in a queue are “owned” by the queue
  • Records in a queue remain in the queue until a queue member processes it or moves it to another queue
    • If a queue member processes a record in the queue, the record owner is changed to that queue member…in other words, the record leaves the queue as a result of the owner being reassigned to an individual user
  • The administrator can specify what objects are allowed in the queue and what users can access those records (the queue members)
  • Queue objects are limited to: Cases, Leads, Service Contracts, and custom objects
    • This means that the owner of a record for any other standard object cannot be a queue, but must be an individual user
  • When a user is a member of a queue and a record is owned by a queue, the user has “Full Access” to that record

Quick Text

  • Quick Text are pre-defined messages that you can quickly insert into Case updates and communication with customers to save time and increase standardization
    • Examples include: greetings, answers to common questions, and short notes
  • Quick Text must be enabled before it can be used
    • Setup > Customize > Cases > Quick Text > Quick Text Settings > “Enable Quick Text”
  • Once enabled, Quick Text cannot be turned off
  • In order to use Quick Text permissions need to be granted to users
    • “API Enabled” for Live Agent users
    • “Read” permission on Live Agent Sessions, Live Chat Visitors, and Live Chat Transcripts
    • “Read,” “Create,” “Edit,” and/or “Delete” permissions on the Quick Text object as required


  • Salesforce Analytics Query Language
  • These are functions that are used in Wave Analytics to return data to be used in Wave Analytics charts and graphs

The Recycle Bin

  • Most deleted items are stored in the Recycle Bin for up to 15 days before they are permanently erased
  • The number of records that the Recycle Bin can store is 25 times your storage limit in MB
    • If this limit is exceeded, then the oldest records in the Recycle Bin are automatically purged if they have been in the Bin for at least 2 hours
  • Users can restore only items they have deleted
    • Admins can restore records deleted by any user

Rule Processing Order

Salesforce processes rules in the following order (Basic)

  1. Validation rules
  2. Assignment rules
  3. Auto-response rules
  4. Workflow rules with immediate actions
  5. Processes
  6. Escalation rules
  7. Rollup Summary Formulas

Violins And Accordions Will Produce Excellent Songs

Valerie Assigns Automobile Work Processes to always Escalate Rolls Royce repairs

Salesforce processes rules in the following order (Detailed)

  1. Validation rules
    1. System validation rules (if request comes from standard UI page edit only)
      1. Layout-specific rules
      2. Required values at the layout level and field-definition level
  • Valid field formats
  1. Max field length
  1. Foreign key validation (if request comes from other sources like Apex or SOAP API only)
  2. User-defined validation rules if multiline items were created (like quote items or opportunity line items)
  1. “Before” triggers
  2. Re-run most validation rules with the exception of layout-specific rules when the request comes from standard UI page edit
  3. Duplicate rules
  4. “After” triggers
  5. Assignment rules
  6. Auto-response rules
  7. Workflow field updates
    1. Re-fires “Before Update” triggers and “After Update” triggers for records with field updates
    2. Re-fires standard validation rules
    3. Does not re-fire custom validation rules, duplicate rules, or escalation rules
  8. Processes
    1. Process Builder processes
    2. Flow triggers, for older orgs where this is still being used
  9. Escalation rules
  10. Entitlement rules
  11. Rollup Summary Formulas
    1. Parent records are updated, then
    2. Grandparent records are updated
  12. Criteria Based Sharing evaluation
  13. Post-commit logic, such as sending emails

Stay-in-Touch Requests

  • A Stay-in-Touch Request is a way for a user send an email to a Contact or Person Account to request updated information
  • The Contact or Person Account must have a valid email address
  • You can send Stay-in-Touch Requests to:
    • Contacts or Person Accounts you own
    • Contacts that are associated to Accounts that you own
    • Contacts that you can edit because a Sharing Rule or manual sharing
  • To send a Stay-in-Touch Request, click “Request Update” from the record detail page
  • When the recipient receives the email and clicks a link to provide updates or confirm that no changes are necessary you’ll receive an email notification
    • You can then review, update, and accept or reject the new information
  • Stay-in-Touch Requests can be sent even if the recipient has “Email Opt Out” set to true

Synonym Groups

  • Prior to Spring ’16 Synonym Groups were known as Knowledge Synonyms
  • Synonyms are different words or phrases that can be used somewhat synonymously
    • USB, thumb drive, flash stick, and memory stick could be designated as synonyms
  • Synonym Groups are groups of synonyms that are used to enhance searching for items in the following objects:
    • Knowledge Articles
    • Cases
    • Chatter Feeds
    • Files
    • Ideas
    • Questions
  • When a Synonym Group is created it is enabled for all supported objects
  • Effective Spring ’16 the number of Synonym Groups for an org was increased from 3,000 to 10,000

Tags and Topics


  • Tags are words or short phrases that you can associate with records to describe and organize them in a personalized way
    • Use Tags to group records from various objects by a common theme or use and use those tags in search to make finding information fast and intuitive
  • Two types of tags
    • Personal tags
      • These tags are private and only you can view personal tags you added to a record
    • Public tags
      • These are tags shared among all the users in the org and any user with access to the record can view the public tags
    • Tags can be added to the following objects:
      • Accounts, Activities, Assets, Campaigns, Cases, Contacts, Contracts, Dashboards, Documents, Events, Leads, Notes, Opportunities, Reports, Solutions, Tasks, Custom objects
    • If Topics are enabled for an object, public tags are disabled for that object
      • Personal tags are still available for the object
    • Tag Names
      • Tags can contain only letters, numbers, spaces, dashes, and underscores
      • Tags must contain one letter or number
    • Adding Tags to records:
      • If the record does not already have tags, click “Add Tags”
        • If the record already has tags, click “Edit Tags”
      • Tags can be removed from records
        • If the tag that is removed is the last instance of the tag, the tag is deleted from the org completely
      • Tag Limits
        • You can have a maximum of 500 unique personal tags
        • You can have a maximum of 5,000 instances of personal tags applied to records
          • If personal limits are close to being reached, consider merging similar tags into a single tag by renaming them
        • Good Video on Tags


  • Topics are words or short phrases that you can associate with records to organize them around common themes
    • Topics can be used to filter list views
  • All topic names and descriptions are public
    • Topic names appear in search results
  • Topics can be enabled for the following objects:
    • Accounts, Assets, Campaigns, Cases, Contacts, Contracts, Leads, Opportunities, Orders, Solutions, Custom objects, English articles
    • Topics can also be enabled for Tasks and Events, however, they are not available via list views or the Records tab
  • To enable Topics for Objects go to Setup > Customize > Topics > Topics for Objects
    • When Topics are enabled for an object, public Tags are disabled for records of that object
  • Topic Names
    • Commas (,) and closing brackets (]) automatically end a topic name
    • Other punctuation, symbols and separators are supported in topic names
  • Adding Topics to records:
    • If the record does not already have topics, click “Click to add topics” on the top of the record detail page
      • If the record already has topics, click “Topics”
    • For feed-based layouts, click “Add Topics”
  • Records can have up to 100 topics
  • Topics can be removed from records
    • Removing a topic from a record does not delete the topic name
  • Because Topics are public they cannot be used in Unlisted Groups
    • Instead a hashtag topic can be used when writing a Post or Comment
    • The topic will be formatted as a link after you post but a detail page is not created and the link will not work
  • Deleting Topics
    • When Topics are deleted they are permanently erased (they are not sent to the Recycle Bin) and will not appear in any search result or list
    • Anyone with “Modify All Data” or “Delete Topics” permission can delete standard Topics
    • Deleted Topics cannot be re-introduced by users
    • To delete a Topic, navigate to the Topics page and select Delete from the drop-down menu next to the Topic name


  • Visualforce is used to create custom user interfaces
  • These interfaces are hosted natively on the platform
  • It is generally used to deliver functionality more sophisticated than what a page layout can perform
  • The component-based VF framework includes tag-based markup language similar to HTML and a set of server-side Standard Controllers
  • Standard Controllers make basic database operations like queries and saves
  • Each VF Tag corresponds to a course- or fine-grained user interface component such as:
    • Section of a page
    • A field
  • VF has about 100 build-in components
  • VF uses a traditional model-view-controller (MVC) paradigm


  • Zones are used to delineate access to records for certain objects which do not use the standard Security Model
  • These objects include:
    • Ideas
    • Chatter Answers
  • Multiple Zones can be created and assigned to specific Portals
    • This give you the ability to have different sets of records available to different groups of users
    • A Partner Chatter Answers Zone associated with a Partner Community and an Internal Chatter Answers Zone associated with your internal users



ADM201 Study Notes Index

disclaimerDisclaimer: Always do your own due diligence! Although I tried my best to record accurate and understandable notes, actual Salesforce documentation should always take precedence over the information in this blog. 🙂

Leave a comment

Posted by on January 9, 2017 in ADM201