Salesforce Winter ’17 Release Notes Highlights

It’s that time of the year again!  The Release Notes have just launched and it is time to read through 425 pages of awesomeness.  Or, you can read these 27 highlight along with any of the other great release recap blog posts (I will try to keep an updated list at the bottom of this post).

My initial reaction to playing with the pre-release Org was, wow! Is it perfect?  No.  There are many gaps between Classic and Lightning still, but overall this latest release is a very encouraging sign that Lightning Experience is moving in the right direction.  They seemed to definitely improve the speed of Lightning in this release.

I will mention below the feature if there are any limitations like a feature only being available in Lightning Experience.  If you want more detail on a feature, you can click on the header to drill into the release notes.  The links to the release notes site and PDF are below:

Winter 17 GIF.gif

Visual Flow

Run Flows with a Lightning Skin (Beta)

This is one of the more exciting features for me in quite some time.  This is an out of the box clean looking Visual Flow in Lightning! So cool!  This is not only available in Lightning Experience, but also available in Classic!  Let’s see it in action:

A Lightning Page Component

UsingFlow

A URL (via a Button or Link)

Through a Button.gif

Inside your Flow Designer

FlowDesignerNewUI.gif

Embed Your Flows in Lightning Pages (Beta)

Available in Lightning Experience & Salesforce1

This new feature will make many Admin’s lives much easier.  Now you have a way to avoid Visualforce Pages or URLs to launch your Flow.  Let’s give it a shot and see how this works in action!

Add a new Tab to your Layout.  Click on the Label and select Custom to make it your own!

CustomTabAddLEX

Click on the Tab in the Page.  Then drag in your Flow Component. Select the Flow you want to be visible.  This is also where you’ll assign variable(s) if you have any Input ones.  No real documentation on the naming convention yet.

Drag Flow into App.gif

 

You’re all set to use your Flow!

UsingFlow

Display Flow Screens in Two Columns (Beta)

This really goes along with the new Lightning Skin.  Just another improvement to the UI to allow you some out of the box customization to help keep your Flow from being really long.  I know this was a long awaited feature from all of us Flow crazies.

2 Column Flow.png

Customize the Look and Feel of Flow Interviews with the REST API (Pilot)

This is a really cool feature that allows people to really make their Flows look even better than the new Lightning Skin.  Because this is currently Pilot, I’ve not had a chance to play around with this feature yet.  I’m not sure how many people will adopt this, but the fact that we’re not limited anymore with the UI customization is very encouraging.

rest api.png

Access Encrypted Data in Your Flows, Process Builder, and Formula Fields (Pilot)

This is a really cool feature that not only covers Flow, but also Process Builder and Formula Fields.  This is Pilot, so you’ll have to wait (or contact your AE) to get ahold of this.

Process Builder

Build Reusable Processes

Available everywhere!

A Process that is not Invocable can’t be triggered by a Record Create or Edit, and because of that I would consider it similar to calling a Flow.  At this time you are unable to adjust the Process Type when you Clone a Process Builder, so that wouldn’t be a shortcut to allowing a Process to be Invocable.  When creating an Invocable Process you simply choose the Object it starts on.  It is very simple to use, you don’t have to determine if it was just when a record was created or created and edited.

InvokedPB.gif

Let’s see Invoking a Process Builder in action!  When you select Processes you’ll then have to pick the SObject that you want it to be referencing.  You are just looking for the Object, not an ID Field.

Invocable Process PB

Note – Deactivating an Invoked Process will cause a Flow Trigger Failed to Execute error when the Parent Process Builder attempts to fire the Deactivated Process.

flowerrorgif.gif

View Your Process Types in One Place

So now you’re able to sort by your Process Type and quickly find all of your Invocable Process Builders.  I’m thankful for this one, because it would have been a nightmare to manage if they did not add in this nice feature.

Process Type added

Access Cross-Object Owner Fields in Process Builder!

Previously you were not able to access the related Owner Fields.  Now you are able to Access and reference both Queue and User Fields while in Process Builder.  This is an awesome addition that will save countless Formula Fields from being built (among other things).

Pre-Winter ’17

OldOwnerId.png

Winter ’17

NewOwnerInPB.gif

Communities

Reports & Dashboards are now available in Community Builder!

Previously you had to get creative to get your Reports and Dashboards into the Community Builder.  Now, there is a Lightning Component for a specific Report Chart or a whole Dashboard!

Report

AddingReportChartCommunity.gif

Dashboard

DashboardInCommunity.gif

Custom User Profile & Search now available!

Now you can easily from your Community Builder select a custom Search Component for your Pages.  You can also override the default user component on the pages to have a custom User Profile Component.  Nifty!

Override Theme.gif

Easier than ever to control Page Access for your Community!

If you navigate to your Page Manager, you can now control the Page Access at a Page Level!  This does a great job in simplifying things for us.

CommunityBuilderPageAccess.gif

Super Slick Community Creation Wizard

This is really just a cool looking update… no new features or functionality!

CommunityTemplateCreation.gif

Rich Text Content Editor (Easily Embed Videos!!)

It has never been easier to add a video to your Community than it is now!

RichContentEditor.gif

Chatter Related Enhancements

 Group Chatter is Now Real-Time!  No Page Refreshes!

Available in Lightning Experience

This is a very nice feature to help make Chatter real-time, and a great use case for me to sneak my wife into a post.

RealTimeChatterNotifcations.gif

New Group Creation Wizard!

A streamlined Group setup experience!  Not as flashy as the Community Builder Wizard, but still it makes it very user friendly to create a new Group!

NewGroupWizard.gif

Record Types are now available for Groups!

Groups no longer has to envy other features with record types: it’s now got its very own! All those page variations you created for different group layouts can be assigned to record types. When a user creates a group, one of the first things they do is pick a record type and the variation populates. Voila! One customized group layout ready for action.

recordtypechatter.png

Rich Text in Chatter!

Available in Lightning Experience

You now have the ability to use Rich Text in Chatter!  You can even embed images into your messages!

RichTextChatter.gif

Other Enhancements

New & Improved Navigation Menu!

Available in Lightning Experience

Well, one of the biggest changes that I think everyone is already aware of is the switch in the Nav bar.  I’m glad they switched earlier rather than later.  It also has more functionality than the Classic navigation menu, due to the ability to create a new record, view a previous record, or access a previous list view all from the navigation menu!

rn_lex_nav.png

Better App Launcher now includes all your Apps and Objects!

Available in Lightning Experience

I do like this streamlined App and Object view.  The ability to use a Search on this will come in handy!

AppLauncher.gif

Inline Editing comes to Lightning Experience!!

Finally we can do inline editing inside Lightning Experience List Views!

InlineEditing.gif

Expand and Collapse Sections in record details!

Lightning Experience finally is making the Detail section like Classic.  Previously the Sections blended into the layout more, so this is something I’ve been waiting for.

SectionsInDetails.gif

Clearer Popup Messages for Records

Available in Lightning Experience

Now when you Create a Contact, miss a required field, or encounter any other Error Message, you’ll be greeted with a better error message!

Better Messages.gif

 Object-Specific Sharing Locks!

This one is surely going to save you some time if you’re a Consultant or just setting up (or updating) a Data Governance policy in your own Org.  Object-specific share locks enable you to make changes to sharing rules for multiple objects simultaneously, depending on the objects affected by the sharing rules, sharing rule type, and target groups or roles of the affected users.

SharingRules.gif

Identify and Merge Duplicate Leads

Available in Lightning Experience

This is one of those features that caught my eye immediately.  I know many of my clients are going to love this one.  After playing around with it, you do need more than just a Full Name and Company match for it to show up.  You’ll see by adding a duplicate Email the Potential Duplicates is automatically populated with the other existing Duplicate Lead.

PotentialLeadDuplicates.gif

 Launch a Lightning Component from an Action

It was only a matter of time before this came out.  Just like you can embed a Visualforce Page, you can now embed a Lightning Component in your Actions.

LightningComponentInQAction.gif

Use Global Value Sets (previously Global Picklist) in Picklist Dependencies

Global Value Sets = Global Picklist.  This was something holding me back from using a Global Picklist in some areas.  With this improvement, managing picklist dependencies just got more efficient. You can now make a local, custom picklist dependent on a local, custom picklist that uses a global value set. The global value set is defined in one place and shared. Use that value set for as many local, custom picklists—and their dependent picklists—as you need.

Picklist.gif

Associate Permission Sets with Permission Set Licenses!

If you’ve used a Permission Set License (think Wave Analytics), you better not forget to also assign the Permission Set with that License.  Now, you don’t have to worry!  You can set a Permission Set to be included with that License.

Add and Update Campaign Members Using the Data Import Wizard

From my little time spent on the Answers board, I have seen plenty of questions around importing Campaign members.  While I don’t plan on using this myself, I know this is something many Admins will use.

ImportCampaignMembers.gif

Other Winter ’17 Release Highlight Blog Posts:

  1. Rakesh Gupta’s (Automation Champion) Quick Summary
  2. Jen Lee’s Blog has 5 posts on the different features
  3. Mark Cane’s Force 365

 

 

 

 

 

 

Creating Your First Package in Salesforce

A few weeks back I decided to create a Package.  I had thought about creating one for months, but never invested the time into it.  It was way easier than I thought it would be!  If you’ve created a Change Set before, then you’re ahead of the game.  This blog post will hopefully give those of you who haven’t created your own Package the confidence and encouragement to!  If you’ve developed something that could be beneficial to other Admins, consider packaging it up and sharing it with the Community!

salesforcepackage.png

What types of packages are available for us?

PackCompAttri

Unmanaged Package

This is what you’ll see many of those Salesforce Labs and other free AppExchange Apps use.  By being Unmanaged, it gives the installer (Admin) full control of everything they installed.  It functions as if the Admin built it themselves.

Managed Package

This is what you’ll see an ISV Partner use.  The red section is their magic sauce, and they don’t want you to touch it.  This also allows them to Upgrade their package periodically with new enhancements and features.

(for additional details, please see the Salesforce documentation)

Should you set a Namespace?

If you’re going with the Managed Package, you don’t have a choice.  Managed Packages require a Namespace.  If you’re creating an Unmanaged Package, it is up to you!  The benefit for using the Namespace would be that you won’t have to worry about anyone having conflicting API Names in their Org.  If you choose to go without using a Namespace, the benefit for the Admin is that it really functions exactly as if they built it themselves.

Before adding a Namespace

Namespace1

After adding a Namespace

Namespace.jpg

Namespace2

Creating your Package

Select New in the Packages section.

Hit New.jpg

 

  1. Pick your Package’s Name
  2. Make sure you put in a very good Description for your Package, so any Admin can quickly recognize what your Package is doing.  Don’t make another Admin’s life harder!
  3. Determine if you want to use a Configure Custom Link (Displays as a Configure link within Salesforce)
  4. Notify on Apex Error (enter the username of the person who should recieve an email if an exception occurs in Apex code that is not caught by the code)
  5. Decided if you want it to be Managed or Unmanaged

Creating Package

Add in your Components

This functions just like Building a Change Set.  Select New and then you’ll go through and choose the Component Type that you want to add to your Package.

AddComponents.jpg

AddComponents2.jpg

The dependencies will automatically populate for you.

 The dependencies will automatically populate for you..jpg

Name your Version

When you’re ready, Select the Upload Button.

This will allow you to now choose a Version Name, Version Number.  You can optionally add in Release Notes, Post Install Instructions, and a Description to be shown after installation.  While the last three areas are optional, think about the Admins that will use your App and make sure you’re not leaving them in the dark on setting up and maintaining your Package/App.

NamingVersion

You can optionally add Password protection to your package, require Features to be enabled, and Require Objects.  I am not covering this in detail, because Salesforce automatically detects the required pieces that are apart of your package.

Select Upload… and we’re all done!  Take a look at your Installation URL, you did it!  You can pass this URL to anyone that you want.  You could even look to get your Package added to the AppExchange!

Version1

If you ever want to remove your a Version from being available, just select the Deprecate button while clicked in on a Version.  This allows you to make sure nobody can download an older Version of your Package.

Recap: Creating a Package sounds crazier than it really is.  It is very simple to do and if you have an idea or solution that you think other Admins would benefit from, you can Package that up and share it with the Community!  It is important to remember to use Best Practices with your Packages, and to make sure your have clear and clean Documentation in your Package for the Admins that will use it.  Take the extra time to polish your solution.  That means plenty of Descriptions and hopefully some Post Install Instructions!

How to Simplify the “One Process Builder Per Object” Design Pattern by Using Custom Settings

About three months ago, as we were getting ready for Summer ’16, I posted The “One Process Builder Per Object” Design Pattern.  On that post, my friend Chad Seales commented on asking how you would manage One Process Builder for a whole Object, because one benefit of having separate Process Builders is that you can Activate or Inactive any of them as you need.  He brought up a very good point, and one I had somewhat overlooked before the post.  So we’ll go over how to do just that by using Custom Settings!

Concept Overview:

  1. Create Checkbox Field on your Object
  2. Create Custom Setting
  3. Create Checkboxes on your Custom Setting for each “Process Group”
  4. Reference the Custom Field and Custom Setting in your Process Builder to determine if your Criteria is Active or Inactive.

Navigate to your Object and create a Custom Field with the type Checkbox.  Make sure the Default Value is Checked/TRUE.  For my example I’ll be working on the Opportunity.  I’m going to call this field Process Builder Active.  Make sure to leave a nice description so that any other Admin will know what this field is being used for.  Note – if you’re in an Object with existing records, you’ll have to populate this Checkbox as TRUE through a data load (Default Values do not work retroactively).

Custom Field for PB Active

Navigate to create a Custom Settings (Setup | Develop | Custom Settings).  Select New.

Custom Settings.jpg

You’ll want to make sure that you select Hierarchy as your Setting Type.  If you want additional information on the difference between List and Hierarchy, check out Salesforce’s documentation.

Hierarchy

It is time to click New and add in the different Process Groups or Criteria that you want to control.  For each of these, you’ll want to create a Checkbox Field.

Opportunity Custom Settings.jpg

Hit the Manage button.  This takes us to what I call the “record” of the Custom Setting.

Opportunity Custom Settings.jpg

We then want to hit the New Button.  This is where we will determine if those Checkboxes are TRUE or FALSE.

Default Org.jpg

Check the boxes for the Process Groups you want Active.

Check Boxes

Simple as that… we’re now done with our Custom Setting (until you need to add another Process Group down the road).  Head over to Process Builder, and lets talk about using our Custom Setting values in our Process Builder.  We need to add a final condition to our Criteria.  So, lets add the Custom Field we created Process Builder Active.

Selecting PB Active Field

Select Formula as the Type.

Selecting Formula

Select the System Variable search tool.

System Variable.jpg

Hit $Setup and then select the Process Group Checkbox that you want to use.  Note – $Setup is where all your Boolean Custom Settings fields live inside of Process Builder.

Selecting Checkbox

All that is left for you now is to hit Use this Formula!

Using Formula

For a quick summary, we are used Custom Settings to house the Active Status of our different Process Groups (what used to be individual Process Builders).  This allows you to turn on (or off) specific Criteria inside your Process Builder off without affecting the whole Process Builder!  If you’re being a good Admin and doing this in your Sandbox – note the “record” in your Custom Setting won’t deploy with your Change Set.  You’ll have to manually update that (or through data loader if you have more than 3 checkboxes).

Five Best Practices for Building a Clean Visual Flow

We’ve all been there, where you’re learning to write your first Visual Flow.  The main thing we’re focused on is just making sure that it is functional.  That’s fine while you are in your Sandbox developing, but once you’ve got it working correctly you need to make sure your Flow follows these five best practices.

Elements are Organized

One of the top rules for writing code is using proper indentation.  David Liu (SFDC99) is known for his love (or OCD) of clean code.  Visual Flow’s equivalent to indentation is the alignment of the elements into a clean format.  Think of it like you’re having company over – you would make sure you cleaned your house up before they arrived.

Your Flow should be very easy for you to follow the Flow Elements from start to finish without having to strain your eyes.  Keeping it clean also lets your Flow be easier to make future updates to it.  You don’t have to take apart your Flow to make sure you didn’t miss anything on your update.  So, be sure you spend the extra minute or two to make sure your Flow is sharp looking!

Bad

Messy Flow

Good

Sharp Flow

Naming Convention

In the developer realm, camel Case is the standard.  In Flow, we’re stepping into the developer world without really having to write code.  It obviously isn’t required that you use camel Case as your naming convention, but it is important that you follow a consistent naming convention.  If you don’t, your Flow will be much harder to read.

camel.png

Variable Names

In addition to your naming conventions, you need to make sure your variable names make sense.  I have opened up way too many Flows that use variable names that are not clear. If someone has to do some detective work to figure out what your variable is doing, you need to rethink your variable naming.  Variable naming can often be hard to do correctly, because you have to summarize the function of the variable into a small concise variable.

DoCaseId — Don’tRecordId

Why? RecordId is very generic and does not tell me what Object it is referring to.  I would have to go find where the value was assigned to see the Object it is the Id for.  CaseId is clear and I don’t have to do any research to figure out what it is.

Fault Messages

When your Flow fails its important for everyone to be alerted.  If you’re a Solo Admin, then you can technically get away without using a Fault Message, because Salesforce’s Email Alert will go to you.  However, if you have more than one person developing in your Org, this is a requirement! By setting up a Fault Message, you can easily alert all of the Admins and Developers of the issue.

It is also important to use multiple Fault Messages inside your Flow.  You’re able to customize the Email being sent out to provide specific information that pertains to that particular part of your Flow.  This will help you as you troubleshoot your Flow.

Fault Message

 

Descriptions

Make sure you use Descriptions in your Visual Flow.  This goes along with having your Flow Elements all aligned and easy to read.  You want your Flow to be easily digestible.  It is important to not write blatantly obvious Descriptions, just to write them.  You want to make your Descriptions helpful.

Anytime you have to do something unique inside your Flow you should include a Description to explain what, and more importantly why.  An example would be when you use a Formula in your Flow.

Description.png

 

 

Recap: Think long term when you’re building your Flows (or anything).  Just like you want to create a good User Experience for your End Users, make sure you create a good one for the Admins & Developers that are maintaining the Org.  None of these best practices require a significant amount of time to follow, and the benefits of having a clean Flow will be worth the extra effort!  And if you’re still reading, make sure you check out my The 6 Most Common Visual Flow Errors to Avoid.

 

 

Using the Lead Source Field

Have you ever inherited or walked into a Salesforce Org that was a mess?  You might see a Lead Source field with over 100 values (I’ve seen it!).  Or, maybe you’re adding a new department into your Org and they’re interested in adding some values to the Lead Source.  It is easy to say yes to adding one or two values, but those values can compound over time and your list becomes a complete mess!  This can hurt your ability to have good analytics. In this post we’ll go over some options for how you can work with your stakeholders to add in their different values, but still keep that Lead Source concise.

 

leadsourcedropdown

Dependent Fields

You can create a dependent field and call it Lead Source Detail (you could also create a separate picklist for each ‘sub-group’).  With this dependent field you’re now able to dynamically require additional data to be filled out based on the value of your Lead Source.

Dependent2

Dependent1

Non-Dependent Fields (Lookups & Texts)

The one that jumps out first on this would be the use of Campaigns.  Not as values, like in the first picture, but to use Campaign Source.  In Objects without one you can easily create your own.  The benefits would be:

  • You won’t have to have a Dropdown value for each Campaign, but just 1 Campaign value
  • Campaigns are scalable. You can track history of multiple Campaigns, and with this you can track the first Campaign source easily.
  • Campaigns are what other programs expect that you’re using
    • Pardot
    • HubSpot
    • Eventbrite

How do you require that the Primary Campaign is selected?  With a Validation Rule!  This is how you can make any non-dependent field conditionally required.

What if you’ve already got 100 values in your Lead Source?

The easiest thing for you to do is to make the changes in Excel and then Update Salesforce with the new values for that record.  You’ll need to map them to their new Lead Source value and then update any sub-Lead Source detail field(s) that might apply.

More maintenance

You now have more to maintain, as opposed to simply having one Picklist that you updated and it worked for Leads, Accounts, and Opportunities.  Now, you’ve got more overhead.  Keep in mind you’ll need to make sure that you’ve got everything mapped correctly on your Lead Conversion.  If you run into any issues with the mapping, remember that Process Builder can also do your Lead Conversion mapping for you.

Recap: Lead Source is a field that can easily over time grow from 10 values to 100.  If you don’t put a plan in place on how you’ll deal with the Lead Source field you can easily find yourself in a reporting and data nightmare.  It isn’t too late to change, as you’ve already have the data in your Lead.

Introduction to Salesforce Actions

Salesforce Actions are one of my favorite tools.  If you’ve got a group of Users that are heavily using Salesforce1, then you can really be a rockstar for them by understanding how to use Actions correctly.  But, Actions also work in Chatter Feeds, Quick Actions, and Lightning Experience!  While Buttons are not extinct, Actions are the future and you should look at using them!

salesforce_lightning.jpg

Global Actions

Where can these be used?  These can be used on any Record Detail Pages & Home Pages… so anywhere an Action can be.

Actions

Can be used on Record Detail Pages for the specified Object.  The biggest difference between a Global Action and an Action is an Action allows you to preform a Record Update.

Global Actions vs Actions

Global Actions allow you to build an Action that can be used across multiple objects!  This means, if you have a specific Record Create, Visualforce Page, or Custom Canvas that you want displayed in multiple spots (or maybe just on the Home Page), then this is your best option.  With the Global Action you are able to re-use your Action across multiple areas, which means it takes less effort to develop and is easier to maintain!

Quick Action (Classic) vs Salesforce1 & Lightning Experience

Ability to have different layout for Salesforce Classic compared to Salesforce1 & Lightning Experience.  When Salesforce added Lighnting Experience they did not group it into the Quick Actions layout, but instead added it to the Salesforce1 Action layout.  So, if you currently are using Lightning Experience, the layout (at this time) will have to be the same between desktop and mobile.  Down the road Salesforce might split this up into a new layout so that we can once again have different actions for the Desktop than our mobile devices.

Action layouts for each object are predefined by Salesforce, but you are easily able to override and drag-and-drop Actions around in the layout (just as you would a Field).  If you customize the Quick Actions (Classic) layout, but not the Salesforce1 & Lightning Experience layout, then the Salesforce1 layout will mirror the Quick Actions layout.

Actions Layout.jpg

Each Action has its own Layout (Works with Record Create, Record Update, and Log a Call)

One nice thing about Actions is how easy it is to drag-and-drop the fields that you want to be displayed for your Action.  Pretty powerful!  Combine with Predefined Values and you’ve got the ability to really streamline the experience!

Your Layout.jpg

Predefined Values (Works with Record Create, Record Update, and Log a Call)

With Actions, one of the biggest selling points is the ability to use Predefined Field Values.  This allows you to save your End Users time entering information (just as you would ‘pre-populate’ fields with a button URL hack).  You’re able to reference the Object that you’re on (if applicable), and the System Fields like the Running User and Custom Settings.  If you choose to display these values on the Action Layout, the End User can change the default value if needed.  If you don’t need the End User’s input, then simply remove it from the layout and the Predefined Field Value will do the rest.

Predefined Value.jpg

Action Design Considerations

Have you noticed that both Global Actions and Actions allow for you to select Log a Call as a type of Action?  All this really is doing is setting some predefined fields/layout changes for you, but it is still a Record Create of a Task.  The benefit, besides not having to set some of those predefined values, is that you get a beautiful Custom Icon!  When you are creating your Actions, be it a Visualforce Action or a simple Record Update, make sure that you’re using the Lightning Design System to use an appropriate Icon.  User Experience matters!
Lightning Design5

Lightning Design6

As of the Spring ’16 Release, we have the ability to now use Success Messages for our non-coded Actions (Record Create, Log a Call, and Record Update)!  This is something small (just like picking a Custom Icon), but it really does enhance your the User Experience of your Action.

Success Message 1

Success Message 2

Sometimes the Chatter Feed can get annoying if every little thing done shows up.  This issue  was also resolved with the Spring ’16 Release, giving us the ability to choose whether or not we want to Create Feed Item with our Action for any Record Create (includes Log a Call).

Create Feed Item

 

How to work with Related Records in Process Builder Criteria

When Process Builder first came out, the lack of error messages made it hard to adopt.  I have noticed from looking at the Salesforce Answers Community, confusion with Process Builder errors is a very common.  In this post, we will cover one of the most common mistakes for someone learning Process Builder – how to work with related records.

What do I mean by related records?

Anything that is referenced through a Lookup Field on an Object (including System fields like Created By).

lookupfield.jpgWhen you’re working inside Process builder, you’ll see a chevron next to any related object that you can navigate to.  This lets you then reference the fields of that Object in your Criteria and Actions.

RelatedRecords

This works like a charm, until you decide to have a Process Builder reference a Lookup Field that is not populated (so the value is null).

failed.jpg

Yikes!  We never want to see that error stopping an End User from saving a record!  What happened?  Salesforce will tell you in your Fault message (emailed), the variable “hasn’t been set or assigned.”  What does that really mean though?

You were trying to reference a related record, but your Lookup Field does not have a value or record in it.  This isn’t documented very well, and is an easy mistake almost everyone will make as they learn to use Process Builder.  This is a new problem for Admins, because we do not run into this issue with Formula Fields and Field Updates (in a Workflow Rule).  And, this is a serious problem because it actually can affect an End User’s ability to make a new record and/or edit an existing record.

So now that we know the problem, how do we fix it?

  1. Check for Null
  2. Formula Field

Checking for Null is the approach that I prefer to go with.  Either one can technically work, but I choose to keep my Objects as simple as possible and avoid adding excess fields.

For our example, lets say that we wanted to run some automation for our Opportunity when the Primary Campaign is Type = Trade Show.   We’d first need to make sure that our Opportunity actually has a Campaign associated to it, otherwise we’d get that failed to execute the flow error.  So, how do we do it?

Campaign ID >  the Related Record, ability to reference Campaign Fields.

Campaign ID  the Campaign Lookup Field on the Opportunity.

CampaignLookup.jpg

 

That means that the Campaign ID Field houses the value of the Lookup.  Which means we can check to see if there actually is a value!

SelectCampaignId

CheckforNull

Now, we are able to add the rest of our conditions that reference our related Campaign record.

Note – we must to check for Is Null BEFORE we reference the related record’s fields.  Salesforce checks our criteria from Top to Bottom.

typetradeshow.jpg

We can now reference fields on related records in Process Builder because we first validated that we had a related record.

How to Create a Conditional Auto Number with just Process Builder

A few months ago I did a post on creating a Conditional Auto Number using an Autolaunched Flow.  In the comments, I mentioned that you could actually solve the solution using only Process Builder.  It seemed like that idea had some interest from people, so I wanted to turn it into a post.  With Salesforce (for better or worse) there are so many ways that we can accomplish the different solutions we come up against.

Automation Overview:

  1. Account Meets Criteria – Process Builder #1 triggered (Record Create Action)
  2. Custom Object Record with Auto Number created – Process Builder #2 triggered
  3. Update the related Account record with the Auto Number value

What fields do we need create in this Custom Object?  Just one! A Lookup to Account.  Also, we need to make sure we set the Name to be an Auto Number.

AutoNumberObject.jpg

HINT: If you ever need to reset the number, you can switch the Name field to Text and then back to an Auto Number and it will let you pick the Starting Number again.

Here is what our finalized Object looks like:

customobject

Now that we have our Object ready, we can go create our first Process Builder (Setup | Create | Workflows & Approvals| Process Builder).

createpb2

We want the Process Builder to fire on our Account, so for our object select Account, and for starting the process select when a record is created or edited.

PB1.jpg

This next step is completely on you for when the record meets the criteria.  For my example we will just use when the Type is now a Customer.  Careful with the Advanced section at the bottom, you aren’t going to want your Process Builder to fire more than once per Account!

NewCustomerCriteria.jpg

Now we get to setup our Immediate Action of creating our Client Number record.  All we need to do is pass in our Account Id.

pb6.png

Hit Save, and then hit Activate up in the top right corner… and lets move on to our next Process Builder!

createpb1

We want the Process Builder to fire on our Client Number Object, so for our object select Client Number, and for starting the process select only when a record is created.  We don’t need to do this action any other time.  Tip: if you’ve got something you need to run on Create, but you have more than one Process with it you can always use IsNew() in your criteria.

pb2.png

Since this is the only action we will have on the Client Number Object, and we know the Account will always be filled out, you might want to use the No criteria – just execute the actions! option.  However, I chose to validate that I first have found an Account value, because strange things can happen.

pb3

Now we get to setup our Immediate Action of updating our Account record with the correct Client Number value.  We need to make sure we set this to update on the Account Object.  If you notice, I didn’t choose the Account> option, because that would be if I wanted to update a record related to the Account.

pb4

All that is left for us is to set the Account Number to be updated with the reference to our Client Number’s Auto Number value.

pb5

Hit Save, and then hit Activate up in the top right corner… and you’re done!

The Power of Formula Fields in Visual Flow Bulkification

Often times I find myself in a situation where I need to reference a value from within a Visual Flow that is not on the Object I am working with.  As we’ve talked about in a few of my recent posts, the biggest trick to bulkification is reducing the amount of queries that we are using.  These queries count against our limits in Visual Flow and Process Builder.  So, how does a Formula Field play a role into reducing our queries?

Lets say we’re in a brand new Org.  We’re working on a Flow from the Contact Object, and we need to reference the Account Name for a naming convention on the Task we are going to create.  The problem?  It isn’t there for us.  All we have is AccountId.

AccountName1

This is not a problem that you’re going to find in APEX, because APEX has Dot Notation.  Unfortunately in Visual Flow we don’t have Dot Notation (or anything similar) at our disposal for us to navigate through a Lookup Field (vote for the idea here).  Update: Gorav Seth pointed out that we can actually do this with a Fast Lookup, just not a Record Lookup.

However, we can use that AccountId to query the matching Account to get the Account Name.  But, should we?  Lets say that this Flow was being launched from a Button or Action, and there is no way that we’re going to ever have this running with another Flow or Process Builder.  In that case, bulkification is not a factor (performance still is), and we probably are okay to add that extra query.

But, if you’re looking to bulkify your Flow, you’ll want to think twice about adding another query.  It might be smarter to simply create a Text Formula Field on the Contact Object that gives us the Account Name value.

Navigating a Lookup Field.jpg

We obviously don’t want to start cluttering up our Contact Object with extra fields, but we do need to weigh the pros and cons of the situation.   We won’t add this field to any Page Layouts, but is adding a field called Account Name going to confuse potential End Users that might see this in their List View or Reports?  The answer to that depends on your Company or Client.  In most cases the field you’re going to create will most likely be something that most End Users would overlook (if they saw it), but you do need to keep User Experience in mind.

As the Admin of my Developer Edition Org, I had a company-wide meeting and unanimously determined that there was not going to be a negative impact of adding an extra field called Account Name.  When I went to create my Account Name Formula Field, I made sure that I left a very good description so that everyone why it was created and where it is being used.  

After creating the Formula Field, we now have our Account Name available on the Contact Object without having to do an additional query.

AccountName2

And just like that, we have reduced a query in our Visual Flow and further bulkified our Contact Object!

NOTE: When dealing with Large Data Volumes (LDV), you want to avoid filtering your query with a formula field, as it can slow down the performance of your query (be it APEX, Reports, List Views, or Flow).  In most situations we are not going to use our Formula Field in that way, but it is important to keep this concern mind.

Flowception – How to use a Flow inside another Flow

Have you ever found yourself reusing a Flow over and over?  Maybe its to calculate something or its a series of Lookups and Decisions that you always use on your Accounts, Opportunities, or Leads?  With Flows we have the ability to use Flows inside of other Flows.  But, why would we want to do this?  If I am honest, this was one of those areas of Visual Flow that I never really used until I started to get into actual code.  When coding, I learned to create a common area of methods that I can call from any Apex Trigger or Apex Class, and now I have reusable pieces of code.  Why does this matter?  Well, when changes happen… and they always happen… we only have to go to one spot to make the update to that particular method!

flowception.jpg

As you begin to use some of the same logic over and over in your Flows, you’ll have to keep rebuilding that same piece of your Flow.  I don’t know about you, but that really doesn’t sound fun to me. Think Flowception like using Custom Settings or Custom Metadata, you have multiple Process Builders or Flows that reference that data, and when you need to make a change you only have to make the update in one place.  With using Flows in the same way that we might use an Apex Class or Custom Settings, we can save time as we build new Flows and as we make updates.

Now that we’ve covered why you would want to use a Flow inside a Flow, lets show you how simple it can be!  For my example, I’ve got a Flow that I’ve built that cleans and parses out a multi-select value and turns it into a collection variable, so that you can loop through each value and apply your criteria.  If you think this sounds somewhat familiar, you’d be correct!  That is because there are two near identical posts out there (by some very respected and active people in the Salesforce Community):

  1. Rakesh Gupta (Automation Champion) (Parsing Multi-select ID Values from a Flow Interview)
  2. Mayank Srivastava (Suceed with Salesforce) (The exact same example I’ll be using)

This past week I had two different clients that needed to parse through a Multi-Select. Unfortunately, Rakesh’s managed package that parses Multi-select ID values did not work, because both solutions needed to be Autolaunched Flows (and I was using strings and not IDs).  So, I built it myself.

If you read Mayank’s blog post, you’ll see there is quite a lot going on to parse the multi-select value:

  1. Remove brackets
  2. Add a semi-colon to the end
  3. Separate each string value between the semi-colons
  4. Add those values into a collection that can be used

Why would I want to rebuild this complex piece of logic in every Flow that I need to parse out a multi-select value?  That makes this is a prime example of a Flow that acts as a calculation or formula that could be reused across many different Flows (and Orgs).  It is on my to-do list to do what Rakesh did and package this up so others can reuse this… stay tuned!

Now that we know what our example Flow is doing, lets jump into our Visual Flow Designer!  I’ve got quite a lot of Flow’s in my Org, so I am going to use the search at the top to find the Flow I am looking for and drag it into my canvas.

DragFlowOutInFlow.jpg

Now, if you remember my post on Visual Flow Resource Tutorial – Input & Output Type, I pretty much said don’t worry about your Input and Output type.  That is true, as the only downside to putting everything as Input & Output is that it clutters what you’re seeing when you go to assign values to your variables.  But, when you get into reusing a Flow, you’ll want to start considering cleaning up which variables are input and which are output.  That way you can make it as simple as possible to reuse.

If you notice for my Flow, I only have one input and one output variable, and they are worded clearly so you know how to use it.

Flow Inputs

Flow Outputs

All that is left is for me to assign the Source (child Flow) values to the Target (Flow you’re building).  So lets do that.

Flow Inputs 2

Flow Output 2.jpg

Note: If you have additional values that you need to pass into your child Flow, all you need to do is use the Add Row option, just like you see in any other element.  Also, you have the View input/output of other versions, which allows you to look at the variables in versions other than the Active one for that Flow.

Now, all we need to do is finish the logic of our current Flow, and we get something that might look like this.

FinishedFLowExample.jpg

RECAP: Using a Flow inside of a Flow is a powerful way to build something scalable with Flow.  You can save tons of time by building reusable pieces of Flow that you find yourself commonly using.  By doing this you are not only saving time, but you’re also building something that will make any updates down the road easier.  When you find yourself doing something in more than one Flow, you should consider putting it in its own Flow.