Component Design Guidelines

Component guidelines provide recommended standards 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.

General Naming Guidelines

Many components require a label and/or name. Community Hub 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.

Capitalize:

  • 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

Lowercase:

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

Exceptions:

  • 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.

Capitalize:

  • 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.

Guidelines For Specific Components

App Design Guidelines

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

Community Hub Component Design Guidelines

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

Custom Label Design Guidelines

Custom Label Design Guidelines provide standards 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.

Field and Field Set Design Guidelines

Field and Field Set Design Guidelines provide standards for naming fields, specifying field help text and descriptions, configuring field history tracking, and naming field sets.

Layout Design Guidelines

Layout Design Guidelines provide standards for naming and configuring Staff View layouts such as 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.

Object Design Guidelines

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

Permission Set Design Guidelines

Permission Set Design Guidelines provide standards 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.

Record Page Design Guidelines

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

Report and Dashboard Design Guidelines

Report and Dashboard Design Guidelines provide standards for naming and describing Report folders, Dashboard folders, reports, and dashboards.

SOQL Query Design Guidelines

SOQL Query Design Guidelines provide standards for naming SOQL Queries in a clear and consistent way.

Validation Rule Design Guidelines

Validation Rule Design Guidelines provide standards for naming validation rules.