Recommended naming conventions

Rationale

• Entity names have a 100-character limit in Lucernex.

• Entity names are heavily used when searching. Shorter names require less processing time.

• When creating Capital Projects for Programs through the Add Facility Projects wizard, Lucernex creates a name composed of Facility and Program names separated by a colon—for example, FacilityName: ProgramName.

Rationale

While limiting symbols is still a good idea, it can be unavoidable in entity names because they often include place names, which may have hyphens or apostrophes.

Rationale

Many companies use numbers to identify facilities and contracts. Referring to these numbers directly is the most efficient way to identify the associated entities in Lucernex. Also, entity names are never data, as opposed to names given to configuration, which may be normalized and / or used as accessor names.

Examples

Rationale

This practice ensures entities sort logically within My Portfolio and search results.

Examples

Rationale

These two options are preferred over others, but have tradeoffs between them.

• Hyphen

  For example: CA-San Diego Office

  • Pros

    • Less prone to data-entry errors

    • Fewer characters

  • Cons

    • May be confusing if name parts include hyphens (for example, Winson-Salem, NC).

• Space-hyphen-space

  For example: CA - San Diego Office

  • Pros

    • Easier to read

  • Cons

    • More prone to data-entry errors, including missed spaces and unneeded spaces

    • More characters

Context-Dependent Recommendations

Rationale

• Using the company name provides users a familiar reference point that gives them confidence they’re in the right place and reinforces company identity.

• Simplifying the company name reduces the likelihood of upload errors.

Examples

Rationale

• Using the country, brand, or department provides users a familiar reference point gives them confidence they’re in the right place.

• Simplifying or abbreviating the Portfolio name’s parts reduces the likelihood of upload errors.

• Longer names take up more space in reports.

Examples

Rationale

When looking at historical data, future users may not remember the purpose of a program based on its nickname and will have to do additional research to find what they’re looking for.

Examples

Rationale

Many programs cover multiple years or recur. Including the calendar or fiscal year of initiation…

• …ensures one program can be appropriately distinguished from the next.

• …ensures default names generated for Capital Projects for the same Facility don’t conflict.

• …makes reporting easier.

• …is more reliable than including the year targeted for completion because plans can change.

Examples

Rationale

• Ensures one program can be appropriately distinguished from the next.

• Ensures default names generated for Capital Projects for the same Facility don’t conflict.

• Makes reporting easier.

Examples

Rationale

Incorporating a description of the design of the prototype into the name of the prototype will help you distinguish from multiple prototypes for similar facilities. Your description could include one or more of the following items:

• Brand

• Target environment

  This could include but is not limited to a mall, airport, stand-alone facility, in-line facility, or high-rise building.

• Facility type

  This could include, but is not limited to a kiosk, store, or restaurant concepts—such as a branded coffee shop.

• Size

  Such as a small, medium, or large facility.

Examples

Rationale

Major versions may correlate with an entirely new floor plan or design initiative. Do not track minor changes in the prototype name. The Prototype module has a Change Management sub-module, which can be used for tracking minor version updates.

Work with your management team to determine the distinctions between major and minor version changes.

Examples

We recommend you include the facility ID number, project type, and calendar or fiscal year of opening.

Rationale

Some companies—primarily retailers—re-use facility ID numbers, meaning they could have more than one project with the same facility ID number. Similarly, buildings may be heavily damaged and require rebuilding. Including the project type and opening year can help distinguish full-scope projects for the same facility.

Examples

A capital project that has been created using the Add Facility Project function in the Program module will follow the naming convention [Facility Name]: [Program Name]. If you have followed the naming convention recommendations for facilities and programs, your automatically generated capital project name will be sufficient.

If you are not following those naming conventions, refer to the Stand Alone Capital Projects section above for best practices.

Rationale

The Municipal ID will be unique to the parcel and therefore be easily searched.

Examples

Rationale

Including the location name will make searching for your parcel simpler and make parcels easier to distinguish.

Examples

Rationale

Users often know their store number / branch number / restaurant number. It is a unique identifier that most likely would not be duplicated across facilities.

Examples

Rationale

Use a number that is one digit longer than the postal or zip code in your primary country of business. By doing this, you will eliminate false positives from your search results. Including leading zeroes gives you the flexibility to grow and makes your facility IDs consistent in length.

Examples

Rationale

This will help differentiate between operating and closed facilities.

Examples

Rationale

Users can easily recognize records by including the location of the facility.

Examples

Rationale

Users typically know their store number / branch number / restaurant number.

Examples

Rationale

Including the part of the lease—such as a billboard, storage, or parking—in the contract name makes it easier for users to find the contract they are looking for.

Examples

Rationale

If you have both leases and subleases related to the same location, adding "sublease" to the contract name makes the contracts easier to differentiate.

Examples

Review the following expanding sections for naming conventions for the contract of an equipment contract.

Include the Vendor / Provider name in the Contract name

Include the Contract ID provided in the contract paperwork in the name

Review the following expanding sections for naming conventions for assets on an equipment contract.

Include the type of asset in the name

Include the serial number and manufacturer in the name

Rationale

You should use field labels to clearly and specifically tell users what the field does or should contain. If a field label is vague, it increases the chance that users will enter incorrect data.

Examples

Rationale

"[Object] Name" implies that the field contains simple text. If a field can be used to access multiple types of data about an object, it should have a more generic name.

Examples

Rationale

Creating a common prefix helps you easily distinguish global fields from firm-defined fields. This is particularly useful if you use DataMart, JavaScript, or API calls.

We recommend using a prefix that is at least three characters long, so your fields do not become mixed with other fields in an alphabetical list.

Common examples of prefixes include:

• Firm_

• UDF_

• Company initials

• Brand Initials

Examples

Rationale

Adding a form-type abbreviation prefix helps you easily distinguish form fields from global fields, firm-defined fields, and other form-type fields, particularly in DataMart, JavaScript, and API calls. We recommend you use the form type's sequence prefix.

Examples

Rationale

Before you can add a custom list to a page, you must create a field that contains the custom list. Adding a suffix of CL to the field helps distinguish the field that contains the custom list from the fields that the custom list is composed of. Doing this also makes it very clear that this field is the custom list itself rather than a standalone field.

Examples

Rationale

Following this convention makes it clear that the field is a component of a custom list, and which custom list it belongs to.

Examples

Rationale

Following this convention makes it clear that the field is a component of a report.

Examples

Rationale

Following this convention makes it clear that the math field is a component of a report.

Examples

Rationale

Following this convention makes it clear that the JavaScript field is a component of a report.

Examples

Rationale

Following this convention makes it clear that field is a math field.

Examples

Rationale

If you want to import the form type into another environment, you will get an error.

Examples

Rationale

Form types can be a parent to multiple form layouts. Reduce clutter on the Manage Forms page by grouping forms that have the same field set type. This way, you can capture the same kind of data with a similar set of fields.

Examples

Rationale

Adding a prefix to distinguish between departments can help users understand which forms are relevant to their work flow. If your department names are fairly static, consider abbreviating based on your actual department names.

Examples

Rationale

If the Lucernex team creates integrations for you that target the form, we normalize the form type name into an XML tag name. XML tags cannot start with numbers.

Examples

Rationale

If the Lucernex team creates integrations that target the form, we normalize the form type name into an XML tag name. The normalization process has rules that must be followed, and punctuation makes this process more difficult.

Examples

Rationale

This best practice applies to any type of configuration record. Adding the zHISTORY prefix puts the configuration record at the bottom of the list and makes it clear that the configuration record is no longer being actively used.

Examples

Rationale

The form layout name displays in the Select Form dialog box and on the work flow step after the step name. A long name can be distracting and harder to quickly understand.

Examples

Rationale

Adding the zSUBFORM prefix to subforms pushes them to the bottom of the form layout list. It also makes it clear that the form layout is not associated with a work flow step, and that changing the form layout will impact multiple form layouts.

Examples

Rationale

Approval is not an inevitable result—the word "review" more appropriately captures the purpose of the form.

Examples

Rationale

Following this convention results in form layout names that are more concise. The form layout name usually aligns better with the work flow step name, and it is clear what action is associated with the form.

Examples

Rationale

This best practice applies to any type of configuration record. Adding the zHISTORY prefix puts the configuration record at the bottom of the list and makes it clear that the configuration record is no longer being actively used.

Examples

Rationale

If you name a custom page layout after a global page layout and you want to import the page layout into another environment, you will get an error.

Examples

Rationale

Adding the COPY suffix makes it clear that the layout is a copy and including the original name will help you keep track of which layout you originally copied.

Examples

Rationale

Following this convention will make it easier for you to quickly pick out the correct page layout.

Examples

Rationale

This best practice applies to any type of configuration record. Adding the zHISTORY prefix puts the configuration record at the bottom of the list and makes it clear that the configuration record is no longer being actively used.

Examples

Rationale

Following this convention will make the purpose of the layout clear.

Examples

Rationale

Following this convention will make the purpose of the layout clear.

Examples

Rationale

Some clients have pages that are tied to an Excel workbook. This integration is initially configured by your Professional Services representative. If you have this functionality enabled, distinguish integrated pages by including the word Model in the page title.

Examples

Rationale

List layouts allow you to display a list of the same type of record—for example, the Accounting Assumptions page in the Contracts module. Since the list layout will contain multiple records of the same type, name the list layout after the type of record will be contained in the list.

Keep in mind, some global list layouts also have child list layouts—such as the Recurring Expenses (Expense Setup) list layout, which has the Expense Schedule, Expense Allocation, and Vendor Allocation list layouts as children.

Examples

Rationale

A common use case for a list layout outside of an actual page layout is when they are incorporated into a report or form. A common example is a Lease Abstract report, which may include list layouts from the Contract Terms or Covenants pages.

Examples

Rationale

Following this convention helps users identify the purpose and context of the sub-page, so that it is not used in another page layout.

Examples

Rationale

Some clients have sub-pages that are tied to an Excel workbook. This integration is initially configured by your Professional Services representative. If you have this functionality enabled, distinguish integrated sub-pages by including the word Model in the page title.

Examples

Rationale

Following this convention gives users a better idea of what type of information is contained within the sub-page.

Examples

Rationale

This best practice applies to any type of configuration record. Adding the zHISTORY prefix puts the configuration record at the bottom of the list and makes it clear that the configuration record is no longer being actively used.

Examples

Rationale

Your ad hoc binder template is used when your users want to create a binder that does not follow one of your preconfigured templates. We recommend titling it Ad Hoc, or some other term which implies its usage—such as "empty", "undefined", or "blank".

Examples

Rationale

Following this convention clearly indicates to users how they should use the binder template.

Examples

Rationale

Following this convention clearly indicates to users what type of document they need to upload.

Examples

Rationale

You can only apply one budget template to an entity. In order to increase the usefulness of a budget template, it should be generic enough that it can be used for multiple contexts.

Examples

Rationale

If a company acquires another company, they may have to work with more than one ERP system until the two companies are fully merged. Another scenario is when multinational companies use different ERP systems based on differing operating units. Specifying the ERP system in your Budget Template name clearly indicates which template is appropriate to use.

Examples

Review the following expanding sections for naming conventions for the folder template itself.

Include the module name in the folder template.

If you have multiple folder templates for a module, include a common theme in the template name.

Review the following expanding sections for naming conventions for folders within the folder template.

Do not add prefixes to folder names.

Don't include date- or timing-information in your folder name.

Do not add version names to folder names.

Do not include the words "current" or "latest" in your folder names.

Do not include the name of the containing module in your folder names.

For root folders or other folders that contain folders, include the department name or purpose of the grouped sub-folders.

For folders that just contain documents, include a common theme of the contents in the folder name.

Rationale

Following this convention will keep your capital project schedules together on the page.

Examples

Rationale

Following this convention makes it clear to users which schedule template they should apply to the entity.

Examples

Rationale

Having generic templates that capture common tasks increases the usefulness of the template across your portfolios.

Examples

Rationale

Having a generic template which captures 90% of your tasks in combination with sub-schedules that capture the remaining tasks allows you to still include more specific schedule tasks in your schedule.

Examples

Rationale

Including the process name will help your users understand for which circumstances the work flow is appropriate.

Examples

Rationale

Keeping your work flow names simple and to the point makes them easier to understand.

Examples

Rationale

Following this convention allows you to differentiate between work flows that are unique to specific departments.

Examples

Rationale

Since work flow steps are sorted alphabetically in the Report Builder, following this convention makes it easier to find work flow steps to insert into reports.

Examples

Rationale

Following this convention results in form step names that are more concise, and it is clear what action is associated with the step.

Examples

Rationale

Following this convention makes it easier to link the task step to the appropriate task in your schedule.

Examples