Best Practices

Salesforce API Name Character Limits for Different Metadata Types

#1MinuteTip While working on a recent project, I was defining the technical/design standards and best practices for the Salesforce Implementation. As a part of this exercise, I was defining the naming convention for different metadata types and wanted to list the maximum characters allowed in the API Names of different metadata types.

Strangely, I couldn’t find any Salesforce reference document on the same. So just figured it out myself. There are three main limits on the length of the API Name for Metadata in Salesforce. 40 characters, 80 characters & 255 characters.

Here is the maximum number of characters you can use in the API Name of the metadata type in Salesforce. This can be helpful when coming up with a naming convention for your Salesforce implementation. Please also note that:

  • This excludes the suffix added by Salesforce (e.g. ‘__c’ for custom objects and fields)
  • This list does not include all the metadata. But all the important ones are covered here. If I have missed out anything important do mention that in the comment below and I will add it to the list.
Salesforce API Name Character Limits

Naming Convention for Your Salesforce Developer Edition Orgs

#1MinuteTip If you are a Salesforce Professional (e.g. admin, consultant, developer, architect) chances are that you have registered multiple developer edition orgs. And chances are that you have often struggled to come up with the My Domain name URL for your Org and the username. And as you keep on registering different orgs for developer purposes, you end up having a bunch of variety of Salesforce Orgs and the usernames with no standardization whatsoever.

  1. Come up with a prefix keyword for your Developer Edition Orgs. Like for me, it is ” asagarwal “. For you it can be your first name + last name (e.g. ” annaparker”, ” aparker “) or any combination on these lines. If you have a blog or company, you can use those as the prefix. But just come up with something.
  2. Then use the second word for the purpose of the org. Like if it is for trailhead modules then call it “trailhead”. If it is for learning a specific topic likes Flows or Field Service Lighting, then use that. So the string becomes ” annaparker-flow” or “annaparker-fsl” or “annaparker-cpq”
  3. For developer edition orgs, Salesforce will automatically add the suffix “-dev-ed”. So, your URL becomes
    • annaparker-flow-dev-ed
    • annaparker-trailhead-dev-ed
    • annaparker-fls-dev-ed
    • annaparker-cpq-dev-ed
  4. If you need multiple Salesforce Developer Edition Orgs for the similar purpose (like multiple developer edition orgs for trailhead modules) then just add a number starting with “2” to your second word. Like “annaparker-trailhead02”, “annaparker-trailhead03 ” and so on.
  5. Once you have the naming convention for the My Domain URL of your org, coming up with the username is pretty straightforward. Just use the format “” For example:
  6. The benefit of taking this approach will that you will have a standard naming convention, it will have your branding (just in case if you need to share the screenshots with someone or somewhere like a blog) and you will not need to spend much time thinking about it.
  7. If you already have a bunch of Developer Edition Orgs, you can also apply this naming convention to those orgs. Just make changes in “My Domain” URL under Setup and the username.

    Feel free to modify the naming convention as per your preference. The objective of this post is just to give you some ideas and get your creating juices flowing.

    A Naming Convention for Your Salesforce Developer Edition Orgs

    Best Practices with Salesforce Apex in 2022

    #1MinuteTip Time to review / update your Apex best practices in Salesforce. Here is exactly what you need. In TrailblazerDX 2022 (#TDX22), Mohit Shrivastava & Kevin Poorman from Salesforce did a presentation on the same and have very kindly shared the presentation with everyone.

    Salesforce Developer Best Practices Checklist

    #1MinuteTip How do you ensure that you have followed all the best practices when writing code in Salesforce? Like you only have one trigger on an object and that you are using trigger handler rather than writing logic in trigger itself. You are not using SOQLs or DMLs inside the loop. There is a simple solution – use a checklist before and after you are done with your coding.

    Here is the link to all the best practices that you need to follow when writing code in Salesforce – Drive Consistency and Grow Developer Skills with a Developer Best Practices Checklist

    I am a big fan of checklists. First introduced decades ago by the U.S. Air Force, checklists have enabled pilots to fly aircraft of mind-boggling sophistication. Checklists are being adopted in hospitals around the world, helping doctors and nurses respond to everything from flu epidemics to avalanches. To read more about how helpful checklists can be, please check out this one of the best selling books “The Checklist Manifesto: How to Get Things Right” by Atul Gawande

    Salesforce Developer Best Practices Checklist

    Recommended Framework for Salesforce Triggers

    #1MinuteTip A good framework gives you a structure based on best practices that you can reuse. It is optimized, increases the speed of development & improves the efficiency of your code. Implementing a good framework becomes more important when you are working on a multi-tenant platform like Salesforce where there are limits on the amount of resources you can use. 

    Salesforce recommends one such framework to implement your triggers. As mentioned in the Trailhead Module Success Cloud Coding Conventions -> Implement Framework, it says “Having said that, Kevin O’Hara’s SFDC Trigger Framework is the one we generally prefer on large-scale projects within the Success Cloud team at Salesforce.

    Check it out at URL

    Recommended Framework for Salesforce Triggers based on best practices