Salesforce Sidekick

If you’ve got a Sales team that works extensively with their mobile phones, then you’ve probably run into the limitation of being unable to add Contacts to your Account or Opportunity Contact Roles.  This is something that common sense would think was available, until you get that dreaded email from an annoyed Sales Rep asking why they can’t add another Contact Role from their phone.  And then you spend 10 minutes making sure you’re not going crazy, because you just assumed they could.  With this post we’re going to go over a quick and easy workaround for this.  We will be specifically solving this for the Opportunity Contact Roles scenario.

Automation Overview:

1. Inputs for Contact Role received (Action)
2. Process Builder triggered (Pass inputs into Visual Flow)
3. Contact Role created in Flow
4. Add Action to Opportunity Layout

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

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

For me, because some of these fields are similar to other fields you might find on an Opportunity, I am going to go with a new Custom Object.  What fields do we need create in this Custom Object?

1. Auto Number
2. Opportunity (Master-Detail)
3. Contact (Lookup)
4. Role (Picklist, match Contact Roles)
5. Primary Contact (Checkbox/Boolean)

Now that we have our Object ready, we can go create our Action.

Keep it on the default, Create a Record, and select Add Opportunity Contact Role (our Custom Object we created).

Label the Action New Contact Role and then uncheck Create Feed Item.  This stops our action from adding a Chatter Post to our Opportunity.

My favorite part, write your custom Success Message.

Lastly, we need to change the Icon to our Custom one.  If you haven’t read my post on the Lightning Design System, now would be the time to do so!  Don’t use the boring default icon, make this your own creation!!

Now to edit our Layout…  Lets remove Opportunity, because that is implied.

Lets add in our other fields, and make the Contact and Role required.

Hit Save, and ignore the Alert message from Salesforce.

Now, lets create a new Predefined Field Value.

We want to select our Opportunity field and put in the related .

Great, we are done with the Action!

We now have to create the Process Builder and Visual Flow.  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 Opportunity Contact Role.

Contact Id

IsPrimary (This is a BOOLEAN, not Text)

Opportunity Id

Role

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 in extra data to our system.  However, if you want to track the usage of this Action by running reports on this Object, then you can skip ahead to saving the Flow.  Also, if you went with the option to go with using Custom Fields on the Opportunity instead of a Custom Object, you’d want to use a Record Update to reset the values to an empty string.

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, Add Opportunity Contact Role, and we want it to fire only when a record is created.

We don’t need to set any criteria here, as we want it to run every time a record is created.

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.  You’re done!  Now all that is left is for us to update our Salesforce1 Actions layout!

Now open up Salesforce1 and look at your finished product!

                    

With a simple Flow and Process Builder we are now able to bypass a silly limitation that Salesforce1 currently has.  But, hopefully this won’t be necessary much longer if you vote for this idea: https://success.salesforce.com/ideaView?id=08730000000DpbEAAS

 

We all know this, but we don’t all do this.  Please, don’t hardcode IDs!  I will start this off by admitting I have done this many times, and still do it occasionally.  However, whenever I do it now – I have to be able to justify it.  If you can avoid hardcoding an ID – do it!
What are the disadvantages for hardcoding an ID?

1. If you are developing in the Sandbox, the IDs of newly created Record Types, Permission Sets, Public Groups, Accounts, Contacts, or anything else will change when you get to Production!
2. You might miss something when you change the IDs from Sandbox to Production and your Flow won’t be fully functional.  Your testing has to be done all over again!
3. It is easy to lose context for what that hardcoded ID.
4. The System uses 18 Digit IDs when you assign an ID to a variable (referring to Flow).  If you paste in the 15 Digit ID you run the possibility of issues with EQUALS operators… beware!
5. Did I mention IDs can change?!  Don’t do it!

When you think about if you could just hardcode an ID rather than doing that extra query, just remember this:

Top Objects to Query:

1. Group (Filter by Type)
   • Public Groups
   • Queues
   • Chatter Groups
2. PermissionSet
3. RecordType (Filter by Object)

Tricks of the trade:

1. Query using the DeveloperName when possible.  This allows you to change the Label without breaking anything.
2. Use Custom Settings or Custom Metadata Types!  Fun fact, Custom Settings don’t count against your SOQL Limits.  I will admit, I was a late adopter but love them now!

Have you ever had the need to delete a group of records all at once?  If you’re dealing with a sizable amount of records, you can’t get by using multiple Record Updates.  The easiest and most efficient way to do this is to use a Fast Delete.  A Fast Delete allows us to delete hundreds of records at once in one Flow!

Deleting data in Salesforce is something that we typically don’t want to do.  And, when we do, there needs to be a good reason why.  In most cases that I’ve used a Fast Delete it has been removing a relationship that was no longer desired (Assigned Permission Sets, Public Group Memberships, or Campaign Memberships).  The example we’ll go over removing Contacts from a Campaign when their Account is no longer listed as a current customer.  The reason is that our Marketing department uses this Campaign to send out alerts to all of our current customers, and we only want active customers to receive the Campaign’s emails.

The first thing we will want to do is navigate to the Campaign Member Fields (Setup | Customize | Campaigns | Campaign Members | Fields).  We will create a custom formula field that will grab the Contact’s AccountId for us so that we can reference it in our Flow when we query Campaign Members.

Now, we can get into our Flow to query all of the Campaign Members related to the Account that just got turned to be ‘former customer’.

If you have not yet read Fast Lookup, you might want to take a look it.  This post is focused on how we get our Fast Delete to work, and not so much how we query to find the records to delete.  I will be showing the ‘finished’ Fast Lookup so that you have it as reference in terms of what Variables were used.

So, unlike in a Fast Update or Create, we have already queried all of the records that meet our criteria in one collection.  Typically you’ll want your Fast Delete to be simply the records that meet your criteria, because that is the most scalable solution if you’re dealing with a large number of records.

Now we need to finish this by dragging out the Fast Delete element (under the DATA section of the Palette).

Set your SObject Collection Variable to be the Variable in your Fast Lookup and you’re done!

Take a look at what the finished Flow looks like:

To get this to run properly, we would now need to setup a Process Builder to pass in the Campaign Id and the Account Id that we reference in our Fast Lookup.  We would want our Process Builder to fire off of when the Account switches to former customer.

RECAP:  Fast Delete elements let you delete a batch of records in your Flow. While we don’t often use the delete ability in Salesforce, there are certain situations when we need to use it.  Keep in mind the Flow limits that we have when you’re figuring out how to get your collection for deletion.  So, a Fast Delete is like doing an delete of records in Workbench or Dataloader.

In Flow we have the ability to re-use certain pieces of functionality that we have created elsewhere.  The benefit to this is that we can consolidate the places that we have to make the updates.  With an Email Alert, we can use this in a Flow to save some of our ‘limitations’ by not having to query the recipients we want to notify.  Pretty powerful when you use it right.

Depending on how many Flows and Quick Actions you have in your Salesforce, you might not notice the Email Alerts section at the bottom of your Palette.  In here you’ll find a list of all of your system’s Email Alerts to choose from.  You can find the one that you’re looking for easily by using the Search at the top of the Palette, or by just scrolling down to it if you don’t have many alerts.

We found our Alert, so lets drag it onto our Flow’s Canvas.

Now, this is the cool part of an Email Alert.  I could have triggered this Flow to fire from any number of Objects.  As long as I have the record’s ID that I want to fire the Email Alert from I can!  When using this element we simply place the variable of the Record we want the Email Alert sent from in the Record ID input.

If you click over to the Outputs tab, you’ll notice that we don’t have the option to do anything… so know you’re not missing any additional functionality.

Now all that is left is to press OK and map this Email Alert to the part of your Flow you need it to send from.  Pretty simple and easy to use!

 

In Flow we have the ability to re-use certain pieces of functionality that we have created elsewhere.  The benefit to this is that we can consolidate the places that we have to make the updates.  With a Quick Action in a Flow, we can replicate an Action that we have in our system.

Depending on how many Flows you have in your Salesforce, you might not notice the Quick Actions section at the bottom of your Palette.  In here you’ll find a list of all of your Org’s Quick Alerts to choose from.  You can find the one that you’re looking for easily by using the Search at the top of the Palette, or by just scrolling down to it if you don’t have many Quick Actions.

We found our Quick Action, so lets drag it onto our Flow’s Canvas.

Notice, at the bottom we have the description of our Quick Action.  This will give you a quick overview of the fields being referenced in your Quick Action, and an easy way to verify you’re using the correct Quick Action if you have some similarly named.

The thing about using a Quick Action in Flow is that I would argue it only adds more complexity to what could be done with a simple Record Update or Record Create element.  However, where this can get interesting is that using a Quick Action in your Flow DOES NOT count against your 50 DATA element limitation.  That means, if I wanted to essentially run through over 900 individual Record Creates or Updates via a Quick Action, I could!  I wouldn’t recommend doing it in a non-Developer Org, as it does take over 1 minute for the Flow to run…

With that in mind, lets take a look at what our Quick Action looks like when we drag it into our Canvas.

So, I am using the standard Log a Call Quick Action here.  If you notice, there are NO required fields for this action.  That means, we only have to fill out as many parameters as we want.  If I made a field required on the Page Layout, it would look like this:

 

Also, another required field would be the Record ID of any record you’re doing an Update on.  This is not any different than if you were to do an update using a Record Update element, so there should be no surprise.

Lets now look at what our Log a Call will look like after we’ve setup the variables from our Flow to be filled out.

If you notice we have an Outputs tab.  In this element there is no option for us to do anything

Now all that is left is to press OK and map this Email Alert to the part of your Flow you need it to send from.  Pretty simple and easy to use!