IFS Cloud 25R2 Workflow Enhancements: Page Refresh, Asynchronous Observability, and Pragma Autonomous Support

My read on 25R2 workflows is the same as my read on 25R1: this is a release about discipline, not flash. The three workflow improvements I want to call out are not the kind of features that get a marketing splash, but they directly fix things that have been quietly hurting IFS customers — especially those who built business-critical processes on top of BPA workflows.

Why These Three Enhancements Matter Together

In real IFS environments, workflows are no longer side automations. They run business processes — order release, credit checks, service object creation, maintenance handoffs, approvals, integrations. When workflows fail silently or behave inconsistently, the operational impact lands directly on planners, schedulers, customer service, and finance teams.

The 25R2 changes address three of the most common pain points I see in client environments: users not seeing updated data after a workflow runs, asynchronous workflows failing or going missing across application updates, and developers being boxed out of valid integration patterns because the framework did not support autonomous transactions.

1. Page Refresh in User Forms and Workflow Commands

Until now, when a workflow updated data behind the scenes — through a user form or a workflow command on a page — the change was not reflected on the screen until the user manually refreshed. That sounds minor. In practice, it is the kind of friction that produces double-clicks, support tickets, and quiet data trust issues.

25R2 introduces a proper Page Refresh option in two places:

• User Forms. In the Workflow Designer, when a user task is added, there is now a Refresh the Page checkbox on the Forms tab. Tick it, and the page refreshes automatically after the workflow finishes, so the user sees the updated data immediately.
• Workflow Commands. In Page Designer, workflow commands now expose a Refresh dropdown that can be set to true or false. The default is false (legacy behavior); set it to true to force an automatic page refresh after the command runs.

Precedence rule worth memorizing: the user form's refresh setting wins over the workflow command's refresh setting. If the form says false and the command says true, the page will not refresh. If the form says true and the command says false, the page will refresh. Get this wrong in a delivery and you will spend an afternoon explaining why two seemingly identical workflows behave differently.

Why Page Refresh Matters on the Shop Floor and in the Office

For manufacturing customers, this small UX behavior carries real business weight:

• Data accuracy. Users see workflow-driven changes immediately. No more stale screens that lead to wrong decisions on order release, credit holds, or work order status.
• Fewer clicks. Planners, buyers, and customer service teams do not have to reload pages between actions. Across a shift, that adds up.
• Fewer errors. A page showing outdated data invites users to re-trigger an action they have already completed. Auto-refresh removes that confusion entirely.

My recommendation is straightforward: audit your existing workflow commands and user forms during your 25R2 upgrade plan. Anywhere a workflow modifies data the user is staring at, enable refresh. Anywhere a workflow runs silently or kicks off a long downstream chain, leave it off intentionally. Document the choice either way.

2. Asynchronous Workflow Execution Observability

This is the most important of the three enhancements, and the one I would flag for any IFS customer using Uptime Maximizer or running async-heavy integrations. Until now, there was effectively no visibility, tracking, or monitoring for asynchronous workflow executions. They worked, until they did not — and when they did not, finding out why was a forensic exercise.

The classic failure mode looks like this:

• An async workflow job is queued under application version A.
• The OData pod restarts or the system is updated to version B.
• When the new pod comes up, queued jobs from version A resume automatically.
• If the interface, API signature, or input format changed between A and B, those jobs fail — often quietly, often hours later.

With Uptime Maximizer, application updates can happen while the system is online. That dramatically increases the chance that async jobs queued under one version will execute under another. Without observability, you are flying blind through your own upgrades.

What 25R2 Gives You

A new Asynchronous Workflow Executions page surfaces every async run directly in the IFS UI, with a sub-page dedicated to cross-version manual review:

• Main page. Lists every asynchronous workflow execution regardless of version, with a default toggle that hides internal cleanup workflows so the operational view stays clean.
• Sub-page (cross-version). Lists async jobs that were queued under the previous version but are still pending or executing under the new version — exactly the population at risk during an upgrade.
• Manual execution. Administrators can review at-risk jobs for interface, API, or input changes, mark them as reviewed (status STOPPED), and then trigger them deliberately with the Execution button. Approved jobs (APPROVED status) are picked up by the next async cycle, which runs every 15 seconds.
• System variable. A new flag, EXECUTE_ASYNC_FROM_PREV_VERSION, decides whether previous-version async jobs auto-execute in the new version. Set it to TRUE for legacy behavior, or FALSE if you want every cross-version job to require explicit admin review.
• Cleanup parameter. The Cleanup Asynchronous Workflow Data scheduler gains a new parameter, CROSS_VERSION_DAYS_OLD_, controlling how long cross-version STOPPED records hang around before being purged.

Access is gated to administrators or users with either FND_ADMIN or FND_BPA_AUTHOR_FNDWF permissions, which is appropriate for what is effectively a workflow integrity control panel.

Why This Is a Big Deal for Manufacturers

If you are running asynchronous workflows that touch order release, credit, shipping, invoicing, work order routing, supplier messaging, or service automation, you are already exposed to silent execution failures during application updates. 25R2 finally gives you:

• A single place to see the health of all async workflow executions.
• A defensible upgrade procedure where cross-version jobs are reviewed before they run.
• A way to set EXECUTE_ASYNC_FROM_PREV_VERSION = FALSE for high-risk environments, forcing human review whenever the version changes.
• A cleanup mechanism so the review queue does not become a junk drawer.

For any manufacturer who has ever experienced "the workflow stopped working after the update and we did not notice for two days," this enhancement alone justifies prioritizing 25R2 in your roadmap conversation.

3. Pragma Autonomous Support in Workflows

This is the developer-facing improvement, but the business impact is real. Until 25R2, IFS workflows did not allow IFS API tasks to invoke APIs containing COMMIT, ROLLBACK, or SAVEPOINT statements. The reason was a good one: atomicity. Either every IFS API task in a workflow succeeds, or none of them do.

The side effect, though, was that PL/SQL procedures using PRAGMA AUTONOMOUS_TRANSACTION blocks were also blocked — even though, by definition, autonomous transactions run independently of the main transaction and do not affect its atomicity. That cut off a legitimate and common integration pattern: logging, audit trails, external notifications, and other side-effect operations that should commit regardless of whether the main transaction succeeds or rolls back.

What changes in 25R2: IFS Workflows now support invoking APIs that contain Pragma Autonomous blocks inside PL/SQL procedures and functions via IFS API tasks. The main transaction's atomicity is fully preserved — COMMIT, ROLLBACK, and SAVEPOINT behavior in the main transaction is unchanged — but autonomous blocks run in their own transactions, independently of the workflow's main transaction.

One important caveat: autonomous blocks will execute even when the workflow is run in troubleshoot mode. That is the right behavior for autonomous semantics, but it means your audit logs, notifications, or external-side-effect code will fire during workflow troubleshooting runs. Plan accordingly — especially if those autonomous blocks send emails, call external APIs, or write to systems that downstream teams will react to.

When Pragma Autonomous Support Matters

Practical examples where this unlocks cleaner design:

• Audit and compliance logging — write the audit record even if the main workflow rolls back, so you have evidence of what was attempted.
• External notification calls — fire a notification or webhook independent of the main transaction's success.
• Reference data updates — increment counters, sequences, or external IDs that should not be undone by a main-transaction rollback.
• Cross-system reconciliation — record outbound calls so downstream reconciliation jobs can detect orphaned operations.

For customers who previously had to work around this restriction by moving logic out of workflows or using async patterns, 25R2 lets the design move back to where it belongs — inside the workflow, expressed cleanly in PL/SQL, with autonomous semantics respected.

My Recommendation for IFS Customers on 25R2

If you are planning an upgrade to 25R2, or already on it and not exploiting these features, my recommended actions are:

• Audit existing user forms and workflow commands and turn on Page Refresh wherever the workflow modifies data the user is viewing. Document the precedence rule for your team.
• Add the new Asynchronous Workflow Executions page to your standard operations runbook. Make reviewing cross-version pending jobs part of every application update, not an afterthought.
• Decide deliberately whether EXECUTE_ASYNC_FROM_PREV_VERSION should be TRUE or FALSE in your environment. For high-risk processes (finance, shipping, customer-facing notifications), FALSE is the safer default.
• Configure the CROSS_VERSION_DAYS_OLD_ cleanup parameter on the Cleanup Asynchronous Workflow Data scheduler so the manual review queue stays maintainable.
• Identify integration logic that was previously twisted around the no-autonomous restriction and review whether it can be simplified using the new Pragma Autonomous support — while planning carefully for the troubleshoot-mode execution behavior.

None of these are dramatic features. They are the kind of release that quietly makes serious IFS environments more reliable, more observable, and easier to support. That is exactly the kind of progress mature customers should welcome.

Planning a 25R2 Upgrade or Workflow Review?

IFS Expert helps North American manufacturers plan and execute IFS Cloud upgrades, audit existing BPA workflow estates, and design new automations that take full advantage of 25R2 capabilities. We can help with upgrade planning and cross-version async job review procedures, workflow command and user form refresh audits, async observability runbooks and admin enablement, and Pragma Autonomous integration patterns for audit, notification, and reconciliation use cases.