Category Archives: Salesforce

Updating Custom Report Types With All Available Fields

So, you’ve created a custom report type and have been using it for a while. One day you go to use it and realize it is missing all the new fields you’ve added to your org. You can go and edit the report type and drag in the new fields, but of all the interfaces in Salesforce, the Custom Report type one has to be one of the most maddening. (I reserve my anger at State and Country Picklists for the worst at being so damn slow.)

Rather than drag in individual fields, we can use the metadata API to solve the problem. Here are the steps I use:

  1. Create a new report type with the same relationships. Leave it in “In Development” status. This new report type will contain all the fields in your objects by default.
  2. Download the metadata for the report types. You can use MavensMate, workbench or other tools for this. If you use Workbench, here is a sample package.xml file you can use:
  3. Once you get the two metadata files, copy everything in the <sections> tag over from the new one to the old one and save.
  4. Use your preferred metadata tool to push the updated report type back to Salesforce.

Live Agent Sensitive Data Rules

After implementing Live Agent, you may find yourself scratching your head at how to write patterns to prevent sensitive data from being sent over chat. Sure you can just type in strings, but you’ll quickly realize that strings aren’t good enough. The documentation says it supports JavaScript Regex statements, but doesn’t provide much information beyond that. I found Mozilla’s documentation to be the best at helping me with the patterns.

Here are a few patterns that I think you might find helpful. They might not let you Make America Kittens Again, but you can still have some fun with it.

  1. Naughty words case insensitive: you might want to prevent certain bad words to be sent, but quickly realized that case is important in these patterns. for example, you can block “ass”, but what about “Ass” or “ASS” or even “AsS”? Use square brackets to group the two cases together like so:
  2. Naughty words with drawn out vowels. Sometimes people like to repeat vowel sounds in curse words. We can block those too using {n,} where n is a number and the comma means at least that many occurrences of the preceding letter. You can also use the square brackets like in the above example to use character substitutions.
  3. Credit card numbers or Social Security numbers: credit card numbers are either 15 or 16 characters long and are predictable with what number they start with (Amex starts with 3 and 15 long, Visa starts with 4 and is 16 long, etc). Use \d to look for any number and then {n} to tell it how many digits there are (replace n with a number). Use * for optional characters so you can look for strings such as the hyphen between the numbers.
  4. Match whole words only. Maybe you have a word you want blocked when it is used by itself, but it wouldn’t make sense to mask it when part of another word. Let’s say you are anti-fun. you can use \b for word boundaries. In this case I’m using it before and after the string so it has to stand alone, but you can also drop one of them so the match is at the end or beginning of a word only
  5. Blocking strings at the beginning or end only. I can’t think of a great use case, but you can use ^ for beginning and $ for end.
  6. Edit: after a silly back and forth on Twitter with @EvilN8, I had to add one more. This illustrates how complicated you can make things to try and prevent it from masking things you don’t mean to. And I didn’t even get all the possibilities with this one either.

Trailhead: The Awesome New Way to Learn Salesforce

I’ll admit it, I didn’t get Trailhead when it was launched at Dreamforce last year. There were only a few badges, and I didn’t really see what the big deal was. Fast forward a year, and holy cow! The Trailhead content just keeps getting added. I love the humor that the Trailhead Team injects into some of the modules. Catter, anyone? I also love how Trailhead actually makes you work in an org and checks your work.

As content in Trailhead increases, I’ve been pointing more and more people to Trailhead to learn Salesforce. Want to move into an admin role? Take the Admin – Beginner and the Admin – Intermediate trails. Want to see why I love developing on the Salesforce platform? Take the Developer – Beginner and Developer – Intermediate trails.

I’m sure we’ll be hearing a lot about Trailhead at Dreamforce next month.  Speaking of Dreamforce, there is a great badge on what to expect and what to do. This one has a lot of the humor I appreciate so much.

To get started in Trailhead, you need two Salesforce logins. The first login you need is your profile login. I use a developer org login for this. It is the same login I use for the forums and success community. The benefit here is that it isn’t tied to your production org login, so when you get a dream job at another company, your profile will move with you. The second login you need is also a developer org. This login will be used to complete your challenges. It is important to use a developer org for this login as you may need features not available in a sandbox or your production org. And why would you clutter a production org with all of that stuff anyway?

Once you have your logins squared away, you are ready to start learning. One of the cool things the Trailhead team is doing is providing modules on add-on products. One such example is Event Monitoring. By going through this module, you can gain an understanding of these new features and decide if it is something you think your production org would benefit from. You can be much better informed about the features without ever having to go through a sales pitch!

So, get on Trailhead and start exploring. Once you get a few badges, you’ll be hooked and want to collect them all!

 

Allowing any User to Edit Custom Settings

Custom settings are an awesome tool for the Force.com developer. They allow you to control code, formulas, workflow rules and more on the platform. The problem is that they are a little hard to update since they don’t come with a tab, page layouts or other features of a full fledged object.

In order to manage a custom setting through the interface Salesforce provides, you must grant the user “Customize Application” permission. Now, this permission shouldn’t be handed out to just anyone. It allows users to edit layouts, object, fields and more. In some cases, you may want to let your users edit a custom setting, but don’t want them to get the other power of Customize Application.

The solution to this is to create a Visualforce page that you can give access to your users. I merrily went down this route recently and it all worked well until I actually logged in as one of the users and got a nasty surprise when I went to save the record. An error appeared on the page:  “system.security.NoAccessException: Update access denied for SuperDuperSetting__c”. I tried all sorts of things including trying to set my controller to use “without sharing”, call a webservice method, and JavaScript Remoting. The only thing that worked was JavaScript Remoting, but it was a bit messy and I wasn’t happy with it.

I then started examining my debug logs and realized my save code wasn’t even executing. The error was happening somewhere upstream of the save method. This got me thinking about Visualforce and object binding. Sure enough, the problem was because I had bound my VF page directly to an instance of the custom setting. The VF page was allowing my user to view the setting, but when I did any method, including a cancel, it blocked it. It wasn’t letting me get to my code. I created a proxy class that mirrored my custom object and bound my VF page to it instead. Lo and behold my limited user was now able to save the custom setting.

Here’s my VF page which works with both controllers. Followed by the code that only works if the user has Customize Application permissions and then the code that works for everyone.

The Salesforce Tribe

I had the fantastic experience of being interviewed by Mike Gerholdt and Jared Miller for the ButtonClick Admin Podcast recently. We had a great time and I really appreciated how insightful both Mike and Jared were about my ramblings. I think the biggest theme we uncovered is that you should do what you love. I love working for a company that I believe in and that is making a difference in people’s lives.  I also love making the mundane parts of people’s jobs automated so they can focus on adding value and making a difference themselves. But, one of the things that makes me really enjoy what I do is the Salesforce community.

Over the last year or so, I kept running across the idea of a tribe. And I truly believe that’s what we, the Salesforce community, are.

A tribe is a group of people connected to one another, connected to a leader, and connected to an idea. For millions of years, human beings have been part of one tribe or another. A group needs only two things to be a tribe: a shared interest and a way to communicate. – Seth Godin, Tribes: We Need You to Lead Us

Our shared interest could be Salesforce, but I think that isn’t quite right. Our shared interest is in making it easier to work. Salesforce is just the tool we’ve all found that not only works well for our users, but also makes it easy for us to do our jobs. We have many communication channels that I outlined in my post Getting the Most from the Salesforce Community. We have leaders like Jared, Mike, and all the other Salesforce MVPs.

This American Life had an episode on tribes last year that resonated with me. One of my favorite quotes was in the prologue about how each tribe has ways of identifying true members.

If I come into a group and I say, I’m really a long-lost member of your group but I can’t speak your language and I haven’t tattooed myself. Then it’ll immediately be obvious that I’m not a member of your group. So all groups have what are called “expensive” ways of identifying themselves honestly so that you can’t just fake it. – Jared Diamond

So, become an authentic member of our tribe. Contribute to the community. You will be rewarded.

Continuous Integration Using Drone.io

As mentioned in my previous post, Team Development on Force.com, Continuous Integration is a key part of getting your team to working efficiently. I recently found Drone.io to be really easy to get setup. They provide a trial with 50 free builds. After that, the cheapest option is $25/month for unlimited builds. I was using it in a matter of minutes after signing up for an account. In this post, I’ll describe how to setup Drone.io to build your Git branch into a target org.

First we need a repository in Git. Drone.io works really well with both Github and Bitbucket. I’ve set up a  demo repo on Bitbucket that you can fork and use to try it out. (This repo will deploy a custom object called Test1__c to your target org.) First, let’s look at the things that aren’t usually in Salesforce metadata. At the root directory, you’ll see three new items:

  • lib folder that contains the ant-salesforce.jar – this provides the Ant files needed to deploy to Salesforce.
  • build.properties – this provides some settings for the deploy
  • build.xml – this provides the deploy actions we can use to deploy to the target org.

Let’s look a little deeper at the two build files.

build.xml

This file sets up the deploy targets. Provided are two targets, one runs all tests and the other runs none. You’ll notice there are several variables in use in the file including sf.username. This allows us to avoid hardcoding values and also prevents them from being visible in source control.  We’ll use these later in our setup.

<project name="ci-demo" default="test" basedir="." xmlns:sf="antlib:com.salesforce">

    <property file="build.properties"/>
    <property environment="env"/>

    <target name="deployRunAllTests">
      <sf:deploy username="${sf.username}" 
        password="${sf.password}" 
        serverurl="${sf.serverurl}" 
        runAllTests="true"
        logType="Detail"
        deployRoot="src"
        maxPoll="${sf.maxPoll}" />
    </target>

    <target name="deployRunNoTests">
      <sf:deploy username="${sf.username}" 
        password="${sf.password}" 
        serverurl="${sf.serverurl}" 
        runAllTests="false"
        logType="Detail"
        deployRoot="src"
        maxPoll="${sf.maxPoll}" />
    </target>

</project>

 

build.properties

This file provides some of the default values for the build. In this case, the default server url is login.salesforce.com so I can deploy to a developer org. Change this  to test.salesforce.com to deploy to a sandbox org. The other variable I tend to tweak is the maxPoll. The default is 20 and I find for large deploys this isn’t near enough time to let the deploy finish.

sf.serverurl = https://login.salesforce.com
sf.maxPoll = 100

With our repo all set up and pushed to Bitbucket, we are ready to set up the build job. First create an account at Drone.io. You can use your Bitbucket credentials, which makes things pretty convenient later on. After you have your Drone.io account created, click on “New Project” at the top of the page, select Bitbucket, then pick your repo. You’ll then be prompted to select a language. I just went with Java as that has all the components we need. In the script window, enter the following command:

ant -lib lib/ant-salesforce.jar -Dsf.username=${SFUSER} -Dsf.password=${SFPWD} deployRunNoTests

This invokes Ant and tells it to include the ant-salesforce.jar. It then sets the username and password using an environment variable (I’ll cover that in a minute) and finally tells Ant to use the deployRunNoTests target in the build.xml file.

After saving the script, let’s add the username and password environment variables. I use variables here so the password is not transmitted in clear text when success and failure emails are sent.

[email protected]
SFPWD=password+securitytoken

With everything entered, click Save at the bottom of the page and then click Build Now at the top of the page. You’ll see a bunch of messages display and hopefully something like this:
deploy log

 

You now have a project setup! It will automatically build every time you commit to Bitbucket. If you use branches, you should go to the project settings and enter in only the branches you want to trigger builds. You can even get fancy and have the build do different things depending on the branch being committed. Here’s an example where we have two different branches. When the branch called develop is committed, we don’t run all tests. When master is committed, we run all tests. You could also have develop build to one org and master to another by changing the username and passwords being used.

[ $DRONE_BRANCH == “develop” ] && ant -lib lib/ant-salesforce.jar -Dsf.username=${SFUSER} -Dsf.password=${SFPWD} deployRunNoTests
[ $DRONE_BRANCH == “master” ] && ant -lib lib/ant-salesforce.jar -Dsf.username=${SFUSER} -Dsf.password=${SFPWD} deployRunAllTests

Poke around at the other settings. If you find other tricks, let me know what you like to do. Happy developing!

Mixing Workflow Rules and Triggers Part 2

In an earlier post, I wrote about how I sometimes use workflow rules for manage the logic for my triggers. I sometimes use a similar trick to get workflow rules to fire. Let’s say I have a requirement to send an email to the account owner when something happens on the account, but I want to allow each user to set his or her email preferences. My solution ends up being to use a custom setting to store the user’s email preferences. I can’t set up criteria in my workflow rules to look at the account owner’s custom setting preferences, so I’ll need a trigger to decide if the email needs to be sent. I don’t want to have to write all the logic for sending the email in my trigger. I’d prefer to use the declarative side of things to handle that.

First, I’ll create the custom setting. I’ll make it hierarchical so I can set preferences at the org, profile and user level.

Custom Setting

Second, I’ll add a field on the account that will be used by my workflow rule.

custom field

Third, I’ll add a workflow rule that sends an email and also does a field update to clear the send email field on the account.

workflow rule

Finally, I’ll create my trigger to update the field above which should cause the workflow rule to fire:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
trigger HotAccountNotification on Account (before update, before insert) {
    Account[] AccountsToUpdate = new Account[]{};
    for (Account a : trigger.new) {
        //only send an email if the rating is Hot
        if (a.Rating == 'Hot') { 
            // only send the email if we are inserting a new record or updating the rating on an existing one
            if (Trigger.isInsert || (Trigger.isUpdate &amp;&amp; Trigger.oldmap.get(a.id).Rating != 'Hot')) {
                // Check custom setting to see if the email should be sent
                EmailPref__c ep = EmailPref__c.getInstance(a.OwnerId);
                if (ep.Send_Hot_Account_Email__c) {
                    a.Send_Hot_Email__c = true;
                    // Since there is a workflow rule on this object with a field update 
                    // that clears the send hot email field as soon as it fires,
                    // we can't really assert that the trigger fired.
                    if (Test.isRunningTest()) {
                        a.Description = 'Hot Account Notification Trigger Fired';
                    }
                }
            }
        }
    }
}

You’ll notice one interesting thing about the trigger. On line 16, I use the Test.isRunningTest Method to update another field on the record. The reason I do this is so I can do some proper assertions in my test methods. If I didn’t have this block of code, then the trigger would fire, the field would get updated, the workflow rule would fire and then the field update would reset it back to unchecked. This all happens in the same transaction so I have no way of using an asserting on the Send Hot Email field. Instead, I’m going to update another field only during tests and check to make sure it was updated as expected in my test method.

Balsamiq Mockups and Salesforce

Usually it is so easy to work on the Salesforce platform that I just jump right in and start coding or adding page layouts. Sometimes, if I don’t have a clear idea of what I need to do, a mockup can help. I recently found Balsamiq, and it is a fantastic tool for quickly creating wireframes. One thing I found myself doing was repetitively putting together the same components over and over again. I figured there must be a better way and found out about Balsamiq symbols. With symbols, I could create reusable components that can be quickly added to my mockup.

I tweeted to find out if anybody else had done something similar and got an overwhelming response that no, but people would love it. I ended up sharing my symbols on GitHub so others could benefit and contribute. Hopefully they will help you too!

Here’s what you’ll see in Balsamiq after adding the symbols to your project assets:

Balsamiq Project Assets

And here’s what they look like when added to a mockup:

Balsamiq Symbols

 

What would you like to see added to this project?

Post Salesforce Data to Non-Salesforce Forms

I had a requirement to look up some information related to a customer in another system. The other system had a simple form where you would enter the data you wanted to lookup and it would give you the details from the other system. I needed a button on the record in Salesforce that when clicked would post the data to the external form and show me the results. I found this great solution on StackExchange and modified it to fit my needs.

First I needed a detail button that executes JavaScript:Crerating Custom Button

The JavaScript would look something like below. It consists of a function which does the post to the form. I then do a simple call to the function, passing in the endpoint plus all the IDs of the form elements that need to be filled and their values. In this case, I’m looking for two phone numbers and passing in the account’s phone and fax numbers

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
function post_to_url(path, params, method) {
  method = method || 'post'; // Set method to post by default, if not specified.
 
  var form = document.createElement('form');
  form.setAttribute('method', method);
  form.setAttribute('action', path);
  form.setAttribute('target', '_blank');
 
  for(var key in params) {
    if(params.hasOwnProperty(key)) {
      var hiddenField = document.createElement('input');
      hiddenField.setAttribute('type', 'hidden');
      hiddenField.setAttribute('name', key);
      hiddenField.setAttribute('value', params[key]);
 
      form.appendChild(hiddenField);
    }
  }
 
  document.body.appendChild(form);
  form.submit();
}
 
post_to_url('http://www.example.com/PhoneLookup',
             {phone1:'{!Account.Phone}',
              phone2: '{!Account.Fax}'});

One caution when using this technique: if the target form ever changes, you’ll need to modify the JavaScript to match.

Mass Editing Profiles in List Views

Here’s an oldie, but goodie tip I picked up a while back. It came in use today, and I thought I’d share it. We had a new custom object deployed to production and needed to give permissions to Create, Edit, Update and Delete records. This wasn’t done when the custom object was deployed, so I needed to assign these permissions profile by profile. Using the edit in list view functionality built into Salesforce, I was able to update all my profiles in one fell swoop.

1. Create a list view showing the permissions you want to change:

Creating a custom list view

2. Select the profiles you want to make the changes to:

Select Multiple Profiles

3. Double click on the field you want to change and select what you want the new value to be as well as which records to apply the change to:

Mass Edit Permissions

And there you have it! I could have also created a permission set with the additional permissions, but in this case I felt it was better to be at the profile level.