With Spring '13 currently deployed to Sandbox orgs and soon to Developer and Production orgs, there are tons of new features to utilize within your future projects. I was recently excited about a new Cases Class called ".getCaseIdFromEmailThreadId."
Remember that "Ref" tag formula from this post? You know, the unique ID that is attached to emails when using the Email-to-Case functionality? I was working on another project in which an email web service was required and I needed to take the "ref" tag and identify the Case ID of the associated Case.
Then I read the Spring '13 Release Notes and was delighted to find the Cases.getCaseIdFromEmailThreadID method. I wrote a quick code block to test it out:
Unfortunately, I received this dreaded message.
Error: Compile Error: Method does not exist or incorrect signature: Cases.getCaseIdFromEmailThreadId(String)
I opened a Case with Salesforce in hopes of a quick remedy to save me from coding it myself. The answer to my problem was that this org already had a custom "Cases" class. This custom class was being referenced as opposed to the new Salesforce provided feature.
The moral of the story is, Salesforce introduced this new feature into my org in which their class conflicted with my class and I only discovered the issue when I tried using the new method. Lots of developers may use a common class naming convention in which the class name mirrors the Objects in which they work with. Lots of developers may try to use future new Salesforce Classes/Methods only to be stopped in their tracks while scratching their heads. Hopefully, this possible conflict is the first thing they think of.