Custom fields and extensibility

Adding a field the platform does not ship, without a release and without touching the core tables.

A field your business needs and the platform does not ship is added as a custom field. It is defined per company, attached to a resource, given a type and a label, and it then appears on that resource’s form, its list columns, its filters, its import mapping and its export.

Custom fields live outside the core tables, so adding one does not alter the schema every company shares.
They are ordinary fields once defined — filterable, sortable, importable and exportable, not a note field with a label on it.
They are per company, so one company’s additions are invisible to another.
A Yes/no field is drawn like the product’s own check boxes: the box beside its label, the label clickable, the help directly underneath.

Before adding one, check whether a classification list does the job. If what you want is a new value in an existing dropdown, that is configuration, not extension.

Making a field required

To make a field always mandatory, or mandatory before a step such as Submit or Post, use Platform › Customization › Field Requirements: tick it, no rule to write. See Making any field mandatory: Field Requirements. Custom Logic, below, is for a condition.

Platform → Customization → Custom Logic holds the rules a company writes for itself: a validation that refuses a save, a value worked out every time a record is saved, and a default for a new record. To make a field mandatory — one the product ships or one you added — write a validation on that screen that is true only when the field has a value, and give it the message people should see when it does not.

Open Platform → Customization → Custom Logic and choose the module and screen — HRMS, Employees.
Add a rule of kind Validate, run on every save.
Write the condition that must hold. not_empty(iqama_number) makes the Iqama number required on every employee. is_saudi or not_empty(iqama_number) requires it of everybody who is not a Saudi national, which is usually what is meant: a Saudi national has a national ID, not an Iqama.
Write the message — "Iqama number is required for an employee who is not a Saudi national" — and save. Test it on the same screen against a record before relying on it.

The rule is checked by the server on every save, whichever way the record arrives: the form, an import, ASK or the API. Changing an existing record so that it breaks the rule is refused too.

In Saudi Arabia the employee form also carries the Saudi record — Saudi national, Iqama number and expiry, work permit expiry, GOSI number and subscriber class, sponsorship transfer, the Hijri hire date, and the basic wage and the housing and transport allowances GOSI is computed from. Any of them can be made required this way. The form already shows only the ones that apply: Iqama number and expiry, work permit expiry and sponsorship transfer when Saudi national is not ticked, and GOSI subscriber class when it is.

Seeing the values your fields hold

Platform → Customization → Custom Fields shows, for the screen you choose, a table of that screen’s records with your company’s own fields as columns. It is searchable and paged like any list, so you can check what has been filled in without opening records one by one.

Only the records you could already open on that screen are listed.
The fields are shown by their labels, as people see them on the form — not by any internal name.

The same plain presentation is used wherever values are listed for you to read: an audit entry’s detail, an agent’s request for approval and the result of an action show a table of field and value rather than raw data.