6

It was recently brought to my attention that for our clients, SalesForce translates profile names (such as "System Administrator") which causes errors when the Apex code attempts to check profile names in conditional code.

I should have thought translation should only have effected the presentation layer and Apex developers would need to go out of their way to consider it. But I'm informed this is not the case.

Is there a way I can tell my Apex code that I am only considered with the value stored in a field (e.g. profile.name) and don't care at all whether it has been translated or what it may have been translated to?

3
  • to avoid such issues, you can try using custom settings...
    – Bforce
    Mar 6 '14 at 16:40
  • @baskaran, but then we need to make sure the values are loaded into the custom settings for the unit tests, which aside from being an additional hassle slow them down even further. Mar 6 '14 at 17:06
  • Nice question!! Can you detect the permission you need as opposed to the profile? Kinda analagous to "feature detection" vs "browser detection" in the webdev world? Or limit your interrogation to profiles you explicitly create, which will not be translated? May 26 '14 at 22:03
5

Profile names can change, but profile ID's don't. I recommend you use the ID instead of the name for that very reason.

Its not unusual with various licenses for someone to clone and rename them. I've encountered this especially with portal user licenses. Regardless of how they rename it when that happens, the license ID still doesn't change. The same applies to other profile names and ID's.

For that reason, I've learned to only query using the ID instead of the name in my coding.

Edit

If you're uncomfortable both with using ID's and with Custom Settings, the only other solution would seem to obtain the translations and add those to your query as part of a logical OR statement in your WHERE clauses. Either that, or add them via some other means that determines which query to run based on the language environment.

10
  • Won't the ID be different in different sandboxes? So maybe it would work in dev but not prod?
    – user6861
    Mar 6 '14 at 17:51
  • Not in my experience when it comes to User profiles. Licenses are the same whether you're in a sandbox or in a production org. In cases where an ID of some kind is different, just as with anything else, you can always put in a conditional to test for sandbox vs production. That's easy enough to determine in most situations.
    – crmprogdev
    Mar 6 '14 at 17:55
  • 3
    Generally I'd downvote an answer suggesting you hardcode IDs, but with profiles it's a pretty rough situation. They don't have a "developer name" that's consistent like most other types of metadata SObjects, so depending on your environment hardcoding the id might actually be easiest. Mar 6 '14 at 19:03
  • Generally speaking, I agree. Profiles ID's are usually the only ID's that I hardcode. I've been bitten with profile names changing on me.
    – crmprogdev
    Mar 6 '14 at 19:29
  • 1
    I don't see why test execution time would be used a reason to avoid using a solution. Your test methods are not fired every time a user touches the system, so it isn't going to impact that. You are not likely doing a deploy ever couple minutes, so you won't be noticeably adding time there. If you use a factory class in your tests, you can have a static set or map that is populated as you request profiles, and referenced before retrieving profiles. May 26 '14 at 20:59

Not the answer you're looking for? Browse other questions tagged or ask your own question.