Prepared action Create one customer follow-up task
Waiting for decision Reviewer: Operations reviewer · Destination: local CRM simulation
Approve continues to the simulated CRM. Reject stops here with zero tasks recorded.
Workflow automation · Human approval before action
RelayOps — human-approved workflow automation
RelayOps checks a customer follow-up request, prepares the exact CRM task and pauses for a person before anything can move forward.
Start with a scenario System ready
- 01CheckRequired data
- 02PrepareReviewable task
- 03DecidePerson approves
- 04RecordOne safe result
Example: create one customer follow-up task in a CRM. This demo stays in your browser and contacts no real system.
01 / Why this matters
Incomplete requests should stop before they reach another system.
Imagine an operations team asking for a customer follow-up task in its CRM. RelayOps checks the email, prepares the task without sending it, waits for the named reviewer and records the outcome. If information is missing or delivery fails, the workflow pauses visibly instead of guessing or retrying in the background.
- Missing information
- The run stops until a person supplies the required value.
- Human decision
- Nothing reaches delivery until the reviewer approves the exact task.
- Delivery failure
- A retry is explicit and reuses the same duplicate-prevention key.
02 / Guided workflow demo
Try one request and see exactly where it pauses.
Everything below is fictional and runs locally in this browser. No customer record, CRM task or network request is created.
- 1Choose a scenarioStart with “Complete request” if this is your first visit.
- 2Run the requestRelayOps checks the data and prepares one follow-up task.
- 3Make the decisionApprove or reject only when the workflow pauses for you.
- 4Inspect the resultConfirm the number of simulated tasks and why each step happened.
Result so far
Nothing has been delivered.No simulated follow-up task exists. Choose a scenario to see how the workflow reaches—or safely avoids—a result.
Detailed workflow status
Idle Technical trace: the “Check” stage above is shown here as Receive + Validate.- Idle
- Capturing
- Validating
- Needs input
- Preparing
- Awaiting approval
- Dispatching
- Retry pending
- Completed
- Rejected
RelayOps laboratory is ready.
-
01Waiting Receive requestLoad the fixed customer follow-up example.
-
02Waiting Check required informationStop instead of guessing when a value is absent.
-
03Waiting Prepare follow-up taskBuild the exact task without sending it anywhere.
-
04Waiting Reviewer decidesA named person approves or rejects the prepared task.
-
05Waiting Simulate CRM deliveryRecord one result and prevent a duplicate on retry.
Example request
Request RLY-COMPLETE-01
- Account
- Example operations team
- Proposed CRM action
- Create one customer follow-up task
- Reviewer
- Operations reviewer
- Customer email
- ops@example.test
- Duplicate-prevention key
relayops:complete:request-001- CRM delivery attempts
- 0
Validation stopped
A required customer email is missing.Simulated CRM response
The first delivery attempt failed temporarily. No task was recorded. The retry keeps the exact prepared action and reusesrelayops:failure:request-001 to prevent a duplicate. Simulated follow-up tasks recorded 0 No simulated CRM delivery attempted
Human decision
No decision is needed yet
No task is waiting for review. Run a scenario to prepare one.
Recorded in order
Why each step happened
- 01
IDLELAB_READYComplete request selected. No external action is configured.
03 / Safety rules
Five rules keep the workflow predictable.
- 01
Required data
Required fields are checked before preparation. Missing information becomes a visible pause, never a guessed value.
- 02
Allowed steps
Only defined events can move the workflow. A stale click cannot skip validation or approval.
- 03
Human authority
The system prepares the task; the named reviewer makes the consequential decision.
- 04
Duplicate protection
Every simulated delivery uses one stable key, so a retry still represents the same intended task.
- 05
Visible record
Each transition records what happened and why. The interface never claims that a real CRM action occurred.
04 / Guardrails
What this laboratory refuses to do.
- No hidden network action.There is no fetch, form submission, webhook or third-party adapter call in the workflow.
- No generated decisions.Branches are fixed and inspectable; no model invents fields, approvals or outcomes.
- No duplicate dispatch.Busy-state guards disable consequential controls and state checks reject stale events.
- No silent recovery.Missing data and temporary failure remain visible until a person chooses the next valid action.
05 / Test matrix
Each scenario has a result you can verify on screen.
| Scenario | What happens | Expected result | Proof on screen |
|---|---|---|---|
| Complete request | Check → prepare → reviewer decides | One simulated task after approval, or zero after rejection | Delivery is impossible before the decision. |
| Missing data | Check → stop for email → resume | Zero tasks until the missing value is supplied and approved | No placeholder is invented for the email. |
| External failure | Approve → simulated failure → explicit retry | One final simulated task, never two | Both attempts show the same duplicate-prevention key. |