Dialogs and assistants with explicit input and output

Client keyword reference / Dialogs and assistants with explicit input and output

IFS Cloud 26R1 · Documentation-based examples · Not compiled or executed in IFS.

Use a dialog to collect a few values; use an assistant for a guided operation. Keep temporary input separate from persisted business records. The examples use fictional projection structures/virtuals that must be defined and generated first.

dialog input output and cancellation

1. Add a projection structure TrainingNoteInput with a Text Note attribute.
2. Define the client dialog and its group below. Ok and Cancel are the dialog’s standard commands.
3. Add command CollectTrainingNote; to a request group and define the caller.
4. Test OK and Cancel. The example only displays the returned note; it does not save it.

dialog TrainingNoteDialog for TrainingNoteInput {
   label = "Review note";
   input(Note);
   output(Note);
   group TrainingNoteFields;
   command Ok;
   command Cancel;
}
group TrainingNoteFields for TrainingNoteInput {
   field Note { multiline = true; required = [true]; }
}
command CollectTrainingNote for DemoRequest {
   label = "Draft review note";
   variable NoteResult Text;
   execute {
      dialog TrainingNoteDialog(Title) into NoteResult {
         when OK { info("Draft note: ${NoteResult}"); }
         when CANCEL { exit; }
      }
   }
}

Keep argument order aligned with input and output. To persist the note, call an authorized server action in the OK branch after validating the returned value. Test Cancel after editing and verify that no business write occurred.

assistant steps and finish

Expose a virtual TrainingReview through TrainingReviewSet, with RequestId and Note. Implement a FinishTrainingReview action matching the virtual’s lifetime and business-write contract. ReviewInputGroup must be a group for TrainingReview containing those attributes.

assistant RequestReviewAssistant using TrainingReviewSet {
   label = "Review a training request";
   input(RequestId);
   savemode = OnFinish;
   steps {
      step {
         label = "Review details";
         group ReviewInputGroup;
         next command { enabled = [Note != null]; }
      }
      final step { description = "The review operation completed."; }
      cancelled step { description = "Review stopped."; }
   }
   finish command {
      execute { call FinishTrainingReview(RequestId, Note); }
   }
}

Walk through missing note, valid note, cancellation, and server rejection. Record which virtual data is saved at each step and ensure the final success view follows a successful action. savemode does not make several independent server calls atomic. If autorestart = [true]; is added, verify repeat execution cannot accidentally duplicate the business change.

Modal and single-step assistants

A modal assistant uses the assistant invocation inside a caller’s execute block. For the assistant above, whose only input is RequestId:

execute {
   assistant RequestReviewAssistant(RequestId) {
      when OK { info("Review assistant finished."); }
      when CANCEL { exit; }
   }
}

If the assistant declares output(ReviewId);, receive it with into ReviewResult using a correctly typed variable. For a single-step variant, replace the steps block with singlestep { group ReviewInputGroup; }, and attach explicit commands for completion and cancellation. Their execute blocks end with exit OK; or exit CANCEL; after the required work. Test that a server error leaves input available for correction instead of closing the dialog.

Dynamic steps and setup

Dynamic assistants need a generated step-definition service and the IFS dynamic-assistant framework contract. Once your projection exposes that contract, a steps fragment is:

steps {
   dynamic BuildTrainingReviewSteps(RequestId);
   final step { description = "Training review completed."; }
}

This is not an arbitrary function returning a string array. Start from the official SDK contract, implement step IDs, controls, initialization, and completion commands, then test an empty definition, branching answers, and repeated entry. Use a setup block only with its agreed caller inputs; keep setup repeatable. Choose the ordinary assistant above when the steps are known at build time so the implementation remains easier to inspect.

Official syntax and next steps

• Dialog
• Assistant
• Modal Assistant
• Single Step Assistant
• Dynamic Assistant

Use the build and acceptance checklist before delivering a change.