Build your first validation workflow

26R1 reference · Documentation-based tutorial draft · Not executed in IFS

Workflow learning center

Try the flow interactively

Enter a reference or leave it blank, then step through the same decision used by the downloadable template. Click a node to inspect it.

BROWSER SIMULATION · FICTIONAL DATA · NO IFS CONNECTION

External reference

Matches the nodes and decision in our downloadable BPMN template. Try a reference, empty text, or spaces.

Next stepRun to endReset flow

Ready. Choose Next step or Run to end.

Click a node to inspect it. Highlighted arrows show the path taken; the dashed outline marks the current step. On small screens, scroll the diagram sideways.

Start

The trigger supplies ExternalReference. This teaching flow makes no API or REST calls.

Read the walkthrough

Variables at the current step

No steps executed yet.

Execution trace

1. No steps executed yet.

Download the validation BPMN template. The form and asynchronous diagrams are conceptual maps, not importable BPMN files.

Outcome and prerequisites

Build a small workflow that rejects a missing external reference. You need an authorized development environment, Workflow Designer access, and a real target operation whose input exposes the field you intend to validate.

The fictional process key is demoRequireReference. Start with the original BPMN teaching template. It is marked non-executable for import as a template and has not been imported or deployed in IFS. Its XML and decision script are checked locally only.

1. Create or import

Navigate to Solution Manager → Workflow Manager → Workflow. Either create a workflow with a unique process key or upload the teaching BPMN file.

The imported process key comes from the BPMN process ID. Check for a name collision before importing. A template can be inspected; use Clone as a new Workflow when preparing an executable copy with your own unique process key.

Open the designer. If building manually, add these elements:

Start -> Check reference (Script Task) -> Reference missing? (Exclusive Gateway)
                                         | true -> IFS Failure Event
                                         | default -> End

2. Define the input and decision

The teaching input ExternalReference is a text value. In the Script Task select JavaScript and use:

var reference = execution.getVariable('ExternalReference');
var referenceMissing =
  reference == null || String(reference).trim().length === 0;
execution.setVariable('referenceMissing', referenceMissing);

On the missing-reference sequence flow use this expression, not JavaScript task syntax:

${referenceMissing == true}

Make the success path the gateway’s default. Configure the failure with locale en and a fixed message such as “Enter an external reference before continuing.”

Use the designer’s IFS Failure Event so its required extensions are present. Dynamic failure messages are not supported by the documented FAQ; use separate failure events for distinct messages.

3. Inspect before attaching

Run Inspect with these inputs:

Input	Expected branch
No input variable	Failure
Empty text	Failure
Whitespace only	Failure
DEMO-HO-021	Success

Inspection accepts key/value inputs with inferred types. Keep the reference a string. The download test matrix includes these and integration checks.

This template has no API or REST tasks. If you add them, inspect their side effects before running Troubleshoot.

4. Map to a real operation

Use trigger discovery to capture the actual projection, entity set or call, operation, and payload. Replace ExternalReference in your own copy with the captured field or an explicit mapping.

Save a version, validate, and deploy in development. Create a Validation projection action with Before timing for the precise operation where the value is available. Do not attach broadly to every operation.

Deployment alone does not register a trigger. An event-based implementation uses After and has different input semantics; follow the event instructions rather than copying this timing.

5. Prove the behavior

With the intended business role, exercise the real page or API twice: once missing the reference and once supplying it. Confirm the failure message, persisted result, and absence of unwanted side effects.

Repeat after redeployment and with a user lacking the needed access. Record the release, process key, active version, trigger, inputs, and actual results. Only then can your adapted procedure be described as environment tested.

6. Attach the validation to one captured operation

Before adding further logic, capture the real page action in Developer Tools → Network. Record the projection, entity set or call, operation, and payload field containing the reference. Use the same operation under the intended business user’s permissions.

In the deployed workflow’s Projection Action Information, open the add/configuration assistant:

1. Select the captured API in Projection General Info.
2. In Action Details, select DATA for the relevant entity create/update operation, or CALL for the captured action/function.
3. Select only the intended entity set/operation or call name.
4. Choose type Validation and timing Before for the missing-reference check.
5. Review the configuration, enable the projection action, and finish.

This timing applies to this projection-based validation. Do not copy it into an event-based notification, which has a different transaction boundary.

7. Verify the mapping and both business outcomes

Run the real operation with an empty reference. Inspect the workflow entry variables and confirm your script reads the actual mapped field. If the payload nests the field or exposes a different name, map it deliberately rather than adding several guessed variable names to the script.

Use this acceptance table and record the actual persisted result:

Input	Expected validation	Expected business result
Missing field	Fail	Intended operation does not persist
Empty text	Fail	Intended operation does not persist
Spaces only	Fail	Intended operation does not persist
LAB-REF-044	Pass	Exactly one intended change persists

Repeat with the normal user role. If Inspect succeeds but the page does not trigger the workflow, check the projection action’s API/entity/call, enabled flag, deployed version, and timing. A workflow can be deployed correctly while registered against the wrong operation.

8. Add one enhancement with a separate checkpoint

Export the accepted version. Add only one new branch or input check and repeat the table before introducing an external system. For example, require a bounded reference format after the missing-value check, then test both valid and invalid formats.

Keep email and external REST writes out of the Before validation path. A rejected business operation must not leave an unintended notification or remote write behind. Add those through a separately reviewed post-change/asynchronous workflow once their acceptance tests exist.

9. Roll back the lab safely

Disable the lab projection action first, verify the original operation’s baseline behavior, and restore the prior accepted deployment/configuration using the supported workflow tools. Confirm no other trigger intentionally depends on the workflow before retiring it.

Save process key/version, trigger configuration, test role, sanitized input, displayed message, and persisted outcome together. The BPMN download’s local XML/script checks remain separate from this required environment execution evidence.

Release sources

• getting started with workflows
• workflow tooling
• deployment validations
• workflow faq

Grow the first workflow one responsibility at a time

After the missing-reference exercise, add only one new behavior per iteration. First prove the trigger and captured inputs, then add a decision, then verify allowed and rejected branches. Capture evidence before adding an external dependency so a later failure can be isolated to a specific change.

A successful deployment shows that the definition passed deployment checks; it does not prove the business rule, permissions, or transaction behavior. Repeat the exercise as a normal intended user and with missing, empty, and unexpected input. Re-run the originating operation with the new trigger disabled to establish the baseline.

Choose the next step by intent: external context for a read-only lookup, email notification for a persistent side effect, or API invocation for another entry point. Keep the original validation small enough that its accepted/rejected paths remain easy to explain.