Best Practices

Salesforce Announces the Launch of Salesforce Availability

#1MinuteTip Salesforce announces the launch of Salesforce Availability, a new resource to provide customers with availability best practices to help them achieve their goals. These best practices have been divided in two categories:

  • For Salesforce: Discover the best practices Salesforce follows to support a highly available and resilient experience for our customers.
  • For Customers: Learn more about how you can implement Salesforce for stronger resilience and performance.

Customers section has further been divided into following subsections, with each subsection containing link to relevant resources:

  1. Design Resilient Salesforce Solutions
  2. Optimize for Performance
  3. Prepare for Major Releases and Ensure Safe Changes
  4. Monitor and Support
  5. Respond to and Resolve Incidents
Salesforce Availability

References & Useful URLs

#TDX23 – Apex Patterns & Best Practices

#1MinuteTip #TDX23 Here is the link to download the PDF on “Apex Patterns and Best Practices in 2023” presented in TrailblazerDX 2023. These best practices have been divided into 5 categories that includes:

  1. Security Best Practices
  2. Performance Best Practices
  3. Designing Apex for Scale
  4. Writing Reusable Apex Code
  5. Writing Maintainable Apex Code
Salesforce Apex Patterns & Best Practices

References & Useful URLs

Video Series on Salesforce Well-Architected

#1MinuteTip Here is a video series brought to you by Salesforce Architects team.

What is Salesforce Well-Architected? It is a framework with prescriptive guidance that you can use in architecting your Salesforce solutions.

This playlist contains 9 short videos between 2 to 5 minutes each, explaining the various aspects of a well-architected solution.

Video Series on Salesforce Well-Architected

References & Useful URLs

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
    Scroll to Top