Page actions, review and completion
Page actions let a journey do work at specific moments: before validation, after valid answers, at task-list completion or in a review workflow. Keep the trigger and outcome clear. A person should never be surprised that an external update, message or redirect happened because they selected Continue.
Separate page visibility from validation
Visibility conditions decide whether a whole page appears in the journey. They do not validate answers. Use page validation conditions when the page itself should not continue, and component validation conditions when a particular answer is required or must meet a rule.
In a Task List service, a task becomes Not required when every page in that task has page-level visibility conditions and they are all false. Do not add separate actions or fields to recreate that status.
Choose the action trigger based on what must happen
| Trigger | Use it when | Avoid it when |
|---|---|---|
| Pre validate actions | You must retrieve or prepare data before page validation. | The work is independent of the current answer. |
| Post validate actions | An action should run only after the page is valid, such as assigning a value or redirecting. | The action needs to complete before validation. |
| User complete actions | A Task List service has reached user completion. | The action belongs to one individual task page. |
| Workflow actions | Work should occur after submission, possibly with a review pause. | The person must see its result before continuing. |
Actions in a trigger run in their configured order. Put a lookup before an assignment that reads it, and put a redirect after work that must happen first. Test a retry so that a repeated submission does not create duplicates.
flowchart LR
A["Person selects Continue"] --> B["Pre-validation action (if configured)"]
B --> C{"Page is valid?"}
C -->|"No"| D["Show helpful error"]
C -->|"Yes"| E["Post-validation action"]
E --> F["Next page or redirect"]
F --> G["Completion or background workflow"]Design a safe completion route
User complete actions run from the first Task List page when a person completes the overall service. They can run again when a completed journey is updated, so write them to be safe on a repeat. The completion page must make clear whether the person can still make changes, whether a reviewer will act, and how they will receive an outcome.
Review actions may limit a page to reviewers. In For internal use by reviewer(s), select only the review-action IDs that require access. An empty setting does not restrict the page. Check permissions with a reviewer account and a normal user account; do not rely on hidden links as access control.
Make review summaries easy to scan
Where a flat Check your answers layout is used, spacing and border lines can show where one page’s answers end and another begins. Use separators when they genuinely improve scanning; keep page titles and change links meaningful. Review layout is not a substitute for clear question labels and concise answers.
Test failure, not just success
Test each relevant trigger in QA with representative non-sensitive data:
- A valid answer and expected action result.
- An invalid answer, confirming post-validation work does not run.
- A failed lookup, timeout or rejected request.
- A condition that skips the page.
- A repeat attempt or change after completion.
- Reviewer-only page access using the correct and incorrect role.
The person’s journey must remain understandable on every path. Provide a recoverable message or route when an external dependency cannot complete.