Custom Properties

Custom properties let you extend Lowgile objects with application-specific data.

The details can vary by object type, but the basic workflow is the same: open the object editor, add a property, choose a type, configure any object-specific settings, and save the object.

Use this page as the reference for creating and configuring custom properties across all Lowgile object types, including static entities, transactional entities, screens, processes, and user-defined configurations.

What is a custom property?

A custom property is a user-defined field that belongs to a Lowgile object.

Depending on the object type, a property can be used to:

• Store business data,
• Define reference data,
• Hold screen state,
• Pass data into or out of a screen,
• Store process-level workflow data,
• Configure reusable application settings, and
• Bind UI components to object data.

Common property creation workflow

Most Lowgile object editors use the same basic pattern for creating custom properties.

1. Open the object in the object editor.
2. Find the section where properties, variables, fields, or structure are defined.
3. Add a new property.
4. Enter a property name.
5. Define the property type (string/number/boolean/[Static Entity]).
6. Configure other setttings such as input type (input field/dropdown), expression, and default value.
7. Save the object.

💡

Insight

The exact labels in the editor may differ by object type. For example, screen-level properties are often configured as variables, while entity properties are configured as data fields. The underlying pattern is still the same: define a named property, assign a type, and decide how the value is created, stored, or passed onward.

Example configuration

The following example shows a screen-level property configuration for a PurchaseRequest object.

Property	Value	Purpose
Name	request	The variable name used to reference the object throughout the screen
Context	Local	Indicates that the screen owns and manages this object locally
Type	This.PurchaseRequest	Defines the object type stored by the property
Default expression	new This.PurchaseRequest({}, true)	Creates a new PurchaseRequest object when the screen loads

Property names

Use clear, descriptive names that explain what the property stores.

Good property names are specific enough to make sense when used in bindings, scripts, expressions, and workflow logic.

For example:

Recommended	Avoid
purchaseRequestNumber	pr1
approvalStatus	status2
requestTotal	amount
vendorName	name1

Use lower camel case (camelCase) for custom property names unless the project has a specific naming convention.

Common property types

Lowgile supports different property types depending on the object being configured. The most common property types are simple TypeScript-style primitive types, object references, and collections.

Type	Example	Use
string	vendorName	Text values such as names, labels, comments, and descriptions
number	requestTotal	Numeric values such as quantities, totals, scores, and amounts
boolean	isApproved	True or false values such as approval flags or visibility toggles
This.StaticEntityName	This.CostCenter	A reference to a static entity entry, such as a cost center or currency
This.EntityName	This.PurchaseRequest	A reference to another transactional or structured object
This.ObjectName[]	This.PurchaseRequestItem[]	A collection of objects, often used for line items or related records

Screen property contexts

Screens commonly use three property contexts: Input, Local, and Output.

Context	Use
Input	Receives a property or object from another screen, task, or process
Local	Creates and manages a property inside the current screen
Output	Exposes a property to a process or parent object

Use Input when a screen receives data from another context. Use Local when the screen owns and manages the data itself. Use Output when the screen returns data to a process or parent screen.

Default expressions

A default expression defines the value a property starts with.

Default expressions are commonly used when a screen needs to create a new object before the user starts entering data.

For example, a create screen can initialize a new purchase request like this:

new This.PurchaseRequest({}, true)

This creates a new PurchaseRequest object that becomes available to the screen for data binding, screen inputs, and process submission.

Best practices

• Define the property on the object that owns the data.
• Use input properties when a screen receives data from another context.
• Use local properties when a screen creates or temporarily manages data.
• Use output properties when a screen needs to return a decision or payload to a process.
• Use static entity types for controlled lists such as statuses, currencies, and cost centers.
• Save the object after creating or editing custom properties.

Related documentation

• Static Entities Reference
• Transactional Entities Reference
• Screen Object Reference
• Process Object Reference
• User-Defined Configurations