Component Standards

Component standards provide guidelines for naming and configuring metadata in Staff View and Community Hub. Components include, but are not limited to, apps, fields, list views, page layouts, search layouts, as well as Community Hub components such as cards and pages.


Adherence to component standards in Nimble AMS ensures a clear, efficient, consistent, and beautiful user experience. Administrators can refer to these standards when creating or editing components in Staff View or Community Hub to ensure both staff and constituents have a great user experience.

These standards prioritize competing design principles to ensure that an effective user experience is clearly defined and consistently configured throughout Nimble AMS.

The variety of interfaces makes adherence to standards very important. For example, if Maria Gomez, a membership staff user, is looking for a specific membership record, she has several ways to find and view it:

  • A global search displays the membership in the Search Results search layout.
  • The Memberships tab displays the membership in the Tab search layout and in list views. 
  • The related account record displays the membership in the Memberships related list.

A well-configured org consistently displays the same fields, in the same order, in all of these layouts. Regardless of the method Maria uses to access a membership record, she experiences a concise, familiar user experience.

Administrators also benefit from an org that adheres to component standards because it is easier to maintain components which have been clearly and consistently named and configured.


The standards for Nimble AMS components are guided by the four Salesforce design principles, which are, by order of importance: (1) Clarity, (2) Efficiency, (3) Consistency, and (4) Beauty.


SalesforceDesign Principle

How it Applies to Nimble AMS

1 Clarity

Name components clearly. In layouts, include fields that most clearly identify a record.

2 Efficiency Keep names brief to minimize reading without sacrificing clarity. In layouts, rank fields by importance to reduce clicks.
3 Consistency

Configure components within an object as similarly as possible. Globally, configure components across all objects as similarly as possible. Consistency cannot sacrifice clarity nor efficiency.

4 Beauty

Generally, the Salesforce platform or the Community Hub theme determines the final presentation of the user interface, but some components can be configured to be more visually pleasing.


Many components require a label and/or name. Nimble AMS uses the title case and Pascal case styles to name components.

Use title case for names and labels if the space character is allowed. Otherwise, use Pascal case.

When creating and editing components, some name fields are automatically populated with values that do not conform to these naming standards and therefore need to be manually corrected. For example, when creating an object where Label is Chapter Membership, Object Name is automatically populated with the value Chapter_Membership, which is neither title case nor Pascal case.

Be kind to your future self and fellow staff by writing clear names. For example, if you have a list view for webinars next month, avoid vague terms such as "Upcoming Webinars." Instead, be more descriptive like Future Webinars: Next Month

Title Case

Title case uses a space delimiter between words and capitalizes most words. For example: Year of Graduation.


  • Nouns, pronouns, adjectives, verbs, and adverbs
  • The first and last words, no matter what the words are
  • The second element of a hyphenated compound. For example: Third-Party Software
  • Prepositions that are part of a verb. For example: Log In


  • Articles (a, an, the) and prepositions that are not part of a verb
  • The to in an infinitive. For example: Modules to Complete


  • Retain the capitalization of abbreviations and names. For example: pH Value; iPhone

Pascal Case

Pascal case uses no delimiters between words and it capitalizes all words. For example: YearOfGraduation.


  • All words, including the first letter of names that start with a standalone lowercase letter. For example: IPhone

  • Acronyms, including the first letter of acronyms that start with a lowercase letter. For example: PHValue; NimbleAMSMembership

Some component names cannot start with a numerical character. Consider changing the number to its text equivalent. For example, instead of 1stDonationDate use FirstDonationDate.

Alternatively, change the order of the words. For example, instead of 401kApplicationDate use ApplicationDate401k.

Omit special characters such as ampersands (&). For example, the conversion of All AV & Tech from title case to Pascal case is AllAVTech.

App Standards

App standards provide guidelines for naming and configuring apps, including recommendations on selecting and sequencing tabs, also referred to as items.

Learn more

Community Hub Component Standards

Community Hub component standards provide guidelines for naming and describing Community Hub components such as access controls, buttons, cards, card layouts, data sources, and pages.

Learn more

Custom Label Standards

Custom label standards provide guidelines for whether you should create custom labels or edit/override existing custom labels. It also provides standards on clearly naming new custom labels. Custom labels are primarily used for messages, heading text, and description text on pages and cards in Community Hub.

Learn more

Field and Field Set Standards

Field and field set standards provide guidelines for naming fields, specifying field help text and descriptions, configuring field history tracking, and naming field sets.

Learn more

Layout Standards

Layout standards provide guidelines for naming and configuring compact layouts, list views, page layouts, and search layouts. Layouts should contain the most important fields for the record. Since some layouts cannot always display all the fields included in the layout, it is important that administrators use a standard approach for selecting the sequence of fields.

Learn more

Object Standards

Object standards provide guidelines for naming and configuring custom objects. This includes recommendations on naming the object and its records, enabling object features, and enabling Chatter Feed Tracking.
Learn more

Permission Set Standards

Permission set standards provide guidelines for naming and configuring permission sets. It can be difficult to tell at a glance what a permission set grants, so it is important to write clear names and descriptions to identify a permission set's purpose and scope.

Learn more

Record Page Standards

Record page standards provide guidelines for when to create new record pages and how to name them. They also provide guidelines for selecting a template and organizing Lightning components.

Learn more

Report and Dashboard Standards

Report and dashboard standards provide guidelines for naming and describing report folders, dashboard folders, reports, and dashboards.

Learn more

Query Standards

Query standards provide guidelines for naming queries in a clear and consistent way.

Learn more

On This Page

In This Section