Create, run and recover an assisted workflow¶

This guide follows the current HiveAI 06 Final Screens. The frontend is still in progress, and the complete run journey has implementation gaps. Follow a step only when the corresponding control and complete review are available in your environment. The examples describe two task reassignments; other supported workflows need their own exact details.

Before you begin¶

Confirm the workspace, repeated outcome and work items involved. You need the applicable HiveAI access and permission for each source action. Creating, changing or retiring a saved workflow also requires workspace policy-management authority.

Choose tasks and people from information you are allowed to access. Decide what should stay the same between runs and what must be selected each time. Do not put passwords, access tokens or unnecessary sensitive information into a workflow description or input.

Read governed action review if you are unfamiliar with approval, expiry or uncertain outcomes. Starting a workflow and approving its first task change are separate decisions.

Find a workflow and inspect its plan¶

1. Ask HiveAI about the reusable workflows available to you, or use Browse workflows when offered.
2. In Reusable Workflows, read the name, description, version, audience and planned action count.
3. Select Open workflow.
4. Inspect Values Needed for a Run and Planned Actions.
5. Check the order and the scope of every action before selecting Ask to run this workflow.

The example “Monthly Close Follow-up” requires a monthly close review task, a reconciliation review task and a colleague to receive both tasks. Those are example inputs, not fixed requirements for every workflow.

Show retired includes retired definitions where you have access. Your workflow runs opens your saved run history. An empty list means no matching records were returned; it does not prove that no workflow exists anywhere in the organization.

Ask to create a reusable workflow¶

1. Describe the repeated work in a conversation, or select Ask to create a workflow from the empty state.
2. Explain the actions, their order and which inputs should be chosen for each run.
3. Read the proposed workflow review.
4. Check the name, description, audience, required inputs and planned actions.
5. Select Create workflow only when the complete plan is correct. Select Reject creation if it is not.
6. Look for the saved creation result before treating the plan as available.

A useful request is: “Create a monthly close follow-up that reassigns the two review tasks to the colleague I choose. Ask for approval before each task change.” The system still needs to validate whether that plan is supported.

The creation receipt offers View workflow and Ask to run it. Creating the definition does not start a run or change either task. A request that is merely saved is not a creation receipt.

Review a change to the definition¶

1. Open the definition and select Ask to change it, or describe the intended change.
2. Compare the current and proposed values shown in the exact review.
3. Check whether the audience, inputs, action order or effects also change.
4. Select Save change to approve those details, or Reject change.
5. Verify the resulting saved version.

The current example changes the description while retaining the private audience, three inputs and two actions. That example does not authorize other changes. Updating a definition does not retroactively replace the version recorded on an existing run.

Retire a definition¶

1. Open the workflow and select Ask to retire it.
2. Review the named workflow and version and read the consequences.
3. Select Retire workflow to proceed, or Keep workflow.
4. Check the saved result and the retired version.
5. Use Your workflow runs to inspect earlier runs.

Retirement does not undo completed task changes. The current backend checks retirement for the selected version; complete blocking of older versions remains an implementation constraint. If retirement is needed to prevent further use, ask the workspace administrator to confirm the effective restriction.

Select inputs for one run¶

1. Select Ask to run this workflow.
2. Read Choose tasks for this run and the selected colleague.
3. Use Change monthly task or Change reconciliation task when the corresponding choice is wrong.
4. In the task panel, inspect its recognizable title, request reference and current assignment.
5. Select Use this task for the intended step.
6. Select Review run after checking all inputs.

In the current example, the same colleague receives both tasks. If that is not your intention, correct the request before starting. The inspected selection screen does not show a separate control for changing the colleague; do not approve an incorrect person merely because both task selectors are present.

The task title helps you recognize the work; it is not permission to act on it. The system must still check the current task before each change.

Review starting the run¶

Read the workflow name, version, selected tasks and selected colleague in Review this run. Select Start workflow only when those details are complete and correct; use Reject start otherwise.

A successful start result says the run is saved and waiting for its first task review. It does not mean either task has been reassigned. Select View saved run to inspect its state.

If selected inputs are unavailable, use Refresh review details. A saved request with unavailable review details does not confirm that a run started.

Review each task change¶

1. Read the current task, current assignee and proposed assignee.
2. Check why that colleague was selected, the review expiry and any restoration conditions.
3. Use Open task to inspect the work when offered.
4. Select Approve change for that exact task change, or Reject change.
5. Wait for a confirmed source result.
6. Review the next task separately if the run subsequently presents it.

The first approval does not approve the second task. The second review should identify the next task and acknowledge the first confirmed result. Never infer that the next step succeeded from its position in the plan.

A source task can be confirmed while the saved workflow still says it is waiting. Use Refresh status and keep the original run. Automatic progression is not yet established by the inspected implementation; if the mismatch persists, ask for support.

Inspect progress and completed work¶

Use Your workflow runs and Open run, or View saved run from a receipt. Some earlier frames label the related inspection control View saved workflow.

Read the workflow version, owner information, saved timestamp, current review and available change history. Where a history entry includes attempts, distinguish when the change was requested from when it was confirmed.

Selected values may be unavailable in saved history. That does not mean they were never supplied or have been deleted. Review the exact current change before making another decision. If history itself is unavailable, use Refresh status and retain the run reference.

Treat the run as complete only when its saved result confirms completion. A completed run has no next action to approve. If old helper text refers to a “next change” on an otherwise completed history panel, use the completed state and investigate the inconsistency rather than starting more work.

Stop remaining work¶

1. Open the saved run and select Ask to stop when offered, or ask to stop the remaining work.
2. Read Review stopping this run.
3. Confirm which run is involved and what has already completed.
4. Select Stop workflow, or Keep run active.
5. Check the saved stop result.

The implementation supports stopping a waiting run whose current proposal can still be stopped. A change already sent for execution may finish. A completed task change remains in place. If stop details are unavailable or the run has changed, refresh the original request and do not assume the stop was accepted.

Stopping the conversation, stopping one proposal and stopping a workflow run are different actions. For a correction to completed work, use a separately reviewed supported change or the owning application's ordinary process.

Recover an uncertain original change¶

The unconfirmed-result screen separates the saved workflow from the task change whose outcome is unknown.

1. Keep the original run and task change.
2. Select Refresh status when you only want to read saved state.
3. Select Recover original change when you want the system to investigate and recover that approved change.
4. Read the recovery decision: after checking the source, it may continue the same change if still allowed.
5. Select Continue recovery to proceed, or Keep saved request to leave it unsubmitted.
6. Check the result in the task and saved run.

Recovery does not create another run or guarantee later workflow progression. If the source already confirms the change, do not ask for the same reassignment again merely to make the conversation catch up.

Handle missing or unavailable information¶

Costs and saved information¶

Creating a reusable plan does not provide a fixed price for all future runs. Conversation work, speech and permitted operations follow their own credit and budget rules. A run's step count is not its price, and missing usage information is not zero cost. See credits and budgets.

Definition versions, run inputs, intermediate outputs, proposal references and checkpoints support execution and investigation. The ordinary history screen exposes a smaller set of information. Retiring a definition or stopping a run does not erase that history. Use approved support and data-lifecycle channels for export or deletion questions.

Help your administrator or support team¶

Provide the workspace, workflow name and version, recognizable task references, approximate time and last visible state. State whether you approved creation, starting, a task change, stopping or recovery, and which source results are confirmed.

Use the approved support channel and include only necessary information. Managers should report confirmed task outcomes separately from runs awaiting review or investigation. The initial audience review remains pending; these steps do not establish a completed frontend rollout.