Custom Enumerations in IFS Cloud: Using Them Safely

Custom enumerations are one of the simplest ways to make IFS custom data cleaner. Instead of letting users type free text into a custom attribute, you provide a controlled list of database values and client-facing descriptions.

The important correction: in IFS, a custom enumeration is already treated as a data type for custom attributes. It is not just a cosmetic dropdown. IFS documentation describes custom enumerations as fixed lists of values with a database representation and a client representation, usable by custom fields, information cards, and custom logical units.

What a Custom Enumeration Is

A custom enumeration is a fixed value list:

• A DB value is stored in the database.
• A client value is displayed to the user.
• Values can be sequenced and translated.
• The enumeration can be reused by custom attributes.
• The enumeration must be approved and published before it is available.

Typical examples:

• Order priority: LOW, NORMAL, HIGH
• Risk level: GREEN, AMBER, RED
• Approval route: LOCAL, REGIONAL, GROUP
• Source channel: PORTAL, EDI, PHONE, EMAIL

When to Use One

Use a custom enumeration when the list is:

• Short
• Stable
• Meaningful as a bounded domain
• Shared by one or more custom attributes
• Safe to expose as a dropdown

Good examples include status-like or category-like values where the business has an agreed vocabulary.

Avoid custom enumerations for long or frequently changing lists. IFS documentation specifically warns that lengthy lists create usability problems. For those cases, use a custom reference connected to a custom logical unit so users can search with LOV behaviour rather than scroll a huge dropdown.

Creating One

The normal configuration flow is:

1. Open the Custom Enumeration page.
2. Create a new enumeration using a valid PascalCase-style name.
3. Add values with DB Value, Client Value, and sequence.
4. Approve the enumeration and values.
5. Publish the enumeration.
6. Translate client values if required.
7. Use the enumeration on the relevant custom attribute.

The DB Value should be treated as a stable contract. Once data exists, changing DB values becomes a data migration exercise. If the label needs to change for users, change the client value or translation rather than casually changing the stored value.

Custom Enumeration vs Custom Reference

Choose custom enumeration when:

• There are a small number of options.
• Options rarely change.
• Users do not need advanced search.
• The value behaves like a type or status.

Choose custom reference when:

• The list is long.
• Users need LOV search.
• Values have additional attributes.
• Values are maintained as business data.
• The list changes often enough that a simple fixed list becomes awkward.

Example: "Warranty Status" is a good enumeration. "Approved Supplier" is normally a reference, because suppliers are real records with names, IDs, statuses, and other metadata.

Developer-Side Enumerations

IFS development also has modelled enumerations in the server or projection model depending on the artefact being built. Those are a different concern from UI-configured custom enumerations.

For customisations built in Developer Studio, validate the enumeration syntax against the exact target release and keep the model in the correct layer. Do not copy syntax from another IFS release without checking it in Developer Studio.

Data and API Considerations

Custom enumerations affect more than the screen:

• Migration jobs must load the DB value, not the translated display text.
• Integrations should treat DB values as stable codes.
• Reports should display client values where users need readable output.
• Translations need ownership if the system is multilingual.
• Removing an enumeration value that has been used in data needs an impact check.

Before changing a value list, search for usage in:

• Custom attributes
• Migration jobs
• Quick reports and report data sources
• Integrations
• Saved filters or user processes
• Documentation and training material

Practical Naming Rules

Use names that will still make sense in two years:

• OrderRiskLevel
• SupplierOnboardingStatus
• ServicePriority
• CustomerSegment

Avoid:

• Enum1
• NewStatus
• TempList
• Names tied to a project code that users will not understand later

Key Takeaways

• IFS custom enumerations are fixed value data types for custom attributes, not just UI dropdowns.
• Store stable DB values; show friendly client values.
• Keep enumerations short and stable.
• Use a custom reference or custom logical unit when the list is long, searchable, or data-rich.
• Validate Developer Studio enumeration models against the target IFS release.
• Treat changes to published enumeration DB values as data-impacting changes.

References

• IFS custom enumerations documentation
• IFS Developer Portal
• IFS Developer Studio model syntax reference