Naming conventions

Data (like numbers, text, or date) or instances of a Type (say, Type: Customer), are stored as Values in ManyWho. Values, once created, are available to be used by all Flows within a tenant, making you more efficient and saving time. A single tenant can have hundreds of Values, shared between hundreds or even thousands of Flows. It is important you follow a naming convention, to make it easy to find specific Values in the future, to understand what a Value contains, and also to avoid naming collisions.

We recommend the following best practices:

  • Use descriptive names, that include a hint as to what the Value contains, or what its intended use is.
  • Stick to a single naming convention.

String, Content, Password, Boolean, Number
  • For Values that will not change during the lifecycle of Flows, include the content category (or what kind of Value it is) in the name.

Example 1: For a fixed Value that will be used to set the Status of a Task in Salesforce, set the Value name as Status: In Progress. This will help fellow Flow builders recognize that this Value is a status of some kind. If the fixed Value is later used with an Object or List, the category is usually the same as the property that will be assigned. For example, Task Object in Salesforce has a property/field called Status.

Example 2: If you have a Value that will store validation alerts, call the Value Validation Alert. For subsequent Values that will hold the various alert messages, use notation similar to this: Validation Alert:Payment Required, and so on.

  • Include a short summary in the Value name.

Example 1: If you are creating a Value that will store the body of an email message, call the Value Email Body:Registration Complete Notification.


Object, List
  • When creating the first Value for the Type, give it the same name as the Type. An Object Value of Type: Contact, should be called Contact, a List Value of Type: Contact should be called Contacts, and so on.
  • If you have more Values of the same type, use a notation that denotes a category.

Example 1: An Object Value of Type: Contact that will hold information about the spouse of a Contact, should be called Contact:Spouse. A List Value that contains information about the dependents of a Contact, should be called Contacts:Marketing.


Picklists

When building Salesforce Flows, you may need to create picklists. To do this, you create a Type called ‘Picklist’ or ‘Dropdown’. This Type is re-used for all picklists; so the naming convention is a little different.

  • For the List Value holding the picklist data, use the notation Type:category.

Example 1: A List Value, holding a list of countries, is named Picklist:Countries.

  • For the Object Value holding the selected picklist entry, use the notation Type:category:selected purpose.

Example 1:  If you select a country from Picklist:Countries, the Object Value holding the selection is called Picklist:Country:Selected Primary Residence.

  • If there are any fixed Values related to these selections (for example, you have a decision based on a selected picklist entry), use the notation Category:Content.

Example 1: Country:USA (This assumes that your Picklist or Dropdown Type contains the standard Label/Value properties (as you find with HTML5 options). If the Type has more properties, modify the notation to Category.Property:content. For example, if you are categorizing countries, the Value would be named Country.Category:North America.


Check out the ManyWho glossary for a definition of terms and key concepts that appear in the ManyWho website, Drawing Tool, technical documentation, blogs, and marketing communications.