Consistent naming and design conventions make applications easier to understand, maintain, and extend. They also have a direct impact on how well filters, processes, and integrations work - because many of these rely on attribute names to match data across objects.

This article defines the recommended conventions for object and attribute naming, and covers technical restrictions you must follow.

​

Every object and attribute has two names.

The System Name is the internal identifier used by the platform, processes, and the OData API. It is limited to 26 characters (24 for objects), must start with a letter, can only contain letters (A-Z), numbers (0-9), and underscores, and cannot contain spaces. It should be uppercase by convention. Once created, a System Name cannot be changed.

The Business Name is displayed to end users in screens and navigation. It has no length restriction and should be descriptive and easy to understand. It does not need to match the System Name. Use singular form - for example, "Contract" not "Contracts".

The Description field should explain the purpose of the object or attribute and provide context for future configurators. It must not simply repeat the Business Name. For attributes, the description appears as a tooltip on screen, so it should describe what the user is expected to enter.

​

Object System Names are limited to 24 characters. Because of this constraint, most organisations adopt a structured coding convention to keep names meaningful within the limit.

A well-structured System Name can encode several pieces of information. For example, an object storing daily allocated data at facility level might be named:

PR_D_FCY_A

A typical structure includes elements such as:

Your organisation can define its own convention, but it must be applied consistently. A naming convention is only useful if everyone follows it.

Object System Names must not end with _V, as this suffix is reserved by the platform.

​

Consistent attribute naming across objects is essential because filters and processes often rely on matching attribute names. The following conventions are recommended.

First unique key attribute - if the first element of the unique key is a reference to an entity, name it NAME. This supports filter reuse and consistent design across objects.

Time-series date attributes - use PRODUCTION_DATE for daily or monthly data, and PRODUCTION_HOUR for hourly data. Even if the period represents a month, the attribute should still be named PRODUCTION_DATE. Consistency is more important than literal accuracy here.

Validity period attributes - always use FROM_DATE and TO_DATE for date-ranged objects. These names are recognised by Virtual Object publication logic and allow filters to be reused across all date-ranged objects.

Use singular names - all attribute names should be singular. WELL not WELLS.

Reuse existing patterns - where a standard already exists for a concept, use it. Do not invent variations.

Monthly data - by convention, monthly values should be stored against the first day of the month (for example, 01 Jan 2025, not 31 Jan 2025). The platform does not enforce this, but inconsistent date storage across objects will cause filters, joins, and time-series aggregations to produce incorrect results.

​

In addition to conventions, there are hard technical restrictions on attribute System Names.

System Names must be between 3 and 26 characters, start with a letter, and contain only letters, numbers, and underscores. They cannot contain spaces or special characters.

Certain words are reserved by the database and cannot be used as attribute System Names. These include SQL keywords, data types, and system terms such as SELECT, FROM, WHERE, DATE, NUMBER, TABLE, USER, and many others. If a System Name fails validation on save, choose a different name.

​

There is one special System Name with defined platform behaviour: ES_ORDER.

When added to an object, ES_ORDER must be an Integer, must not be part of the unique key, and should be set to required. The value entered in this field controls how records are displayed in screens, overriding the default alphabetical ordering by unique identifier. This is most useful for small static lookup lists. It is not recommended for high-volume transactional objects.

​

The unique key is one of the most important design decisions for any object because it cannot be changed after the object is created.

A few conventions to follow:

​

Your organisation may choose to define mandatory attributes for certain types of objects - for example, a Data Status attribute (such as Provisional or Final) applied consistently across all objects that store calculated results. If such conventions are adopted, they should be applied to all relevant objects without exception.

Consistency in standard attributes supports predictable process behaviour, cleaner reporting, and easier maintenance.