Send email notifications from IFS Cloud workflows

Explore this learning path

Documentation-based guide draft · Reviewed against sources on 2026-09-27 · Not executed in an IFS environment. IFS references use 26R1 unless stated otherwise. Confirm available APIs, components, and permissions in your installed release.

Configure a workflow that calls a permitted mail action, then trigger it asynchronously after a narrow business change. The test is complete only when the intended mailbox receives the message; an Application Messages row proves queuing, not delivery.

Before you start

Use a development environment, Workflow Designer and Projection Configuration permissions, a configured IFS Connect mail sender, and one test mailbox. Select a fictional business record and one field whose change will trigger the lab notification.

The workflow needs a callable projection action for mail. A PL/SQL procedure is not automatically an IFS API Task operation. Custom Actions support simple input types; attachment-array/CLOB/BLOB overloads cannot be exposed through that simple configuration mechanism.

1. Expose or select an approved mail action

Open Projection Configuration for an appropriate lab/custom projection. In Add Actions, create an action with a name such as SendLabNotice. Use the PL/SQL method list to select a mail procedure with only supported simple input parameters, checking its Method Option for the correct overload.

For a controlled lab, the legacy simple COMMAND_SYS.Mail overload may be offered with parameters such as from_user_name_, to_user_name_, text_, and subject_. Confirm it in your installed method list rather than selecting an attachment overload by name alone. If it is not offered or your extension policy disallows direct exposure, have the development owner provide a narrow wrapper that fixes the sender/recipient scope and accepts only the required business reference/text.

Approve and publish the custom action through the configuration workflow. Grant it only to the lab role. Check the resulting action and parameter names in API Explorer. Do not broadly expose an arbitrary-recipient mail relay.

2. Build the workflow with fixed inputs

Create a workflow with process key labEmailNotice. In the designer, connect Start → IFS API Task → End. Select the published projection and its mail action as a Call operation.

Map the action parameters shown by the designer. For the simple overload, the lab values are:

Parameter purpose	Value
Sender/user	Approved development sender identity
Recipient	Fixed controlled test mailbox
Subject	LAB-NOTICE-024 workflow check
Body	A development workflow queued this notice.
Attachment/CC/optional fields	Empty unless required by the chosen contract

Use the parameter names generated for the selected overload; do not paste PL/SQL parameter spelling into an unrelated projection payload.

3. Prove mail delivery before adding the event

Save, validate, and deploy the workflow. Run one controlled development execution using the supported workflow tooling. Be aware that inspection/troubleshooting may invoke side-effecting tasks; do not use real recipients.

Open Application Messages, locate the mail by subject/time, and inspect sender/routing status. Check the actual test mailbox, including quarantine/spam handling. Fix the mail sender before proceeding if the message only remains queued.

4. Configure a narrow custom event

Prefer an existing application event if it already represents the required business transition. Otherwise:

1. Open Custom Events and create an event for the actual logical unit/table of the chosen record.
2. Select Update and only the intended changed attribute.
3. Expose the record key and needed new/old values in the event’s Attributes list.
4. Publish/enable the event using the supported UI.
5. Create an event action of type Workflow, select labEmailNotice, and choose Asynchronous timing where supported.
6. Restrict its condition to the intended transition and lab record, then enable the action.

Use asynchronous notification behavior so the business save is not held open waiting for external mail transport. Confirm the actual transaction semantics in your installed workflow/event configuration.

5. Replace fixed body text with mapped context

Inspect the workflow inputs from a real lab event and identify the actual variable names. Add a Script Task before the API task to assemble a bounded subject/body from those variables, then map its outputs to the mail action.

Keep the recipient fixed while validating the mapping. Treat event substitutions such as &NEW:... and workflow execution.getVariable(...) as different interfaces; use inspected workflow names rather than assuming they are identical.

6. Test and clean up

Change the target field once: expect one workflow, one queued message, and one received email. Change an unrelated field: expect none. Test a rejected business transaction, denied action permission, and a failed mail sender. Confirm retries do not create uncontrolled duplicate notices.

Disable the event action first when rolling back, then restore/remove the lab workflow and custom-action grants. Retain the process version, event ID, message ID, and receipt evidence. For multi-file attachments, use the separate report attachment developer procedure rather than passing unsupported complex types through this Custom Action.

Custom-action reference: supported method types and publication fields.

Sources and scope

• IFS event action types
• IFS REST Task

Older IFS Applications examples are historical context, not evidence of Cloud compatibility. No third-party code, screenshots, or downloadable workflows are reproduced.