Entries in salesforce API (71)


Inserting Person Account Records Via API

A common way to insert Person Account records via API (e.g. Data Loader) in your Salesforce org is to define the fields: Last Name and Person Account Record Type ID, which is different from the Record ID in the Business Account. 

But it's interesting to discover that there's rather a smart way for Salesforce to differntiate between Person Account records and Business Account ones; which is by mapping the Last Name.

By mapping the Last Name field, it is acting as the primary field in differentiating between Person Account records and Business Account ones; because if the the record being inserted is a business account, then the company name will have no first or last name. Therefore, remember to always map Last name (along with other related fields) when inserting person account records via api.


Salesforce Tooling API

With the Salesforce Spring 13 release just around the corner, developers everywhere should be getting anxious for the new Salesforce Tooling API.

Unless you’ve been living under a rock, it’s pretty well known that easily sharing code and best practices with other organizations in an effort to create an open source ecosystem around Salesforce is difficult. This is often due to barriers to entry that make it tricky to export/import code into a Salesforce instance. In short, it’s just not easy to collaborate within the Salesforce Developer community…until now!

With the new Salesforce Tooling API, devs in the community can start to build tools for other developers that might make it easier to share code and ideas and increase the flow of best practices within the community.  The Tooling API allows for access to key building blocks of development, including Apex classes, triggers, and VisualForce pages.

Here are some goodies from the API documentation:

  • Manage working copies of Apex classes and triggers and Visualforce pages and components.
  • Check for updates and errors in working copies of Apex classes and triggers and Visualforce pages and components, and commit changes to your organization.
  • Set heap dump markers.
  • Overlay Apex code or SOQL statements on an execution.
  • Access heap dump files.
  • Access debug log files.
  • Set trace flags to generate log files for yourself or for other users.

With a tool this great, I suspect that they’ll continue to build on this in the future, maybe even providing access to more metadata like reports and dashboards, which, of course can only benefit the Salesforce Developer community even more!


API and API Token, Part 3

By now you’ve probably seen my two previous posts about the Salesforce API in PE, and use of the API token.  The first, where I raise questions about accessibility is here.  The second, where I describe the problems we had and their outcomes, is here.

I wanted to give you some more detail on the issue.  This comes from Salesforce technical support:

As a general rule, one cannot run Apex in a PE or GE. However, there is one exception to this rule. Apex that you develop in DE can run in GE and PE, if the following conditions are met:

Apex is installed into the GE and PE org via a managed package.  Apex does not expose classes as a Web service - these can be installed, but not invoked (more below).  Apex is not dependent on features and functionality that exist only in EE or UE (e.g., record types and/or Campaigns) unless it's dynamic Apex.  If an app and its Apex have passed the Security Review, they have been "Apex Authorized."

Apex Authorization means that Apex (classes, triggers, and email services) in the app will run in GE and PE, even though those editions do not support Apex by default.  It is important to note this does not mean the GE or PE customer can create new Apex or modify Apex in the app.  They can only run the existing Apex in the app.  As noted above, any Apex classes that have been exposed as a Web service cannot be invoked from an external Web app in GE or PE even with this special permission.

To be clear, let's say there’s a separate hosted Web app that needs to call an Apex class in the app.  You might expose one of the Apex classes as a Web service and include it in the managed package.  For DE, EE or UE, the app will be able to invoke this Web service externally, but in GE and PE, it will not work.

However, using Apex to make Web service callouts is allowed in GE and PE.  For instance, if the plan is to make a Web service callout to an external Web service like Google, as long as the managed package is authorized, these classes will function in GE and PE.

See the document here for details.

The final outcome is, of course, disappointing.  But if there is a silver lining, it’s that we now know for sure.




API and API Token, Part 2

Some of you may recall my post from a couple of weeks ago on enabling the Salesforce API in Professional Edition, and the use of an API token to allow apps that rely on the API to work in editions that don’t have it.  The original post is here.

Well, after some weeks of experimentation and touching base with several different groups at, I finally have some answers.

First, the API is NOT enabled in Professional Edition (or lower editions), and it cannot be added on/purchased.  There are certain rare occasions where I’ve heard that the API has been enabled in PE, but these occasions had to do with technical data management issues and are by far exceptions to the rule.  For you developers out there, keep in mind that the API is enabled in PE-level partner orgs, which can be a little misleading when testing things out as such orgs don’t truthfully mirror a production-level/paid PE org.

Second, on the matter of the API token:  There is some documentation here.  On our first try, we got an error message saying the API needed to be enabled.  Confusing, right, since the whole reason we’re using the API token is because the API is not enabled in PE.  Salesforce technical support came back to tell us that API tokens are not supported by Rest APIs, only Soap APIs.  We were using the Soap API and had the token in the Soap header, as directed, but we continued to get the following error:  API_DISABLED_FOR_ORG: API is not enabled for this Organization or Partner

After exchanging code snippets and emails, and having the case escalated, we finally were able to schedule a conference call.

As it turns out, Apex classes and methods CANNOT be invoked through API calls on a GE/PE Org, even with the Client Id.  Managed packages that host their own web services are not accessible from outside Salesforce with Professional Edition organizations.  These managed packages are able to call out to externally-hosted web services but those services are not able to communicate back to the installed managed package.  In such a case, this prevents activation of the package and performing other ongoing operations that require communication between the package and the web services.

I’ll include some more details in a later post.  I want to organize my notes and communications with


You can see Part 3, the final part, here.





API in PE, and Other Alphabet Soup

I typically work with Salesforce CRM from a development perspective.  But occasionally, in my consulting work, I work with clients on implementation.  Recently I was working with a client using Professional Edition (usually my clients are running Enterprise Edition or higher).  This client was interested in several complementary apps that are listed on the AppExchange.  The problem though, is that most of those apps only work with Enterprise Edition or higher.

I explained to my client about the API, and in turn, the client asked if he could get or enable the API in his Professional Edition org.  This led me on what has become a bit of a wild goose chase.  I‘d heard, that for an additional subscription fee, PE users could enable the API.  But when I called, I was told this was not the case, and that the client would need to upgrade to EE.  I also posted some notices at various Salesforce forums, where some participants said that it is possible to enable the API in PE.  I am still left wondering what the real answer is, and it’s a bit frustrating.  I know that the API is enabled on a PE partner org, but such an org is completely different from a paid, production, PE org.

To make matters even more complicated, Salesforce told me there is a way, using an API Token, to enable an app to work with PE.  With this bit of news, I contacted a colleague who builds Salesforce apps.  My colleague immediately began working with an API Token (because if he could get his app to work with PE, it expands his potential customer base).  To date though, he’s had no success.  He’s working with Salesforce developer support, but getting nowhere fast.

Anyone out there know the true story?  Can the API be enabled in a paid, production, PE org?  Will the API Token allow an app to work with PE?


See the follow up entries to this post:  Part 2, and Part 3.



Salesforce API Gotcha - logout()

I was fighting a nasty issue last week and was completely stumped as to what was causing it. I've got a .Net application that I've got connected using the Salesforce API. Long story short a few times throughout the week I got the following exception:

 INVALID_SESSION_ID: Invalid session ID found in SessionHeader

I was sitting there scratching my head because I would be in the middle of an operation when all of a sudden this would happen. I wasn't able to reproduce it with any consistency as well and that made it even more puzzling. I put it on the back burner early in the week and I told myself that I would sit down one evening and figure it out once and for all. So, Thursday night I went to work. I spent an hour trying to reproduce it and finally I decided to go back to Google. I had previously searched and didn't find anything of much value. It was always the standard stuff "make sure you've logged in and or are still logged in." I was immediately discounting those because I was in the middle of operations when all of a sudden this would happen.

Finally I stumbled upon a comment from someone on a completely un-related thread. The person mentioned the Salesforce API logout() method with the following comment:

...unless you have a specific reason to kill all active API connections for the user, including connections made by other tools, do not call logout().

At that point, I do a search and find another site that explains the logout() method in detail. Here is the gist of it. When you make an API call to Salesforce, the they authenticate the calls by examining the SOAP header that contains a session key. Session keys are allocated on a per-user basis. What this means is that if you create two connections at the same time (i.e. using login() from two different threads) - they will both be using the same session key.

At this point, the lightbulb in my head starts to slowly begin to glow. I ask myself, could this be the cause. YES, in fact it was. I had a background thread that was kicked off under certain conditions. This background thread was calling logout() when it was completed and in effect, it was killing the session key that the other thread was also using.

I commented out that line where I was calling logout() in my background thread and the issue went away.





Data Quality: Case in Point

The motivation for this blog post is a case in point example, so I'm going to go ahead and give you the story first and I think you will understand immediately why I'm so frustrated. For the purpose of this exercise, I'm leaving out all names and identifying traits of the people involved. I'm sure that most of you have experienced a similar situation, so feel free to chip in with comments.

I received an email two days ago from the sales director at my company. He went into detail about a conflict that came to his attention early in the week with two sales representatives, who I'm going to call Tom and Jerry. Tom made a phone call to a customer that he had made initial contact with two months ago and had entered into our Salesforce database. He was confused when the customer told him that he had just talked to a rep at our company named Jerry, and had actually decided to go ahead and buy one of our products.

At this point, Tom was both frustrated and irritated. He had embarrassed himself in front of a customer and lost out on his commission. He immediately went to the sales director with his complaint, who immediately emailed me. So I was left with a problem: how had Tom and Jerry both been assigned the same customer by the Salesforce system?

I found my answer fairly quickly. Every weekend, our Salesforce account does a mass import from our internal database containing all of our customer information. At some point, the customer in question had his phone number changed. When the system did it's weekly import, instead of recognizing that the number had changed, it went ahead and created a completely new account under the duplicate information with a different phone number. Tom was assigned 'Original Customer' and Jerry was assigned 'New Customer' and I ended up with a two-salesperson pileup.

I know that I've shared a lot of my thoughts on data quality with you before, but I don't think it can be emphasized enough. Without maintaining strict protocols for data import as well as entry, conflicts like this can arise fairly easily.


Steps Toward Cleaner Databases

One of the most consistent problems I face in my work is getting members of our sales team to fully and accurately fill out the required fields on This lack of attention to detail has left entries into our database in a patchy condition at best. Some accounts are fully filled out, but nothing is a bigger bane on the efficiency of our sales team than a partially completely lead form.

However, by taking a two simple steps as a Salesforce Admin, you can start to really cut down on the amount of incomplete data that is entered into the system.

1. Be sure that you have set up all fields appropriately for the lead form. If you plan on transferring the information from the lead form over to the account page, be sure that the fields on both pages match up.

2. Next, set up validation rules. By creating efficient validation rules, you can make sure that the user enters in the required data before they are allowed to save the record or change the status of the lead.

Important things to consider: When you are creating the validation rules for the lead forms, think carefully about which fields you want to be required. For example, if the salesperson makes initial contact over the phone, it makes sense to require that the telephone number field is filled in. You have to be careful though, because validation rules prevent the user from saving the information without all of the required fields filled in. What information is it likely that the sales rep can acquire over the phone? What is unlikely?

Hope this helps! If you aren't already, Follow Me On Twitter!


#DF11 So close, yet so far

We are exactly 20 days away from Dreamforce 2011- or as it's being referred to all over Twitter, Salesforce Christmas. All anyone needs to do to stir up some personal excitement for the conference is visit The lineup is incredible; Marc Benioff, Eric Schmidt, and many other CEO's and higher ups from notable companies. Metallica and Will.I.Am are also going to perform. Tons of folks are going to get certified for Salesforce, developers and admins will network, and unmeasurable amounts of learning will take place. All of this excitement is geared toward celebrating Salesforce and Cloud Computing.

I wish I could do it all. I look at the agenda, the speakers, the workshops, and the random activities and I literally wish I could be in a million places at once. Unfortunately, with around 40,000 people attending the conference, it's impossible to hit all of the events. However, I'm doing my best to be as organized as possible so I can maximize my Dreamforce '11 experience.

Here are four of the sessions I'm planning to attend:

  • Building Your Brand with Jenna Baze, Mike Gerholdt, and Nick Westergaard - 8/30 from 10:00 a.m. - 10:45 a.m.


  • 7 Habits of Highly Successful Admins with Mike Gerholdt, Thomas Martin, and Jeff Grosse - 8/30 from 3:30 p.m. - 4:30 p.m.


  • Best Practices for Clean Data - 8/31 from 2:00 p.m. - 3:00 p.m.


  • Data Does Not Have to Be a Dirty Word - 8/31 from 3:30 p.m. - 4:30 p.m.

I'm also really excited to have the opportunity to walk the Cloud Expo floor and check out all the new products that I'm sure will be debuting at the conference. My favorite part of the conference every year is seeing all of the new features, apps, and innovations all come together at once. I can't wait!