Send reliable SMS notifications from IFS events

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.

Connect one narrowly scoped IFS event to a Clickatell sandbox SMS setup, then prove both provider acceptance and delivery to a controlled test phone. Keep the initial message fixed so you can diagnose transport separately from business templating.

Before you start

Use a Clickatell sandbox/API setup and a test phone you control. In IFS, use a development workflow/event and a single fictional business record. Confirm the chosen sender/region supports the intended type of message.

Clickatell has multiple API products with different credentials and request formats. Use the sample generated for your actual API setup rather than combining an old endpoint with a new key.

1. Create and test the provider setup

In the Clickatell portal, open My Workspace → SMS → New SMS Setup. Choose API use, the required one-way/two-way option, the intended region/number settings, and the available HTTP or One API product. Create the setup in Sandbox and add your test phone.

Open the setup’s generated request example. Record the method, HTTPS URL, content type, authentication location, recipient format, body fields, and response message-ID field. Keep its API key in approved secret storage.

Send a fixed message through the provider’s own test facility first:

LAB-SMS-032: development notification test. No action required.

Confirm it arrives on the test phone. Do not proceed with IFS until the provider-only test works.

2. Create the IFS workflow without a business trigger

Open Workflow Manager → Workflow, create a unique lab process key, and add Start → IFS REST Call → End. Keep it unregistered to a live business event while configuring the external call.

If your API requires a secret in a query string or an unsupported authentication scheme, place an approved HTTPS relay in front of it that protects the credential and restricts recipients. Do not put provider keys into workflow script variables or exported URLs.

3. Configure the REST task from the tested contract

Set the method and URL to the values proven in step 1. Use IFS REST Task Configurations for supported authentication and environment values. Use OAuth/Bearer configuration only when it matches the provider’s actual scheme; adding the word Bearer to a raw API key does not make it correct.

Map the provider’s body fields to the fixed test phone and fixed message. When adding dynamic values later, construct JSON with JSON.stringify, not string concatenation. Configure the output JSONPath for the provider message ID using the real response sample.

Inspect/run the lab workflow once. Capture the provider ID and verify actual delivery. Inspection of a REST task can send real messages, so keep the recipient fixed and use the sandbox throughout this exercise.

4. Add a narrow IFS event trigger

Identify the exact business transition that should send the notification. In Custom Events, choose the actual entity/table and changed attribute, expose only required old/new attributes, and publish/enable the event. Prefer an existing application event when it already represents the transition.

Create a Workflow event action for the deployed process and choose asynchronous execution where supported for this notification. Add conditions for the intended transition and lab record. An update to an unrelated field must not send a message.

Do not place the provider call in a row-level SQL trigger or make a business save wait indefinitely for SMS delivery.

5. Add delivery state and duplicate control

Keep a durable notification record containing business event/reference, recipient reference, provider message ID, attempt state, and final delivery status. Use the provider’s supported callback/status query to move an accepted message to delivered or failed.

An HTTP success is not a handset delivery receipt. For a timeout, reconcile the original reference/provider ID before resending. If the provider does not support an idempotency key, implement duplicate protection in the relay/outbox rather than assuming a custom header prevents duplicate SMS.

6. Run the acceptance cases and clean up

Test the intended transition once, the same event twice, an unrelated field update, an invalid test phone, and provider rejection. Verify the duplicate case sends no second intended notification and the unrelated update sends none.

For dynamic text, keep sensitive business detail out of the message and inspect Unicode/segment behavior before enabling longer templates. Disable the lab event action before deleting the workflow or revoking the key. Record both IFS workflow evidence and provider delivery evidence.

Provider setup reference: Clickatell SMS API setup.

Sources and scope

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