Custom Commands in IFS Aurena: Adding Buttons That Actually Do Things

Introduction

If you've spent time in IFS Aurena, you know that out-of-the-box functionality is powerful—but rarely covers everything your business needs. That's where custom commands come in. Custom commands are the buttons and actions that transform Aurena pages from "display-only" interfaces into active business tools where users can execute custom logic, update records, and drive workflows.

IFS Cloud offers two routes, depending on target release and requirement:

1. Configuration Path — Wire a supported configured action/command where Projection Configuration and Page Designer provide the needed capability
2. Developer Studio Path — Define a projection action and client command as source when the feature needs a durable customer component or richer flow

This guide covers both approaches, complete with PL/SQL wiring, confirmation dialogs, parameter passing, and the gotchas that trip up newcomers.

---

Part 1: Understanding Custom Commands & Actions

Before you build, you need to understand the relationship between two core concepts:

Custom Actions: The Backend API

A Custom Action is a PL/SQL method you want to expose through the Aurena UI. It lives in the database (typically in your business logic packages) and is registered in a Projection Configuration.

Configured-action signature support has varied across IFS Applications 10 and IFS Cloud releases. In Apps 10 and early Cloud documentation, the usual safe shape was a procedure with simple VARCHAR2, NUMBER, or DATE input parameters and no return value; complex PL/SQL records and large-object parameters were not suitable. Use the target release's Projection Configuration assistant as the authority, keep the signature small, use public/customer-owned server methods, and approve/publish the configured action before use. For a richer typed contract or return value, use source-developed projection actions/functions rather than forcing an unsupported configured signature.

Commands: The User-Facing Buttons

A Command is what users click. It's the glue between the page and the backend logic. Commands can:

• Execute Custom Actions (calling PL/SQL methods)
• Navigate between pages (with or without parameters)
• Navigate to external URLs
• Execute Quick Reports
• Open dialogs with confirmation logic

---

Part 2: The Configuration Path

For most functional consultants and admins, the Configuration path is the practical choice when a suitable supported server method already exists. Configuring the action and command requires no client-source rebuild. Creating a new customer-owned PL/SQL wrapper still requires the normal source, build, and delivery process.

Step 1: Define the Custom Action

Navigate to Projection Configuration (or create a new projection):

1. Go to the relevant projection (or create one using the New Projection Configuration Assistant)
2. In the Add Actions step:
   • Action Name: Start with an uppercase letter. No spaces. Example: ApproveOrder
   • PL/SQL Method: Select from the list of available procedures in your logical units
   • LU Dependencies: Choose entities that need to refresh after the action runs (e.g., CustomerOrder, OrderStatus)
   • Action Approved: Toggle to approve the action
   • Action Published: Toggle to publish it

Example:

Action Name: ReleaseCustomerOrder
PL/SQL Method: ACME_ORDER_ACTION_API.Release_Order
LU Dependencies: CustomerOrder, OrderStatistics

After saving, the action is registered in the projection and available for command mapping.

Step 2: Add the Command to a Page

Navigate to the Aurena Page where you want the button:

1. Click Aurena Page Designer (or the design icon in the page header)
2. Under the Active Page, find the Commandgroups section
3. Click the + icon next to Commandgroups
4. Select Execute Action (not Navigation Link)
5. Fill in:
   • Label: Text for the button (e.g., "Release Order")
   • Action: Select your Custom Action from the dropdown
   • Parameter Mappings: Map the action parameters to page/record attributes

Parameter Mapping Example: If your action needs OrderNo and CompanyId:

• OrderNo → Map to record attribute OrderNo
• CompanyId → Map from a validated page attribute or let customer-owned server logic derive the permitted company; do not trust a client-supplied company as authorisation

Click the Edit icon next to "Parameter Mappings" to configure this.

Step 3: Deploy and Test

1. Submit/publish the configuration through the environment's supported workflow
2. Grant the underlying projection/action and page to a test permission set
3. Test the command with a normal user and confirm the configured refresh dependencies update the page

Never expose a guessed private method such as CUSTOMER_ORDER_API.Release__. Double-underscore methods are generated private interfaces. Reuse a public entity action/API documented for the release, or expose a customer-owned server action that calls supported business behaviour.

---

Part 3: The Developer Studio Path

For developers who want full control, custom commands in Developer Studio offer:

• Conditional logic (enable/disable based on record state)
• Confirmation dialogs with custom messages
• Multi-step workflows
• Client-side validation before calling the backend

A source command calls an action or function published by its projection; it does not call an arbitrary package method directly. For example, a bound action can be declared on the projection entity:

Generate the server scaffold and implement the action through the release-supported layered PL/SQL workflow. Bound entity keys are implicit in the projection declaration, and the framework commits or rolls back the action.

Step 1: Create or Edit the Client File

Client files live in the client-source area of the owning component. Customer functionality should normally live in a customer-owned component rather than being placed casually in an IFS-delivered component such as FNDBAS. Client files define pages, fields, dialogs, and commands over the projection model.

Basic Command Structure:

call parameters are positional in client source. For a bound action, pass the entity key or composite keys first and then any explicit action parameters in declaration order.

Step 2: Add Confirmation Dialogs

Confirmation dialogs prevent accidental actions. The syntax is simple:

The confirm() function supports two outcomes: OK and CANCEL. The when blocks define what happens for each.

Step 3: Pass Parameters from the Page

If your PL/SQL method needs parameters, map them from the record context:

Here, OrderNo, CustomerEmail, and ApprovalDate come from the current datasource/dialog context. Do not assume CustomerRef.Email, TODAY, or a named-argument assignment is valid unless Developer Studio exposes it for that model and release.

Step 4: Conditional Enable/Disable

You can enable or disable commands based on record state:

If ObjState is not Planned, the button will be greyed out. The server action must re-check state and authorisation because a direct API caller can bypass the client expression.

Step 5: Add Commands to the Page Structure

In the page definition, reference the command:

This assumes the projection publishes the CustomerOrders entity set. The exact page binding and command-reference placement must match the existing client model and target release; use Developer Studio completion to validate it.

Step 6: Deploy the Client File

1. Validate the .client and .projection sources in the release-aligned Developer Studio
2. On an Apps 10 or developer-VM workflow, generate and deploy the affected artefacts to the development environment
3. For IFS-managed Cloud, deliver the source through the normal build and delivery route; then refresh applicable metadata/client caches. An ordinary client-model change should not require a blanket server restart
4. The commands now appear in the command toolbar

---

Part 4: Advanced Techniques

Passing Hidden Parameters

Sometimes you need to pass a parameter that isn't displayed as a field on the page:

In the Configuration path, you can add attributes to the page that aren't visible in the UI, then use them in parameter mappings.

In Developer Studio, pass them directly:

The server can obtain the authenticated user and transaction time from supported application context; do not trust client-supplied CreatedBy or assume CURRENT_USER/NOW client symbols exist.

Using Dialogs Instead of Confirm

For more complex interactions, use dialog:

This assumes SelectDateDialog is defined in the client or an included fragment and returns a date through its output contract.

Navigation After Execution

Some workflows require navigating to another page after a command completes:

---

Part 5: Common Pitfalls & Solutions

Pitfall 1: Parameter Not Mapping Correctly

Problem: You've added a field to the page, but the command still passes NULL.

Solution: In Parameter Mappings, ensure the attribute is correctly selected from the dropdown. For nested references (like CustomerRef.Email), make sure the reference is included in the page's projection.

Pitfall 2: Server Method Does Not Appear

Problem: Your PL/SQL method exists but doesn't appear in the Custom Action LOV.

Solution: Ensure:

• The method is public/customer-owned and its signature is supported by the target release's configuration assistant
• The operation type matches whether state changes or a read-only result is required
• The owning logical unit/component and projection configuration are approved and published

Pitfall 3: Button Is Enabled But Does Nothing When Clicked

Problem: You've added a command, but nothing happens.

Solution: Check:

• Is the PL/SQL method actually callable? (Permissions, grants)
• Have you deployed the projection configuration or client file?
• Does browser/network evidence show stale metadata, a forbidden action, or a server validation error? Refresh only the applicable metadata/client cache

Pitfall 4: Confirmation Dialog Doesn't Appear

Problem: The action runs immediately without asking for confirmation.

Solution: Ensure confirm("..."); executes before the state-changing call, then inspect the generated client and deployed version. Developer Studio allows an OK continuation, a CANCEL continuation, or both; omitting one branch does not by itself suppress the dialog.

Pitfall 5: Migration from Apps 10 IEE Custom Menus

Problem: You have custom menu items from IEE that don't work in Aurena.

Solution: IFS Cloud Web does not consume IEE custom menus directly. Map each useful outcome to a standard Cloud command, configured action, navigation entry, workflow, or source client command. Reuse PL/SQL only after verifying public APIs, transaction behaviour, managed-Cloud support, and target-release signatures.

---

Part 6: Configuration vs. Developer Studio: When to Use Each

Use Configuration Path If:

• You're a functional consultant without a development environment
• The command is simple (one action, no complex conditionals)
• You want faster time-to-value (no build/deploy cycle)
• You don't need client-side validation or complex dialogs
• Any visibility/enabling rules fit what Page Designer supports in the target release

Use Developer Studio If:

• You have a development environment set up
• The command needs conditional logic or complex dialogs
• You want to build reusable custom pages
• You're migrating complex workflows from IEE
• You need version control and team collaboration

---

Part 7: Best Practices

1. Name Actions and Commands Clearly

Use action names that describe what they do:

• ✅ ReleaseCustomerOrder
• ❌ Action1

Use command labels that match your business process:

• ✅ "Release to Warehouse"
• ❌ "Execute"

2. Add Confirmation for Destructive Actions

Use confirmation for operations that are difficult to reverse or have external effects. Routine state changes do not all need a warning; repeated confirmations train users to click through.

3. Guide in the Client, Validate on the Server

In Developer Studio, use enabled and visible expressions to guide users before calling the action:

The enabled expression is user guidance. The projection action must validate state, permission, data scope, and concurrency again.

4. Document Your Custom Actions

In the Projection Configuration, document what each action does in comments. In Developer Studio, use inline comments in the client file:

5. Test Parameter Mappings Thoroughly

When you add commands, test with different record states and parameter values. Ensure that hardcoded parameters and mapped attributes work as expected.

6. Plan for LU Dependencies

Choose your LU dependencies carefully. They tell Aurena which entities to refresh after the command runs. Too few, and stale data displays. Too many, and performance suffers.

Example: If your action updates both CustomerOrder and CustomerOrderLine, list both as dependencies.

---

Part 8: Real-World Example: Multi-Step Approval Workflow

Let's build a complete example: a Purchase Order approval workflow with confirmation and conditional logic.

Step 1: Discover or Create Supported Actions

In Projection Configuration, add two actions backed by a customer-owned wrapper. A practical wrapper contract is:

Action 1:
  Name: ApprovePurchaseOrder
  Method: ACME_PURCHASE_APPROVAL_API.Approve
  Parameters: OrderNo
  Dependencies: the purchase-order entity and affected summaries

Action 2:
  Name: RejectPurchaseOrder
  Method: ACME_PURCHASE_APPROVAL_API.Reject
  Parameters: OrderNo, RejectReason
  Dependencies: the purchase-order entity and affected summaries

The wrapper should validate the caller, order state, authorisation setup, and concurrency, then call the public purchase-order behaviour supported by the target release. Depending on release, public operations can include methods such as PURCHASE_ORDER_API.Approve_Released and PURCHASE_ORDER_API.Reject_Authorization, but their signatures and applicability are setup-specific. Do not substitute private state-machine methods such as PURCHASE_ORDER_API.Approve__ or PURCHASE_ORDER_API.Release__.

Step 2: Add Commands to the Page (Configuration Path)

In Page Designer, add two commands:

Command 1:

• Label: "Approve"
• Action: ApprovePurchaseOrder
• Parameter Mappings:
  • OrderNo = current record's order number

Command 2:

• Label: "Reject"
• Action: RejectPurchaseOrder
• Parameter Mappings:
  • OrderNo = current record's order number
  • RejectReason = a validated page field or other input mechanism supported by that release

Step 3: Alternative - Developer Studio Version

PurchaseOrderApproval and ApprovalStatus are illustrative customer projection items, not claims about the standard purchase-order state model. The dialog must be defined in the client and its action parameters must match the projection metadata positionally. Notification should be an idempotent downstream effect, not an unverified promise in the confirmation text.

Step 4: Test

1. Create a test PO that is pending approval under the customer's authorisation setup
2. Navigate to the PO detail page
3. The "Approve" and "Reject" buttons appear only for an approval item in Pending status
4. Click "Approve", confirm the dialog, and verify the approval status and intended purchase-order outcome

---

Part 9: Troubleshooting Checklist

---

Conclusion

Custom commands are the bridge between Aurena's UI and your business logic. Whether you choose the Configuration path (faster, simpler) or Developer Studio (more control, more power), you now have the tools to:

• Expose PL/SQL methods as user-facing buttons
• Add confirmation dialogs to prevent accidents
• Pass parameters from pages to backend logic
• Build conditional workflows based on record state
• Navigate between pages after actions complete

Start simple—add a single action and command to test your setup. Once you're comfortable with the basics, layer in confirmation dialogs, conditional logic, and multi-step workflows.

Your users will love having buttons that actually do things.

---

Further Reading

• IFS Custom Actions & Commands Documentation
• IFS Developer Studio client-source reference
• Custom Action Configuration Guide
• IFS Community: Search for "custom commands Aurena" for real-world examples