How to add Quick Actions and a Link in Wave Analytics

If you’re using a Table inside your Dashboard or Lens, as you start to drill down into the data you probably want to either navigate to the record or perform an action. Currently, that is not something Wave is setup to do out-of-the-box.  While this is not a very hard thing to setup, it could be somewhat confusing for any Administrator that is trying to learn Wave.  By the end of this you’ll post you’ll hopefully have no issues adding the Open Record and Actions to your Dataset, and understand some of the quirks associated with the feature.

The first thing to note, is this is Dataset specific.  This change has to take place on every Dataset that you want the ability to drill into.

Before we get started, let’s see what we’re going to accomplish in this blog post:



Quick Actions & Record Open Enabled


Navigate to your Dataset

We want to navigate to our Dataset by selecting Edit under the Dataset.


Download the XMD JSON

You’ll see a blue download icon, hit that to download the file.


Open & Reformat the JSON

When I open the XMD file in Sublime, you’ll notice it isn’t formatted in a readable way.  I would recommend getting a plugin that will reformat this for you.  If that isn’t an option for you, no big deal, I’ve found this site to be great at formatting and helping you troubleshoot errors.  After it is formatted, it should look something like this (if you’re working with a clean Dataset):


Understanding the Parameters

Great, so we’ve got the code formatted to work with now.  Let’s talk about what paremters we have available to work with:

  1. recordIdField
    • This is the field that enables your Actions and the Link to the record.
  2. Field
    • The name of the dimension that the menu appears on in dashboard and lens charts and tables.
      • Let me make sure it is clear — you can not add this to a Measure
    • This ideally is a unique value to enhance the end user experience.  If it is not, make sure you use the recordDisplayFields parameter to improve the user experience.
  3. recordDisplayFields
    • If you put your action and record open on a field that isn’t unique in your table, Salesforce will ask you to select the record that you want to work with.
  4. linkTemplate
    • The default for this is to the Record Id field (the row’s Id).  However, you can use this parameter to setup a custom URL that you send the User to.
  5. linkTooltip
    • This is used if you want the Record Open to have a hover message.
  6. sfdcActions
    • By default the Actions will be displayed as your Page Layout’s Actions.  If you want to modify the values in Wave, then you’ll want to customize this to create your own custom list.
  7. linkTemplateEnabled
    • Default is TRUE.  Set this to FALSE if you want to turn the Link off and only have the Actions.
  8. salesforceActionsEnabled
    • Default is TRUE.  Set this to FALSE if you want to turn the Actions off and only have the Link.

What it looks like together


Update the XMD JSON

Now you just need to upload the updated JSON file into the Dataset, and then hit Update Dataset


Select Update Dataset


All that is left for you to do now is run your Dataflow again so that our updates are put in place.  After your Dataflow finishes running, go in and validate that you now have the Record Link and Quick Actions working!  It looks like this:


I would recommend looking at this article if you want to do a deep dive into this.

How to create a Top 10 List in Wave Analytics

Often times you’ll find yourself wanting to have a Top 10 list chart.  In Sales, it typically is around your largest clients or the biggest deals in your pipeline.  In Customer Service, it is typically around what customers are opening the most cases.  This is something that is really easy to do within Salesforce’s native Dashboards chart, but not as straight forward as you’d expect in Wave (for the time being, they’ve quietly been making some really great improvements).  We’re going to walk through the steps to show you how easy it can be to do this, if you just know where and how to apply the filter.

Create a new Lens

You do this by clicking on the dataset you want to use for your Lens.  You can also create a Lens (technically a Step) inside your Dashboard.  For this scenario I prefer to just do it this way instead.


Group your Lens by Account Name

This grouping can really be whatever you’re trying to do a Top 10 by.  Also, you can add in a secondary group if you want to have a stacked chart.  For this post, we’ll keep it simple and just use one group.

Select Account Name.jpg

Sort your Lens by Descending order

Dsc Lens.jpg

Go to your Lens’ JSON editor

To access this, you’ll use one of this keyboard shortcut: CRTL+E (Windows) or CMD+E (Mac).  If you need more information on the keyboard shortcuts available, check out this.

JSON view in lens.jpg

Add in the your record Limit

This is going to take place inside the “query”.  It is a really simple line that you just add in.  It doesn’t matter if you place it above “groups” or below “measures”, it just goes anywhere inside of the “query”.


Add in the Limit.jpg

Clip your Lens to the Designer

When you clip your Lens to the Designer, you’re now able to grab it inside your Dashboard.

Clip to Designer.jpg

Add the Step/Lens to your Dashboard

Drag out the Step/Lens to your Dashboard and you’re all set.  This will change as you slice and dice your data and show you a dynamic Top 10 list.  If you want to keep your list static and not faceting with the changes in your dataset, you’ll want to turn that off in your Step’s settings.

Drag Lens out to Dashboard.jpg

With that, you’re all set.  As you hopefully can see, it really isn’t very hard to do, but it can be confusing at first to know where to put in your filter.

Note: You are able to edit the JSON of your Lens/Step in your Dashboard.  I chose to do it separately in a Lens to simplify the editing of the JSON.






Parse a Multi-Select Value in Visual Flow [Unmanaged Package included]

In my post on using a Flow inside another Flow, I mentioned wanting to create a Flow that could be re-used for the problem of needing to parse a Multi-Select value.  So, here it is!

Unmanaged Package:

Let’s talk about what is in this Unmanaged Package, so that you understand what you’re installing into your Org.  I want you to be able to easily reference this Flow for any use cases you might have.  So, that is why it is listed as Unmanaged and why I’ll have this detailed blog post on what is going on.

Flow Overview



Let’s talk about what each of these Elements are doing.

Remove Brackets

The Remove Brackets Element is cleaning up the input String that we have.

Remove Brackets Formula.jpg

The Formula (sorry, it doesn’t want to stay formatted for me):

) + “;”

Note: I am cleaning up the original Input variable.  After I clean the variable, I am assigning that new value (my Text Formula above) to the new Text Variable called Multi_Select_Value.


Add Left Value

What we want to do now, is grab the Left value in our String and add it into a Collection Variable.  This will be what you can Loop through to perform login on.

Grab Left Value Formula.jpg

The Formula:



Remove Last Parsed Value

Now that we’ve successfully added the first value into our Collection, we want to remove that value and its semicolon from the String.  This will allow us to then see if we have remaining values or not in our next element.


The Formula:



Remaining Values to be Parsed?

All we’re doing here is checking to see if the value of Multi_Select_Value is null or not.  If it is null, then we want to exit the Flow and send out our Output.  If it is not null, we want to continue along and keep parsing until we have a null value.


How to Guide Users Submitting Records for Approval with Visual Flow

I’ve often thought that the Submit for Approval Button in Salesforce could use some work.  It really doesn’t give the User any good information for why they might not meet the criteria for submitting their record for approval.  Isn’t there a better way?  I think so!  With the use of Visual Flow we’re able to guide the User through a tailored experience to help them submit their record with ease!

We’ll do this by querying the record(s) that we need to access, and then using decisions to determine what might be missing and present the User with the option to update the key fields missing.  In my example I’ll just keep it simple by looking for the Amount field.  If they haven’t filled out that value already, we’ll ask for them to update the Opportunity with the Amount before they can proceed to submitting the record for approval.  Let’s get started!

Navigate over to create a new Flow. (Setup | Create | Workflows & Approvals | Flows)

New Flow

The first step is going to be grabbing our Record Lookup.


We’ll need to set the Record Lookup to find the Opportunity that matches the Opportunity ID variable we setup (and pass in through our Button – see How to write a Button URL for your Flow if you need a refresher on this).


I’ll also create a variable to store the Amount of our Opportunity.  This will allow us to reference the value.


Note:  We could technically pass additional values in our Button, or any number of fields that we want to (besides Currency to Currency, is a limitation within URL).  Regardless of the ability to do it or not, I like to try and keep the complexity in one spot (in the Flow), as opposed to multiple (the Flow and Button).  Also, we’re not expecting this to run in batch as it is only going to happen when a User clicks the button, so we’re not as worried about an extra query (typically).

Alright, so we’ve got our Amount field.  Now, we want to drag in our Decision Element to determine if we found a value in it or not.


For our example, all we need to check is if the Amount is greater than 0.  We’ll use the Default Outcome in this scenario to take our User to a Screen to fill out the Amount before we submit for approval.  If we were checking multiple fields, this decision logic could get more complicated (depending on how customized you wanted to the experience to be).


I enjoy finishing a part of any automation I setup, so lets drag in our Submit for Approval Element and knock out this part of our Flow.  Then we can worry about the Default Outcome routing.

Submit for Approval drag.jpg

All you have to do is pass in the Opportunity ID as the Record ID.  Nice and easy!


Great, so let’s jump into the other route of the Decision, when someone needs to fill out the Amount of their Opportunity.


On our Screen, we simply give a nice message to our User alerting them of what is expected.


I would recommend passing in variables like the Opportunity Name, Account Name, and other key fields into your Text Template.  You want the User to be confident of what record they’re currently updating.

We’ve now got to drag out a Assignment Element and update our Amount variable with the entered Amount.  I like to use Assignments after Screen Elements so that if I’m using multiple Screen Elements I can consolidate the values into one variable.


Now, make sure you’re setting the variable value to the Screen Input field correctly.  It can be easy to make a mistake here and assign the wrong value!


We’ve now got to drag out a Record Update and update our Opportunity with the entered Amount.


Now we just need to add in the Amount field to our Record Update.  We can use the Amount variable here, because we just assigned the Screen Input value to that variable.


From here, I find the easiest thing is to just route this back to the original Decision and see if it meets the criteria to proceed on.  You can determine how strict and customized you need your routing to be, but if you can keep it simple try to do so.  Mapping the Record Update back to the Decision Element gets us our finalized Flow.


Let’s Save the Flow and then Activate it.



Now, let’s go create a new Button on our Opportunity   (Setup | Customize | Opportunities | Buttons, Links, and Actions)


For the Button you’ll want to go grab your Flow’s URL.  This was on the Flow Detail page.


Paste that in, and we’ll add in the variable assignment for our Button.


Save, and then drag the Button onto your Opportunity Layout.  You’ll want to check the API Name when you hover over the Button to ensure you’ve selected your Custom Button and not the Standard one.

Add To Layout.jpg

All that is left is for you to test it out!


Hopefully this post was able to stir up some ideas of what is possible for you to do within your own Org!









Tailoring your Wave Dashboards with the Layout Manager

One of the things that Wave has recently transitioned from having the Flex Designer as BETA and making it now the Standard Wave Dashboard Designer.  Now that it is out of BETA we have tons of new features available that really allow you to create some fantastic layouts tailored to different devices and screen resolutions.  The beauty of the Flex Designer (now called Wave Dashboard Designer), is that it would change the different charts, filters, and other pieces of your Dashboard based on the size of the monitor.  Note: there were previously other ways of doing this, but now Salesforce has made this extremely easy!


When you’re editing your Layout’s properties, you now have the option to control the amount of columns and their spacing.  This gives you more control than before when you’re trying to make a beautiful dashboard.


Columns determines how many columns your Grid will have.  The more you have, the more control you have with your different dashboard elements.  I’ve yet to hear of any downsides for bumping it up to 50 columns (the max).

Cell Spacing is how much space is between the different cells or blocks on your grid.  You have the option of 0, 4, 8, and 12.





The Maximum Dashboard Width plays into our next section on the Layout editor, Device.  This is where we get to control what devices and monitors will work with this Layout.


Screen Width allows you to set ranges that this Layout will work for.  In this image, I’m creating this for really large screens only, and I’ve just set a minimum width for the layout.  For my Standard layout I used both the minimum and the maximum width values.  Note: these numbers are in pixels.

Orientation is whether or not you want to make the Layout only work for Landscape or Portrait orientations.  It defaults to all, but having the ability to dynamically change it also based on the device’s orientation is fantastic!

Platform allows you to determine if your Layout works for iOs, Android, or both.

How does it all tie together?

When you’re editing your Dashboard you’ll see your Layout dropdown to the left of the back and forward arrows.  You can see here that I’m able to create my own Layouts for one Dashboard.  This gives you full control now over how the Dashboard will look at multiple aspect ratios.


Let’s take a look at this in action.  Below, I’m presenting you two very different Dashboard Layouts inside the same Cases Dashboard!  The first screen shot is for Large Screen Users, and the screen shot is for iPad Pro Users.  Notice, I can now add a variety of charts and filters based on the specific layout without any heavy lifting!

Large Screen View


iPad Pro View


How to Troubleshoot Visual Flow & Process Builder with Debug Logs

This is the second of three posts on Troubleshooting Visual Flow & Process Builder.  You can checkout the first post on using the Fault Emails here.  The Fault Emails are great and solve close to 90% of the Flow and Process Builder errors that I have.  However, sometimes it just isn’t that simple.

A Quick Recap … When I’m looking to fix a Flow there are typically three routes that I use:

  1. Fault Email
  2. Debug Logs
  3. Screen Elements & an Assignment Element (I’ll be covering this in its own post after I present on it for my Salesforce Automation Hour Presentation — so register now and see it first!!)

As I mentioned in my previous post, I think overall #1 and #2 are the most common ways that people will test and debug their Visual Flows (and Process Builder, since there are no screens or variables).  This post is going to be an overview on how you walk through the Debug Log, and go over some basic reasons why you would want to use the Debug Log.

Why do I typically drag the Debug Log out when I hit a tricky problem with my Flow or Process Builder?

Debug Logs gives you the full view of what is going on.

I was recently assisting a friend with a Process Builder issue they had.  We walked through the different Criteria, and everything seemed to be setup perfectly.  We went to test the automation, but nothing happened.  There were no emails, because nothing was broke in Salesforce’s eyes.  However, something wasn’t right.  Was our Process Builder’s Record Update setup incorrectly?   Did our test record not meet the criteria?  Those types of questions can be difficult to answer without the Debug Log.

I imagine that I’m not alone in this situation of wondering why a Process Builder or Flow isn’t running as intended.  If your process is large, it can be very time consuming to walk through everything and re-validate multiple times as you try to find the cause.  It takes a lot less time for you to setup a quick Debug Log and truly see what is going on.

New to Debug Logs?  Take a look at this article: Set Up Debug Logging

Debug Logs allow us to to see everything that happened during the Save process of a record.  Need a refresher on what the Order of Execution is, check it out here.  You’ll find Processes as #13 on that list.  That means by reading the Debug Log I am able to see if my Process actually was triggered or if it didn’t meet the criteria.

That is just one scenario when a Debug Log will come in and save the day.  My second example is if you are hitting an error, but the Fault Email doesn’t give you the full picture of what exactly is causing the error.  You need insight into seeing all of the Validation Rules, Workflow Rules, APEX, and other events that occurred when the Process Builder and/or Flow ran.   I’ve had a headache before due to a Workflow Rule I didn’t realize was overwriting my Flow’s field update.  The cause will be different based on the Org and Object, but typically this happens more often on your busier Objects or processes that create/update multiple Objects.

If you’re new to the Debug Log, start with Info and then move to Fine or Finer if you’re not getting the information you need.

Reading a Debug Log might seem complicated at first.  Salesforce put together some great documentation for you to understand what each Event Name means.  I would highly suggest giving this documentation a read.  I’ll give you the two big ones around Flow to remember:

    • Tells you that you’re starting the flow transactions (#13!)
    • Tells you that you’ve exited your flow transactions (on to #14!)

The rest of your Events between those two will house what is going on with your Flow/PB.  Do a quick search/find in your Logs on either of those two Event Names, and you’ll get to where all your Flow Events are located.  There are a total of 38 of these different Flow Events – so I’m not going to go into detail here of what each Event means.

I hope to get this updated (in the near future) with some images of the debug logs. They were hard to read, so I removed them for now.  

RECAP: If you want to take your debugging skills to the next level (and save yourself tons of time), learn to use the Debug Log.  Hopefully you have a better idea of when you’d want to look to use a Debug Log to troubleshoot your Flow.  Don’t restrict this to just your Process Builders and Flows… this works on troubleshooting everything you’re configuring!

Salesforce Automation Hour

Join us for the Automation Hour’s second session next Friday (October 14th @12pm PST)!  I’ll be joined with my co-hosts Jen Lee and Rakesh Gupta.  You can visit our site for a full list of upcoming webinars and past recordings here.  We’ve also setup a Success Community Group here for you to be able to ask questions if you watched a recording or simply are stuck with a Process/Automation question.

What exactly is Salesforce Automation Hour?

Salesforce Automation Hour is a webinar series that we’re running to allow people to share automation tips and tricks with the community.  These sessions will be varying from beginner to advanced Users.

What is a typical format?

We have the host jump into their automation presentation.  These will typically range from 15-30 minutes depending on the scenario.  After the presentation is over, we’ll send it back to the group of co-hosts to answer any questions that the webinar attendees have for the remainder of the time.  These questions are typically related to the presentation, but they do not have to be.

How can you participate?

Our goal when starting this was for it to be something that anyone can be a guest host!  We’ve already got tons of fantastic guest hosts lined up for future webinars, but there is room for even more!  Jump over to our contact us form and just give us an idea of what you’d like to talk about.  There are no requirements, like having a certain number of badges or certifications to be a guest host.  If you missed getting your presentation selected at Dreamforce – be a guest host!



How to Troubleshoot Visual Flow & Process Builder with Fault Emails

Visual Flow is a fun tool that I really enjoy.  What I don’t enjoy, is attempting to debug issues within Visual Flow (or Process Builder).  It is not the easiest thing to work with, and there are a number of areas that you need to watch out for as you build your Flow (see The 6 Most Common Visual Flow Errors to Avoid).  Try as you might, you’re going to run into some sort of error as you work with Flow that is going to give you a headache trying to debug.  In this series I will go over some of the different tricks I use when I am debugging a complex Visual Flow.

When I’m looking to fix a Flow there are typically three routes that I use:

  1. Fault Email
  2. Debug Logs (covered in an upcoming post)
  3. Screen Elements & an Assignment Element (I’ll be covering this in its own post after I present on it for my Salesforce Automation Hour Presentation — so register now and see it first!!)

I think overall Fault Emails and Debug Logs are the most common ways that people will troubleshoot their Visual Flow and Process Builder.  In this post we’re going to just cover our Fault Emails.

The Dreaded PB/Flow Error Message – Ooops! What went wrong?  I have no clue, lets check the email Salesforce just sent us.


The Unhandled Fault Email

The Email solves 90% of the Flow errors that I encounter.  The vast majority of your errors are going to be quick fixes that you can spot easily from your email.  Let’s take a look at the email message we get:

Fault Email.png

What is highlighted in yellow is the key to the whole Email.  The rest of the email is there to help you understand what steps the Flow took on its way to the error.  This lets you walk through and see each element or criteria that your Process Builder/Visual Flow is hitting.  This can be important depending on your Email’s error, you can quickly check an ID or other value that is being used.

In the above email we’re just working with a Process Builder that is failing.  We get this error: (FIELD_CUSTOM_VALIDATION_EXCEPTION) Only Hobbits can change the Account Type

Let’s break this Error Message into two separate parts:

  1. What Caused the Issue 
  2. The Error Message 
    • Only Hobbits can change the Account Type

Based on this message I can quickly tell that we hit a Validation Rule error and it was because I was attempting to change the Account Type, but I’m not a Hobbit.  So, we now know that we need to either change our Process Builder or Validation Rule to fix this error that we hit.

So we solved the first one, that wasn’t too bad.  Let’s take a look at another Error Message that we might run into.


Once Again, let’s break the Error Message into two separate parts:

  1. What Caused the Issue 
  2. The Error Message 
    • Owner ID: owner cannot be blank

Based on this message it looks like I didn’t assign a value to the Owner Id variable that I created.  Rookie mistake, but something easily fixable.  My next step would be to make sure the correct ID is being passed into that field and then give it another go.  This is a good example of how you can walk your error message all the way to the actual Element you failed at to see what the values were.  I highlighted the specific part of my Flow that is causing the error.


If you get an email where the Error Message doesn’t make sense, Google is your friend!  Seriously, when I searched our first Error and I found over 1,700 results!


RECAP: A quick understanding of what you’re getting with the Fault Email will save you lots of time when you’re troubleshooting an issues you’re having with Process Builder or Visual Flow.  If you don’t recognize an error message, simply Google it!  Don’t get too caught up with all the details that Salesforce sends you, focus on the error message and then look to see how you can resolve that error.


Understanding how Two-Column Screens work in Visual Flow

When I saw the release notes for Winter ’17, I was very excited about the ability to have two-column screens inside of Visual Flow.  When I first published my release notes highlights, there wasn’t any documentation out on how this was going to work.  Salesforce just published the Developer Documentation around the Winter ’17 Preview, and now we can start see the features with more clarity.  So, let’s dive right into this new feature!

You can find the Developer Documentation here on this feature.

Pre-requisite: You must Enable Lightning Flow Runtime for Flows to be able to use this feature.  From Setup, enter Process Automation Settings in the Quick Find box, then select Process Automation Settings.  Select Enable Lightning Flow Runtime for Flows.  Save your changes.

How can you use the Two-Column Layout?

Through a URL Parameter into your Flow, just like you would the Record ID or another variable.  Take a look my post on How to write a URL for your Flow if you need a refresher here.  It is going to look like this:


If you’re dropping your Flow into the Lightning App Builder using a Flow Component, you can also control the Layout in that component.  Simply choose the Two-Column Layout in the Flow Component’s Layout selector.  This defaults to One-Column (as you would expect).


How does the Two-Column Layout work?

Very similar to the standard Page Layouts.  You can determine the order of the fields, and every field alternates from left to right.  Be warned, it can look somewhat funky when you have fields that are not all aligned.


Things to keep in mind…

The Layout is for ALL Screens in your Flow

Let me reiterate this.  When you select your Layout, this is for ALL Screens inside your Flow.  You simply can’t control the column layout at the Screen level.  Another thing to keep in mind, is you’re selecting the Layout when you’re using the Flow.  This is all done in the URL or in the individual Flow Lightning Component – not when you Save or Activate your Flow.

Only available with the new Lightning Skin

Your Flow can be viewed in both Single and Double Column layouts.  If you have a Flow exposed on a Visualforce Page, you will not be able to select Two-Column Layout (at this time).  Flow’s launched by Visualforce will not use the new Lightning Skin, and thus this feature is not available.


Tab-key Order not customizable

You’re unable to change user’s Tab-key Order in the Two-Column layout.  It is automatically set to Top-Down.  If you’re not quite sure what I mean, the Tab-key Order is something that you’ve see in every Section Properties in a Page Layout.  This is not a huge issue to me, but I think it could annoy your Power Users who use Tab-keys efficiently.



The Two-Column layout doesn’t care what the size of the user’s screen is.  Which means it is not mobile responsive.  This is something you’re reminded of in the Lightning App Builder through a Help Bubble, but not when you’re using a URL parameter.  Make sure you keep that in mind when you’re deciding to go with a Two-Column Layout.


Recap: The new feature of having Two-Column screens comes with some drawbacks.  We’re not able to control Screens separately inside one Flow.  Right now if you’ve got something that you want to be accessed through a URL button (and not a Visualforce Page housing the Flow), then this will be a great solution for you.  I am hopeful this is just the beginning and we’ll soon be able to customize this at the Screen level, but we’ll see with time if I’m being overly optimistic.

How to use Case Comments with Communities in the Service Console Feed View & Salesforce1

This past week I had someone who is looking to use Case Comments in the Service Cloud, but wanted it to be listed as an Action in the Feed.  I thought it would be a good use case of many different tools within Salesforce being used together.  I am looking at possibly doing this with code and basing it off this post, but for now I figured that I’de show you how without code.  Let me be clear that if you’re not using a Community that you can simply use the Internal Comments field instead without having to do anything.  The only negative of going with this solution is that you’re not going to have your Case Comment Chatter Post visible until your Chatter feed is refreshed, but that is something that also happens with the Internal Comments field.  The Case Comment record is visible instantly.  And this works nicely with Salesforce1.  With that said, let’s jump right in!

Automation Overview:

  1. Inputs for Case Comment received (Action)
  2. Process Builder triggered (Pass inputs into Visual Flow)
  3. Case Comment created in Flow

For this solution we have two different options in how we can do it architecturally:

  1. Record Create – Create new Custom Object
  2. Record Create – Create new Task Record
  3. Record Update – Use Custom Fields on Account/Opportunity

For me, because of not wanting to further complicate the Task Object and not wanting to add excess fields to the Case Object, I’m going to go with option 1 and create a new Custom Object.

How will we build this?

  1. Create the Case Comment Extension Object
  2. Create our Visual Flow to create the Case Comment
  3. Create our Process Builder to launch the Visual Flow
  4. Create our Action on the Case

For this solution we have two different options in how we can do it architecturally:

  1. Record Create – Create new Custom Object
  2. Record Create – Create new Task Record
  3. Record Update – Use Custom Fields on Account/Opportunity

For me, because of not wanting to further complicate the Task Object and not wanting to add excess fields to the Case Object, I’m going to go with option 1 and create a new Custom Object.

What fields do we need create in this Custom Object?

  1. Auto Number
  2. Case (Master-Detail)
  3. Comment (Long Text Area)
  4. Public (Checkbox) Note: this only applies if you have a Customer Community.


Let’s get our Flow created first since we can’t Activate the Process Builder without it  (Setup | Create | Workflows & Approvals | Flows).


The first step is going to be grabbing our Record Create.


We now need to create the variables we will use to create the Case Comment.

Case Id


IsPrimary (This is a BOOLEAN, not Text)




Lets make sure everything is correctly mapped inside our Record Create.


Great!  So lets hit OK and set this as our Starting Element.


Now lets drag in our Record Delete.  This is so that we don’t add useless data into Salesforce.


Create a variable for the Record Id of the Custom Object record we just created, when our Action is used.


Map it in our Record Delete.


Connect the elements together to finish our Flow.


And lastly we want to Save and then Activate our Flow!



Fantastic!  Now we need to setup our Process Builder that fires this Flow.  So lets go create a new Process Builder for this.  (Setup | Create | Workflows & Approvals | Process Builder)


We want the Process Builder to fire on our Custom Object that we created, Case Comment Extension, and we want it to fire only when a record is created.


We don’t need to set any criteria here, but to be safe let’s just make sure that we have a Case ID and Comment before proceeding.


Now we need to map the variables in our Flow to the Values in the Custom Object, using the Type Reference.


Hit Save, then Activate your Process Builder. Now, lets navigate to go create our Action.


Keep it on the default, Create a Record, and select Case Comment Extension (our Custom Object we created earlier).


Let’s make sure we turn off the Create Feed Item, so we don’t spam the Chatter Feed since the Case Comment itself will cause a Feed Item to be created.  Also, make sure we add in a nice Success Message and custom Icon to make the action look sharp!


Remove the Case Field and drag Public and Comment into the Action’s Page Layout.  Make sure you require the Comment field.


It will give you a small popup warning you about not having the Case field on the Layout, but you can ignore it and move on.


We now need to setup a Predefined Field Value for our Case field.


Set Case.Id to our custom Case field.


Now all that is left is for us to update our layout(s)!


And with that, lets take a look at the finished product!