Default values

What this is about

A default value is the value a field gets on create when the client does not send one. You set it on the field in the hub: for simple fields as “default value”, for enum fields as “preset value”.

Creating with defaults

Request

POST /api/rest/preset/create
{ "data": { "note": "vom Client" }, "response": ["+"] }

Response

{
  "data": {
    "id": "3f0c…",
    "_createdOn": "2026-09-21 10:15:02",
    "_updatedOn": null,
    "label": "unnamed",
    "status": "NEW",
    "amount": 7,
    "ratio": 1.5,
    "active": true,
    "dueOn": "2026-01-01",
    "startedAt": "2026-09-21 10:15:02",
    "note": "vom Client"
  },
  "meta": { "error": false }
}

Only note came from the client. All other fields got their default. startedAt got the time of creation through NOW().

The kinds of defaults

There are two kinds: a fixed value (literal) that is always the same, and NOW(), which is evaluated again on every create.

Field type	fixed value, example	`NOW()`
Text	`unnamed` (spaces at the edges are removed)	–
Integer, decimal	`7`, `1.5`	–
Yes/No	`true` or `false`	–
Enum	name of the value, e.g. `NEW`	–
UUID	`3f0c1d2e-…`	–
Date	`2026-01-01`	`NOW()` or `LocalDate.NOW()` → today
Time	`08:00:00`	`NOW()` or `LocalTime.NOW()` → now
Timestamp	`2026-01-01 08:00:00` or `2026-01-01T08:00:00`	`NOW()` or `LocalDateTime.NOW()` → now

Upper and lower case do not matter for true/false and for enum names. There are no other functions besides NOW(). Relations have no default. A reference or list is empty on create if it has no value.

When a default applies

Does the field get its default?

Operation	Value in the request	Result
Create	field missing	Default
Create	field is `null`	Default
Create	value	Client's value
PUT	field missing or `null`	no default, the field is cleared
PATCH	field missing	no default, the field stays unchanged
PATCH	field is `null`	no default, the field is cleared

“Create” means: every object that is newly created. This also applies to a child without id that is created along with it in a PUT or PATCH of its parent object. The child gets its defaults, the parent object does not.

The default in the flow

Where the default is inserted on create

1

Client→CDMS
sends POST /preset/create with { "note": "vom Client" }
2

CDMS
goes through every field; if the value is empty and the field has a default, it inserts the default
3

Hook
Before hooks see the object with the defaults and can overwrite them
4

CDMS
checks the rules; a required field with a default is met this way
5

CDMS→Database
saves the object with the inserted values

Because the default is inserted before validation, you can make a field required and still give it a default. The client then does not have to send it. See Validation.

The default lives only in CDMS, not in the database. A row that is created around the API, for example through SQL, does not get it.

An unusable default

When saving, the hub UI checks whether a default fits Yes/No, integer or decimal, and otherwise rejects it with 400. It does not check text, date, time and timestamp. If a default does not fit the field type, such as morgen (“tomorrow”) for a date, the following happens at runtime:

Default does not fit the field type

Field is optionalField is required

When: Not a required field.

1

CDMS
tries to convert morgen into a date
2

CDMS
fails → drops the default and writes a warning to the log
3

CDMS→Database
saves the object with an empty field

Result: 200, the field is null. This happens again on every create.

When: The field also has the rule required field.

1

CDMS
drops the default as above
2

CDMS→Client
the field is empty → 422 cannot-be-null

Result: The client gets a validation error for a field it did not have to fill at all. If it sends a value, it works.

Pitfalls

Where to go next

The whole flow on create: Creating an object
Rules and required fields: Validation
Setting defaults in the hub: Modeling in the hub