Skip to main content
Solved

Missing CUSTOM Functions in Dialog and Assistant Views in IFS Cloud

  • March 12, 2026
  • 2 replies
  • 43 views

SPLPAWWOR
Do Gooder (Customer)
Forum|alt.badge.img+1

IFS Cloud 25R1

Description: 

While attempting to add or enable CUSTOM fields on the Receive Shop Order Manually view in IFS Cloud, we encountered a limitation related to the view type. 

The issue occurs because this view is implemented as a Dialog. As far as we understand, Dialog and Assistant type views currently do not support adding CUSTOM functions. 

In IFS Applications 10, it was possible to add CUSTOM fields for this process because the functionality was available in a separate, standard window rather than a popup (Dialog or Assistant). 

Due to this change in the UI architecture in IFS Cloud, it appears that similar CUSTOMizations cannot be implemented in the same way as before. 

Question: 
Is there any recommended workaround or alternative approach to implement CUSTOM fields or logic for Dialog or Assistant views in IFS Cloud? 

Best answer by jbush0419

@SPLPAWWOR - 

I think that this is a common challenge when migrating customizations from Apps10 to cloud and you're correct in your understanding: 

‘Dialog’ and ‘Assistant’ views dont support the standard custom field framework in Cloud. This is because custom fields require that pages conform to certain common patterns for their underlying storage and implementation, which dialogs and assistants don't follow.

Here are a few potential workarounds I would explore if I was doing the implementation:

1. Check for Page Designer Options

Try accessing the Page Designer for your specific dialog by navigating to the dialog and adding 

?showInPageDesigner=true to the URL. this won't add custom fields, you may be able to modify existing field visibility or behavior within the dialog's constraints. (I don’t know your exact use case)

2. Pre/Post Processing Logic

Have you considered implementing your custom logic before or after the dialog interaction:

  • Add custom fields to the parent page
  • Use “Events” or “Custom Events” to capture data entry
  • Implement business logic through database events or custom packages

3. Custom Entity Approach

If you need to capture additional data:

  • Create a Custom Entity to store your additional information
  • Link it to the shop order using appropriate keys
  • Build separate pages/functionality to manage this data outside the dialog

4. Projection Customizations (mods)

In my implementation, I tend to lean towards creating mods (but we have the capabilities in-house)

  • Custom projections that extend the standard functionality
  • Custom fragments that can be integrated into workflows

The way that I understand it, this architectural change from Apps10 was intentional…. Cloud's framework uses dialogs and assistants for a better user experience - but this comes with the trade-off of reduced customization flexibility in these specific UI patterns. (I also struggled with this when migrating from Apps 10 to cloud) 

unfortunately, there's no direct equivalent to the old separate window approach for this particular process. (at least that I am aware of)

Hope that helps.

 

-jason

2 replies

jbush0419
Do Gooder (Customer)
Forum|alt.badge.img+3
  • Do Gooder (Customer)
  • Answer
  • March 16, 2026

@SPLPAWWOR - 

I think that this is a common challenge when migrating customizations from Apps10 to cloud and you're correct in your understanding: 

‘Dialog’ and ‘Assistant’ views dont support the standard custom field framework in Cloud. This is because custom fields require that pages conform to certain common patterns for their underlying storage and implementation, which dialogs and assistants don't follow.

Here are a few potential workarounds I would explore if I was doing the implementation:

1. Check for Page Designer Options

Try accessing the Page Designer for your specific dialog by navigating to the dialog and adding 

?showInPageDesigner=true to the URL. this won't add custom fields, you may be able to modify existing field visibility or behavior within the dialog's constraints. (I don’t know your exact use case)

2. Pre/Post Processing Logic

Have you considered implementing your custom logic before or after the dialog interaction:

  • Add custom fields to the parent page
  • Use “Events” or “Custom Events” to capture data entry
  • Implement business logic through database events or custom packages

3. Custom Entity Approach

If you need to capture additional data:

  • Create a Custom Entity to store your additional information
  • Link it to the shop order using appropriate keys
  • Build separate pages/functionality to manage this data outside the dialog

4. Projection Customizations (mods)

In my implementation, I tend to lean towards creating mods (but we have the capabilities in-house)

  • Custom projections that extend the standard functionality
  • Custom fragments that can be integrated into workflows

The way that I understand it, this architectural change from Apps10 was intentional…. Cloud's framework uses dialogs and assistants for a better user experience - but this comes with the trade-off of reduced customization flexibility in these specific UI patterns. (I also struggled with this when migrating from Apps 10 to cloud) 

unfortunately, there's no direct equivalent to the old separate window approach for this particular process. (at least that I am aware of)

Hope that helps.

 

-jason


Grzegorz Byrski
Hero (Employee)
Forum|alt.badge.img+10

Thanks ​@jbush0419 

To add to this here are the information I was able to gather regarding the question and validated with my collegues.

It is not possible to add custom fields directly to Dialog or Assistant views in IFS Cloud using the standard Custom Fields functionality. This is due to the architectural design of these views, which do not conform to the patterns required by the Custom Attributes framework. Please refer to 

Recommended Workarounds / Alternative Approaches

Although direct addition of custom fields is not supported, there are a few alternative approaches you can consider:

Option 1: Use Custom Actions or Custom Logic

  • Implement Custom Actions or Custom Events on the underlying entity or process that the dialog interacts with.
  • These can be triggered from the dialog’s standard fields and can execute additional logic or validations in the background.
  • This approach allows you to extend functionality without modifying the dialog UI.

Option 2: Extend the Underlying Entity and Use a Separate Page

  • Add the required custom fields to the underlying entity (Logical Unit) using the Custom Attributes framework.
  • Create a custom page (standard page type) that includes these fields and provides the same functionality as the dialog.
  • Users can then use this custom page instead of the dialog for the extended process.

Option 3: Use Custom Events with Assistants

  • For Assistant views, you can use Custom Events to capture user actions and apply additional logic or validations.
  • While you cannot add fields to the Assistant UI, you can still influence the process flow through event-driven logic. "