What’s New in Oracle Integration – Process 25.04

Welcome to the April edition of What’s New in Oracle Integration – Process. In this update, we’ll cover the most significant features introduced in this release to keep you informed about the latest enhancements.

The 25.04 release delivers the following:

• Support for email-based approvals
• A native action for invoking processes from integrations
• Email template support for:
  • A large set of email variables
  • Using the Mustache syntax to reference data objects in the Notify activity

This blog focuses on the process automation component of the Oracle Integration platform. You can see what’s new in the 25.04 release of the overall platform here.

Approvals now happen where your day already unfolds

We are excited to announce that with the 25.04 (April) release, we will introduce support for email-based approvals. This is a feature that has been eagerly awaited by many of our customers, and we are happy to share its imminent release with you today.

Knowledge workers spend a considerable amount of time in email each day. The ability to approve a request through email enables them to stay focused because it means that they no longer need to leave their inbox to address tasks.

This feature comes with enhanced functionality that allows users to add comments directly through email and includes comprehensive validation and security built in.

We wrote all about this feature here, so if you are interested in bringing this experience to your users, check it out!

Triggering Processes Just Got Simpler

Starting today, kicking off a process from an integration in Oracle Integration 3 is dramatically easier. No more configuring REST connections, fiddling with authentication policies, or manually defining endpoints and payloads.

We have introduced a new native action that lets you invoke a process directly from your integration. It’s streamlined, intuitive, and designed to save you time.

To get stated, you just need to ensure that Process is enabled in your Oracle Integration 3 instance. 

Configuring the Process action is simple; you are guided through a wizard that prompts you to select the target process application and process that you want to invoke from your integration. 

The process application selection is straight forward. You select from a list of active applications in your instance.

The version selection is set to Default, because this is the only available option in this release. This setting ensures that you don’t need to update your integration whenever you make changes to your process (deploy a new process version).

Next, you need to select the process that you want to invoke. Because an application can have multiple processes, you may need to make a selection. The native action shows both message (API) and form start processes here. 

Finally the operation, is defaulted to Create Instance because this is the only operation we support for this release. In the future, we may add additional operations here that allow developers to get or update an instance through this menu.

Once the Process action is configured, you see that the request payload is automatically defined for you, allowing you to easily map data to it. 

Unlike the request definition, the response always has the same structure. Oracle Integration 3 Process returns this response immediately after being invoked using asynchronous or fire-and-forget semantics.  

Before running your integration, you need to ensure that the integration has been given permission to call your process. You can do this by following the steps defined here.

Note: The process action uses the OAuth Client Credential flow at runtime to authenticate with the process. 

Email Templates

We have made the following improvements to our email templates in this release that enable process designers to deliver a more tailored email experience to stakeholders, whether through approval tasks or FYI notifications.

Support for Additional Variables

Email templates have been enhanced to support many new variables that allow process designers to personalize email notifications associated with human tasks.

In this release, we added support for variables such as Human Task outcome, approver comment, assignee / creator display name, process id, task substate, and more.

You can view the full list of supported variables here.

Referencing Data Objects in a Notify Activity

In this release, we have also added support for the Mustache syntax in email templates referenced from the Notify activity! The Notify activity is often used to send FYI notifications to users when no action is needed. 

This means that you can now use the same syntax to reference data objects in email templates regardless of whether these templates are used in Human Tasks or in a Notify activity.

The Mustache syntax offers several benefits to directly referencing data object properties. One major benefit is that it does not surround data objects with double quotes.

To leverage this new format, you need to define a process or form-level data object that contains the required attributes and reference it through the syntax documented here. 

Auxiliary Features 

Human Tasks – Output Variables

We have introduced the following TaskExec variables in this release. These are available on the output data association of a Human Task:

• approvalDuration: Stores the duration (long) taken to approve a task. This is useful when you need to manage SLAs around approval duration and need to notify stakeholders of task completion time.
• substate: Stores the substate (string) of a task. This is useful if you need to know or display if a task is in an expired, escalated, or re-assigned state.

Process Instance Title – Process Level Variables

Process-level variables are now available for selection when setting the Instance Title.

This can be useful for customers who want to display the creator or process instance ID as part of the process instance title.

Re-Assign API

The task re-assign API has been extended to support identifying the assignee through their UserName. This is useful for customers who are interacting with our tasks through APIs and do not know the UserID of the new assignee. This eliminates a call to IDCS that is otherwise needed. 

Final Thoughts

We’re excited to see these features in your hands and look forward to hearing your feedback!

We encourage you to check out the What’s New section of our documentation next for more information that can help you get started.