# How to Add a Custom Field to an IFS Cloud Page > Source: https://netray.co/erp-help/ifs-cloud-add-custom-field-aurena-page > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer In IFS Cloud you add a custom field by opening the page in configuration mode, choosing to add a field, defining its name, type and placement, and publishing the configuration. The field is stored by the platform as configuration, not as a code change, which is why it normally survives upgrades. ## Kind how-to ## System small-erp ## Erp IFS Cloud ## Module Configuration / Custom Fields ## Query how to add a custom field to a page in IFS Cloud ## Alternate Queries - IFS Cloud custom field configuration mode - IFS Aurena add field to page without modification - IFS custom fields survive upgrade - IFS Cloud custom field not showing after creation ## Applies To IFS Cloud web client (Aurena pages); IFS Applications 10 used a similar but not identical custom field experience ## Steps ### How to add a custom field **Items:** - Sign in as a user whose permission set includes configuration access, then open the page where the field should appear. - Switch the page into configuration mode from the user menu or the page options. - Choose to add a custom field, and give it a clear name and a label end users will understand. - Pick the data type (text, number, date, boolean or a list of values) and set length, mandatory and default value rules. - Place the field on the right group, card or list and choose whether it is editable or read-only. - Save and publish the configuration so other users with access to the page see it. - Give end-user permission sets the right to see and edit the field, then test as a normal user. - Move the configuration to test and production through the supported configuration export and import, not by recreating it by hand. ## Sections ### What a custom field really is **Body:** A custom field is platform configuration attached to a logical unit, the IFS business object behind a page. The value is stored in an extension structure managed by the platform, commonly a companion custom field table for that logical unit, rather than by editing the standard table or PL/SQL. That design is why custom fields are the preferred first option. They are declarative, tracked as configuration, and carried through release updates without a merge exercise. A true code modification would not have that property. ### Choosing the data type and rules **Body:** Decide the type before users start filling the field, because changing it later with live data is painful. Free text is tempting but produces dirty data. If the answer is one of a small set, define a list of values. If it is a reference to an existing IFS object such as a customer or part, use a lookup rather than a text field that people type into. Mandatory rules deserve care. Making a field mandatory on a page that integrations also write to can break those integrations, since they may not supply a value. Prefer a default value or validate in the UI layer when only interactive users are the concern. ### When it does not show up **Body:** If the field is saved but invisible, check the usual suspects in order. First, was the configuration published, or is it still a draft visible only to you? Second, does the viewing user's permission set include the page and the field? Third, is the field on a group that is collapsed or on a different tab than you expected? Also confirm which page you configured. The same data can appear on several pages, such as a header page and a list, and a field added on one does not automatically appear on the others. Configure each page where users need it. ### Reports, APIs and limits **Body:** A field that exists on a page is not automatically in every report or integration. Reports, lobby elements and API projections each have their own definition, so check whether the custom field is exposed there. Where the platform supports extending a projection or information source to include it, do that deliberately and document it. Know when to stop. Custom fields fit extra attributes on an existing object. If you need new behaviour, a new entity with its own lifecycle, or logic that fires on events, look at custom objects, events, or an extension built with the proper tooling instead of stacking dozens of fields. ## Pitfalls - Making a field mandatory on a page that integrations also write to. - Using free text where a list of values or a lookup would keep data clean. - Forgetting to publish the configuration, so only the author sees the field. - Recreating configuration by hand in each environment instead of exporting and importing it. - Assuming a page field also appears in reports, lobby elements and API projections. - Letting field names drift, creating near-duplicate fields across environments. ## Ai Angle Before adding a field, teams often need to know whether one already exists, how it is used and which pages and reports depend on it. An assistant grounded in the IFS configuration and data, such as ERPray, can list existing custom fields on a logical unit, check how many records have values, and show the query it used. It reads rather than changes configuration; any write-back remains behind human approval. ## Faq ### Do custom fields survive an IFS Cloud update? **Answer:** Normally yes, because they are stored as platform configuration rather than code changes. You should still retest the pages after each release, since a standard page can be restructured and a field may need to be repositioned or its dependent reports reviewed. ### Can I add a custom field to a standard report? **Answer:** Not automatically. A page field is separate from the report definition. You need to extend the report data source or information source to include the field, and then adjust the layout. Check what your edition and tooling support, and document the extension. ### Why can a colleague not see my new custom field? **Answer:** The most common reasons are an unpublished configuration, a permission set that does not cover the field or page, or the colleague viewing a different page than the one you configured. Publish the configuration and verify access with a normal user, not an administrator. ### When should I use a custom object instead? **Answer:** Use a custom object when you need a new entity with its own records, keys and lifecycle, not just one more attribute on an existing object. Custom fields suit extra attributes; custom objects, events and extensions suit new structures and behaviour. ## Search terms IFS Cloud custom field, IFS Aurena custom field, IFS configuration mode, IFS add field to page, IFS custom field upgrade safe, IFS custom object, IFS Cloud customization, IFS custom field not visible --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json